From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 00:59:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72C0F83F for ; Sun, 4 Nov 2012 00:59:07 +0000 (UTC) (envelope-from bane.ivosev@pmf.uns.ac.rs) Received: from mail.pmf.uns.ac.rs (mail.pmf.uns.ac.rs [147.91.177.13]) by mx1.freebsd.org (Postfix) with ESMTP id F17A58FC08 for ; Sun, 4 Nov 2012 00:59:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.pmf.uns.ac.rs (Postfix) with ESMTP id 750D4223E3; Sun, 4 Nov 2012 01:59:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.pmf.uns.ac.rs Received: from mail.pmf.uns.ac.rs ([127.0.0.1]) by localhost (mail.pmf.uns.ac.rs [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6FDo+qvUUAhM; Sun, 4 Nov 2012 01:58:58 +0100 (CET) Received: from [10.10.13.5] (unknown [10.10.11.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bane.ivosev@pmf.uns.ac.rs) by mail.pmf.uns.ac.rs (Postfix) with ESMTPSA id 3ACEE2018E; Sun, 4 Nov 2012 01:58:57 +0100 (CET) Message-ID: <5095BDD1.40504@pmf.uns.ac.rs> Date: Sun, 04 Nov 2012 01:58:57 +0100 From: Bane Ivosev Organization: PMF Novi Sad User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.10) Gecko/20121028 Icedove/10.0.10 MIME-Version: 1.0 To: Bryan Venteicher , "freebsd-stable@freebsd.org" Subject: Re: kvm vlan virtio problem References: <1542441515.1609.1351975216870.JavaMail.root@daemoninthecloset.org> In-Reply-To: <1542441515.1609.1351975216870.JavaMail.root@daemoninthecloset.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: bane.ivosev@pmf.uns.ac.rs List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 00:59:07 -0000 thanks bryan, i don't have vlans inside guest. as you suggested i disabled nic tso ifconfig vtnet0 -tso and sysctl net.inet.tcp.tso=0 and so far, so good! everything is ok now. once again, thanks a lot. On 11/03/2012 09:40 PM, Bryan Venteicher wrote: > Hi, > > ----- Original Message ----- >> From: "Bane Ivosev" >> To: freebsd-stable@freebsd.org >> Sent: Saturday, November 3, 2012 2:12:25 PM >> Subject: kvm vlan virtio problem >> >> hi, i have several kvm ubuntu 12.04 and centos 6 hosts with standard >> bridged network setup. same problem on each server with freebsd 9 >> amd64 >> guest and virtio nic: soon after guest start host syslog is filling >> with >> this message at very high rate. guest is working without any problem. >> with e1000 guest driver eveything is ok. >> >> does enyone have/had same problem? >> >> thanks. >> > > I have a vague recollection of looking at something similar last year... > > Do you have VLAN configured in the guest as well? What is the ifconfig > output? Does disabling TSO on the vtnetX device make these messages go > away? > > Bryan > >> >> kernel: [2337728.094141] ------------[ cut here ]------------ >> kernel: [2337728.094144] WARNING: at >> /build/buildd/linux-3.2.0/net/core/dev.c:1955 >> skb_gso_segment+0x341/0x3b0() >> kernel: [2337728.094146] Hardware name: System x3550 M3 -[7944K3G]- >> kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, >> 0x0) >> len=3196 data_len=0 ip_summed=0 >> kernel: [2337728.094149] Modules linked in: dm_snapshot >> ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE >> iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state >> nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp >> iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs >> lockd >> fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat >> 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap >> i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp parport >> mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 >> kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G >> W 3.2.0-31-generic #50-Ubuntu >> kernel: [2337728.094179] Call Trace: >> kernel: [2337728.094180] [] >> warn_slowpath_common+0x7f/0xc0 >> kernel: [2337728.094185] [] >> warn_slowpath_fmt+0x46/0x50 >> kernel: [2337728.094188] [] >> skb_gso_segment+0x341/0x3b0 >> kernel: [2337728.094191] [] >> dev_hard_start_xmit+0xc1/0x540 >> kernel: [2337728.094196] [] ? br_flood+0xc0/0xc0 >> [bridge] >> kernel: [2337728.094199] [] >> dev_queue_xmit+0x2aa/0x420 >> kernel: [2337728.094203] [] >> br_dev_queue_push_xmit+0x92/0xd0 [bridge] >> kernel: [2337728.094208] [] >> br_forward_finish+0x58/0x60 [bridge] >> kernel: [2337728.094212] [] >> __br_forward+0xab/0xd0 >> [bridge] >> kernel: [2337728.094217] [] br_forward+0x5d/0x70 >> [bridge] >> kernel: [2337728.094221] [] >> br_handle_frame_finish+0x182/0x2a0 [bridge] >> kernel: [2337728.094226] [] >> br_handle_frame+0x1c8/0x270 [bridge] >> kernel: [2337728.094231] [] ? >> br_handle_frame_finish+0x2a0/0x2a0 [bridge] >> kernel: [2337728.094234] [] >> __netif_receive_skb+0x1e2/0x520 >> kernel: [2337728.094237] [] >> process_backlog+0xb1/0x190 >> kernel: [2337728.094240] [] >> net_rx_action+0x134/0x290 >> kernel: [2337728.094242] [] ? >> _raw_spin_lock+0xe/0x20 >> kernel: [2337728.094245] [] >> __do_softirq+0xa8/0x210 >> kernel: [2337728.094248] [] >> call_softirq+0x1c/0x30 >> kernel: [2337728.094249] [] >> do_softirq+0x65/0xa0 >> kernel: [2337728.094254] [] >> netif_rx_ni+0x28/0x30 >> kernel: [2337728.094258] [] >> tun_get_user+0x306/0x4a0 >> kernel: [2337728.094261] [] >> tun_sendmsg+0x25/0x30 >> kernel: [2337728.094265] [] >> handle_tx+0x296/0x530 >> [vhost_net] >> kernel: [2337728.094269] [] >> handle_tx_kick+0x15/0x20 [vhost_net] >> kernel: [2337728.094273] [] >> vhost_worker+0xdd/0x170 >> [vhost_net] >> kernel: [2337728.094276] [] ? >> vhost_set_memory+0x130/0x130 [vhost_net] >> kernel: [2337728.094279] [] kthread+0x8c/0xa0 >> kernel: [2337728.094282] [] >> kernel_thread_helper+0x4/0x10 >> kernel: [2337728.094285] [] ? >> flush_kthread_worker+0xa0/0xa0 >> kernel: [2337728.094287] [] ? >> gs_change+0x13/0x13 >> kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- >> kernel: [2337728.094731] ------------[ cut here ]------------ >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 01:36:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA848503 for ; Sun, 4 Nov 2012 01:36:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id A5E5A8FC08 for ; Sun, 4 Nov 2012 01:36:55 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MCX00M00TPDPC00@smtpauth3.wiscmail.wisc.edu> for freebsd-stable@freebsd.org; Sat, 03 Nov 2012 19:36:49 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-71-150-249-157.dsl.mdsnwi.sbcglobal.net [71.150.249.157]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MCX00I3NTPBAH10@smtpauth3.wiscmail.wisc.edu>; Sat, 03 Nov 2012 19:36:48 -0500 (CDT) Date: Sat, 03 Nov 2012 19:36:47 -0500 From: Nathan Whitehorn Subject: Re: SU+J on 9.1-RC2 ISO In-reply-to: <20121103190930.GA23145@icarus.home.lan> To: Jeremy Chadwick Message-id: <5095B89F.4070705@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=71.150.249.157 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.4.2416, SenderIP=71.150.249.157 References: <20121103190930.GA23145@icarus.home.lan> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121019 Thunderbird/16.0.1 Cc: b.smeelen@ose.nl, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 01:36:56 -0000 There's an existing checkbox to disable it. There was substantial consensus for 9.0 that SUJ was something we wanted -- I'd personally be very hesitant to change the defaults without more input from FS people. I think this discussion should be moved to freebsd-fs@ or freebsd-current@ instead of stable@ since it's actually a filesystem issue not an installer issue. -Nathan On 11/03/12 14:09, Jeremy Chadwick wrote: > (Please keep me CC'd, as I'm not subscribed to -stable) > > I've CC'd Nathan Whitehorn, who according to bsdinstall(8) is the > author (not sure if maintainer) of the code. > > This default has already begun to bite users/SAs in the ass: > > http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html > > SU+J (the journalling part specifically) needs to be disabled by default > in the installer. This default was a very bad choice and should not > have been done. It either indicates someone was out of touch with the > rest of the issues surrounding the feature, or that someone > intentionally decided "it's the best way to get people using it for > testing" (I have seen this justification presented in the past, and it > is the wrong approach). > > However, since some people DO want it (and those folks don't use dump), > the installer should be modified to make SU+J support toggleable via a a > checkbox. The default, obviously, should be unchecked. > > If the user checks the checkbox, an ominous warning message should be > displayed informing the user of the repercussions. The only option at > that point should be "OK", after which the checkbox is checked. > > Do not tell me "send patches". This issue/problem has gone on long > enough, and the community bitched hard/long enough, that the person who > committed this default should be responsible for fixing it. > > We should operate under the assumption that this bug/problem will never > be fixed. It probably will be, but again, we must operate with the > assumption that Kirk et al will require years to fix it. (It has > already been something like 9 months. Or is it a year?) > > While I'm here -- does anyone remember the exact commit which was done > sometime in the past 6-9 months which "made the installer work properly > with SSDs" (re: partition alignment)? I have questions about that; if I > remember right, someone set the alignment size to 4KBytes, and that is > completely 100% wrong -- it needs to be 1MByte or 2MBytes if you want to > be extra cautious, which correlates with NAND erase block size, > otherwise we're not really solving jack squat. > From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 01:54:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B4D9849 for ; Sun, 4 Nov 2012 01:54:36 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 01EE28FC12 for ; Sun, 4 Nov 2012 01:54:35 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.196.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 2DC1942C088A; Sun, 4 Nov 2012 02:56:04 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id 9D8B16F3EF; Sat, 3 Nov 2012 20:53:40 -0500 (CDT) Date: Sat, 3 Nov 2012 20:53:39 -0500 (CDT) From: Bryan Venteicher To: bane ivosev Message-ID: <2103527496.1667.1351994019607.JavaMail.root@daemoninthecloset.org> In-Reply-To: <5095BDD1.40504@pmf.uns.ac.rs> Subject: Re: kvm vlan virtio problem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC22 (Mac)/7.2.0_GA_2669) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 01:54:36 -0000 Hi, ----- Original Message ----- > From: "Bane Ivosev" > To: "Bryan Venteicher" , freebsd-stable@freebsd.org > Sent: Saturday, November 3, 2012 7:58:57 PM > Subject: Re: kvm vlan virtio problem > > thanks bryan, i don't have vlans inside guest. > > as you suggested i disabled nic tso > > ifconfig vtnet0 -tso > and > sysctl net.inet.tcp.tso=0 and > > so far, so good! > everything is ok now. > > once again, thanks a lot. > No need to disable TSO globally. So it seems if_vtnet sending down TSO frames that don't have the appropriate flags set. I'll look into it more in a next couple of days. Thanks for the quick reply back. Bryan > > On 11/03/2012 09:40 PM, Bryan Venteicher wrote: > > Hi, > > > > ----- Original Message ----- > >> From: "Bane Ivosev" > >> To: freebsd-stable@freebsd.org > >> Sent: Saturday, November 3, 2012 2:12:25 PM > >> Subject: kvm vlan virtio problem > >> > >> hi, i have several kvm ubuntu 12.04 and centos 6 hosts with > >> standard > >> bridged network setup. same problem on each server with freebsd 9 > >> amd64 > >> guest and virtio nic: soon after guest start host syslog is > >> filling > >> with > >> this message at very high rate. guest is working without any > >> problem. > >> with e1000 guest driver eveything is ok. > >> > >> does enyone have/had same problem? > >> > >> thanks. > >> > > > > I have a vague recollection of looking at something similar last > > year... > > > > Do you have VLAN configured in the guest as well? What is the > > ifconfig > > output? Does disabling TSO on the vtnetX device make these messages > > go > > away? > > > > Bryan > > > >> > >> kernel: [2337728.094141] ------------[ cut here ]------------ > >> kernel: [2337728.094144] WARNING: at > >> /build/buildd/linux-3.2.0/net/core/dev.c:1955 > >> skb_gso_segment+0x341/0x3b0() > >> kernel: [2337728.094146] Hardware name: System x3550 M3 > >> -[7944K3G]- > >> kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, > >> 0x0) > >> len=3196 data_len=0 ip_summed=0 > >> kernel: [2337728.094149] Modules linked in: dm_snapshot > >> ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE > >> iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state > >> nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp > >> iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs > >> lockd > >> fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat > >> fat > >> 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap > >> i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp > >> parport > >> mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 > >> kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G > >> W 3.2.0-31-generic #50-Ubuntu > >> kernel: [2337728.094179] Call Trace: > >> kernel: [2337728.094180] [] > >> warn_slowpath_common+0x7f/0xc0 > >> kernel: [2337728.094185] [] > >> warn_slowpath_fmt+0x46/0x50 > >> kernel: [2337728.094188] [] > >> skb_gso_segment+0x341/0x3b0 > >> kernel: [2337728.094191] [] > >> dev_hard_start_xmit+0xc1/0x540 > >> kernel: [2337728.094196] [] ? > >> br_flood+0xc0/0xc0 > >> [bridge] > >> kernel: [2337728.094199] [] > >> dev_queue_xmit+0x2aa/0x420 > >> kernel: [2337728.094203] [] > >> br_dev_queue_push_xmit+0x92/0xd0 [bridge] > >> kernel: [2337728.094208] [] > >> br_forward_finish+0x58/0x60 [bridge] > >> kernel: [2337728.094212] [] > >> __br_forward+0xab/0xd0 > >> [bridge] > >> kernel: [2337728.094217] [] > >> br_forward+0x5d/0x70 > >> [bridge] > >> kernel: [2337728.094221] [] > >> br_handle_frame_finish+0x182/0x2a0 [bridge] > >> kernel: [2337728.094226] [] > >> br_handle_frame+0x1c8/0x270 [bridge] > >> kernel: [2337728.094231] [] ? > >> br_handle_frame_finish+0x2a0/0x2a0 [bridge] > >> kernel: [2337728.094234] [] > >> __netif_receive_skb+0x1e2/0x520 > >> kernel: [2337728.094237] [] > >> process_backlog+0xb1/0x190 > >> kernel: [2337728.094240] [] > >> net_rx_action+0x134/0x290 > >> kernel: [2337728.094242] [] ? > >> _raw_spin_lock+0xe/0x20 > >> kernel: [2337728.094245] [] > >> __do_softirq+0xa8/0x210 > >> kernel: [2337728.094248] [] > >> call_softirq+0x1c/0x30 > >> kernel: [2337728.094249] [] > >> do_softirq+0x65/0xa0 > >> kernel: [2337728.094254] [] > >> netif_rx_ni+0x28/0x30 > >> kernel: [2337728.094258] [] > >> tun_get_user+0x306/0x4a0 > >> kernel: [2337728.094261] [] > >> tun_sendmsg+0x25/0x30 > >> kernel: [2337728.094265] [] > >> handle_tx+0x296/0x530 > >> [vhost_net] > >> kernel: [2337728.094269] [] > >> handle_tx_kick+0x15/0x20 [vhost_net] > >> kernel: [2337728.094273] [] > >> vhost_worker+0xdd/0x170 > >> [vhost_net] > >> kernel: [2337728.094276] [] ? > >> vhost_set_memory+0x130/0x130 [vhost_net] > >> kernel: [2337728.094279] [] > >> kthread+0x8c/0xa0 > >> kernel: [2337728.094282] [] > >> kernel_thread_helper+0x4/0x10 > >> kernel: [2337728.094285] [] ? > >> flush_kthread_worker+0xa0/0xa0 > >> kernel: [2337728.094287] [] ? > >> gs_change+0x13/0x13 > >> kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- > >> kernel: [2337728.094731] ------------[ cut here ]------------ > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to > >> "freebsd-stable-unsubscribe@freebsd.org" > >> > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 01:56:49 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C1D09DE for ; Sun, 4 Nov 2012 01:56:49 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6688FC08 for ; Sun, 4 Nov 2012 01:56:47 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so4304876lbd.13 for ; Sat, 03 Nov 2012 18:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=B/MrqRIu0QazFBjHkXv8kq4UMk6lKhejXQiYZRP7QkU=; b=KiNUBVXdCdmnLc6eqG78dp6n6rvOh/02K1LgM6GZRQzEKGAyON7F8dnxn3Xu41p0kb YFv+arwGnKV9tx0patcS6OzgsGFc/VHItsPHUDBgYADyuIBW7dsMTBpuwz6IJTpd6C1R FFeYAVKxZPoI6rcOyAvXEi3cydBFtdhZ0/K7GuplJhgwFzg5HmbuTwLQJmOE6c2gerGT N2o+0kI3Ii9/MA8OWUIn84mbPItPqQ0rLZCsOfmzwVeNerIAW7gdjOcMvAiQCYHX+J/e PUbUpMiEh3e+6/AkBYOYGBPxJL4IbRYAY8Fy1qWbdrNqN/wSXAnVusBkMHLUe8UsE3/b PzbQ== MIME-Version: 1.0 Received: by 10.152.104.107 with SMTP id gd11mr5488359lab.25.1351994206169; Sat, 03 Nov 2012 18:56:46 -0700 (PDT) Sender: vrwmiller@gmail.com Received: by 10.112.4.97 with HTTP; Sat, 3 Nov 2012 18:56:45 -0700 (PDT) In-Reply-To: <20121102091021.23cf9af0@suse3> References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> Date: Sat, 3 Nov 2012 21:56:45 -0400 X-Google-Sender-Auth: i4jAuvehCdhupP0evcwjudsVAeA Message-ID: Subject: Re: FreeBSD 9.1 stability/robustness? From: Rick Miller To: Rainer Duffner Content-Type: text/plain; charset=ISO-8859-1 Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 01:56:49 -0000 On Fri, Nov 2, 2012 at 4:10 AM, Rainer Duffner wrote: > Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) > schrieb Brett Glass : > >> I need to build up a few servers and routers, and am wondering how >> FreeBSD 9.1 is shaping up. Will it be likely to be more stable and >> robust than 9.0-RELEASE? Are there issues that will have to wait >> until 9.2-RELEASE to be fixed? Opinions welcome. > > > If I'm not mistaken, the bge-stuff that makes the default NICs ins HP > G8 servers (360+380) actually run will not make it back into 9.1. > Intel cards work much better anyway... I have a blog post at http://blog.hostileadmin.com/2012/06/14/freebsd-on-hp-proliant-dl360p-g8-servers/ which touches on this. I heard as recently as today that the fixes for the BCM5719 and 5720 were recently committed to -CURRENT. It's too late for them to be rolled into 9.1. Not sure if they'll be committed to to stable/8 or not, but if so they could make it into 8.4-R. -- Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 05:19:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 818806FC for ; Sun, 4 Nov 2012 05:19:38 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp9.sbb.rs (smtp9.sbb.rs [89.216.2.41]) by mx1.freebsd.org (Postfix) with ESMTP id DDF6A8FC14 for ; Sun, 4 Nov 2012 05:19:37 +0000 (UTC) Received: from mycenae (cable-178-148-96-94.dynamic.sbb.rs [178.148.96.94]) by smtp9.sbb.rs (8.14.0/8.14.0) with ESMTP id qA45JUit019421 for ; Sun, 4 Nov 2012 06:19:36 +0100 Received: by mycenae (Postfix, from userid 1001) id AC4CF5C23; Sun, 4 Nov 2012 06:19:31 +0100 (CET) Date: Sun, 4 Nov 2012 06:19:31 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO Message-ID: <20121104051931.GA1202@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 05:19:38 -0000 > There's an existing checkbox to disable it. There was substantial > consensus for 9.0 that SUJ was something we wanted Nice to hear. I assume you mean check box during install process? Not mentioned in install guide in handbook. So, after I accept guided partitioning, I should go to "modify" or else? Sorry to bother again and again, but it is not clear to me at the moment. I'd avoid further tunefs if possible. If not possible, let me clear that branch 8 has no J as default and I found myself wondering. Correct me if I'm wrong. I have to go to single user mode first. Make fsck on partition that contains freebsd-ufs ( / ). Check options for that partition with "tunefs -p partition". What exact name that partition would have? Next I have to disable journaling with "-j disable" and enable trim with "-t enable". Reboot and voila? People mention file or partition that has to be deleted. Next few days I will put ssd into laptop and manage install, when release shows up. If there is another point I have to choose for journaling, let me know. Best regards all Zoran From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 07:57:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69A67EDA for ; Sun, 4 Nov 2012 07:57:48 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id ED58E8FC0A for ; Sun, 4 Nov 2012 07:57:47 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Sun, 4 Nov 2012 08:57:37 +0100 Message-ID: <50961FF1.9010605@ose.nl> Date: Sun, 04 Nov 2012 08:57:37 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: freebsd-update and sources of 9.1-RC3 References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 07:57:48 -0000 On 11/03/2012 05=3A03 PM=2C jb wrote=3A =3E Eugene Grosbein =3Ceugen =3Cat=3E grosbein=2Enet=3E writes=3A =3E =3E=3E =2E=2E=2E =3E=3E My real question is how make freebsd-update download sources they ar= e not =3E=3E installed=3F =3E I am not 110=25 sure=2C but you can not=2E =3E When freebsd-update runs=2C it checks its config file /etc/freebsd-upda= te=2Econf =3E and then takes inventory of your system =28that=27s why it is called=20= =22update=22=2C and =3E that=27s why you do not get new src set=29=2E =3E FREEBSD-UPDATE=288=29 does not give any =22override=22 option=2E =3E So=2C here you are=2E But next time =28assuming you keep your src=29 yo= u will be fine=2E =3E jb Can=27t this be accomplished by setting StrictComponents yes in /etc/freebsd-update=2Econf =3F Then feebsd-update does not try to figure out the components to update=20= by itself=2C but updates the components mentioned in Components src world kernel I didn=27t try what happens if no source is installed=2E This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 08:05:42 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 578B3114 for ; Sun, 4 Nov 2012 08:05:42 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id EDD588FC0C for ; Sun, 4 Nov 2012 08:05:41 +0000 (UTC) Received: from [10.188.2.241] (5.sub-70-197-141.myvzw.com [70.197.141.5]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id qA4816Yi044789 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 4 Nov 2012 01:01:07 -0700 (PDT) (envelope-from takeda@takeda.tk) User-Agent: K-9 Mail for Android In-Reply-To: <201211032130.PAA04484@lariat.net> References: <201211032130.PAA04484@lariat.net> MIME-Version: 1.0 Subject: Re: Why is SU+J undesirable on SSDs? From: Derek Kulinski Date: Sun, 04 Nov 2012 01:00:59 -0700 To: Brett Glass , stable@freebsd.org Message-ID: <6a2843fd-1574-440d-a3c5-83aeb106b854@email.android.com> X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean X-Bogosity: No, tests=bogofilter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 08:05:42 -0000 I personally let it be enabled during installation. I noticed that I was getting errors on fsck even after clean shutdown. After noticing it, I disabled it and the problems go away. Also, fsck works really fast so I don't see much advantage with SU+J. -- Sent from my phone. Please excuse my brevity. Brett Glass wrote: >Have been following the thread related to SU+J, and am wondering: why >is it >considered to be undesirable on SSDs (assuming that they have good wear >leveling)? I have been enabling it on systems with SSDs, hoping that >between >the lack of rotating media and the journaling I would have very robust >systems. > >--Brett Glass >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to >"freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 09:13:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6706BE4B for ; Sun, 4 Nov 2012 09:13:15 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id EF6468FC0A for ; Sun, 4 Nov 2012 09:13:14 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Sun, 4 Nov 2012 10:13:12 +0100 Message-ID: <509631A7.3000709@ose.nl> Date: Sun, 04 Nov 2012 10:13:11 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO References: <20121104051931.GA1202@mycenae.sbb.rs> In-Reply-To: <20121104051931.GA1202@mycenae.sbb.rs> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 09:13:15 -0000 On 11/04/2012 06=3A19 AM=2C Zoran Kolic wrote=3A =3E=3E There=27s an existing checkbox to disable it=2E There was substantia= l =3E=3E consensus for 9=2E0 that SUJ was something we wanted =3E Nice to hear=2E I assume you mean check box during install =3E process=3F Not mentioned in install guide in handbook=2E =3E So=2C after I accept guided partitioning=2C I should go to =3E =22modify=22 or else=3F Sorry to bother again and again=2C but =3E it is not clear to me at the moment=2E I=27d avoid further =3E tunefs if possible=2E =3E If not possible=2C let me clear that branch 8 has no J as =3E default and I found myself wondering=2E Correct me if I=27m =3E wrong=2E I have to go to single user mode first=2E Make fsck =3E on partition that contains freebsd-ufs =28 / =29=2E Check =3E options for that partition with =22tunefs -p partition=22=2E =3E What exact name that partition would have=3F Next I have to =3E disable journaling with =22-j disable=22 and enable trim with =3E =22-t enable=22=2E Reboot and voila=3F =3E People mention file or partition that has to be deleted=2E =3E Next few days I will put ssd into laptop and manage install=2C =3E when release shows up=2E If there is another point I have =3E to choose for journaling=2C let me know=2E =3E Best regards all =3E =3E Zoran I have just installed fresh from 9=2E1-RC3 ISO and cannot find a checkbox= =20 to disable journaling or enable TRIM=2E Do I miss something here=3F The only way I can find to customize is to go to the shell=2C which is an= =20 option in bsdinstall partedit and then gpart and newfs from there=2E This= =20 way I can align to 1 or 2 MB=2C enable TRIM and disable journaling=2C and= =20 make use of all options someone desires=2E Also I tried using the shell at the end of the install to disable=20 journaling=2C but this cannot be done since /mnt is busy=2E Just rebooting to single user mode after the install and then tunefs -j=20= disable /dev/ada0p2 works for me=2E Replace ada0 with the device your disk is on=2C p2 is the defalt partition= =20 for / After a reboot then I just removed /=2Esujournal Still I have send a pr with patch to change the default=2C let=27s see what= =20 goes=2E This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 10:20:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4980A36 for ; Sun, 4 Nov 2012 10:20:49 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id B5D548FC08 for ; Sun, 4 Nov 2012 10:20:49 +0000 (UTC) Received: from [192.168.15.220] (gw.digitalspark.net [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 07318BBAAC; Sun, 4 Nov 2012 05:20:41 -0500 (EST) Message-ID: <5096417E.20703@ateamsystems.com> Date: Sun, 04 Nov 2012 17:20:46 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <20121102183123.GA22755@dft-labs.eu> In-Reply-To: <20121102183123.GA22755@dft-labs.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bas Smeelen , Mike Jakubik , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 10:20:50 -0000 On 11/3/2012 1:31, Mateusz Guzik wrote: > Currently when you try to take a snapshot, the kernel checks whether SUJ > is enabled on specified mount-point, and if yes it returns EOPNOTSUPP. > > See this commit (MFCed as r230725): > http://svnweb.freebsd.org/base?view=revision&revision=230250 Ahhh excellent to hear. I partition manually these days with 9.0-R because most servers are either using gmirror, which I want setup before the install, or a RAID card which means partitions need to be aligned to the stripe boundaries. So I just "newfs -U -L" and keep journaling off and wouldn't have realized there is at least some mitigation that will make it into 9.1-R. I still stand by my feeling that it should not be on by default though, because it breaks snapshots and by extension dump -L which I consider to be a pretty awesome feature of FreeBSD. If you have partitions with enabled it means booting up in single user to undo it which is a hassle for a server if it's in production (I realize that's a bit whiny :P). -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 10:25:15 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6853B5E; Sun, 4 Nov 2012 10:25:15 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from smh05.opentransfer.com (smh05.opentransfer.com [98.130.1.173]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3AD8FC14; Sun, 4 Nov 2012 10:25:15 +0000 (UTC) Received: by smh05.opentransfer.com (Postfix, from userid 8) id D8F0B8E6FC; Sun, 4 Nov 2012 05:25:08 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on smh05.opentransfer.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=RDNS_NONE autolearn=disabled version=3.2.5 Received: from webmail7.opentransfer.com (unknown [69.49.230.6]) by smh05.opentransfer.com (Postfix) with ESMTP id BE4108E6F3; Sun, 4 Nov 2012 05:25:08 -0500 (EST) Received: from webmail7.opentransfer.com (webmail7.opentransfer.com [127.0.0.1]) by webmail7.opentransfer.com (8.13.8/8.13.8) with ESMTP id qA4AP8Nm016137; Sun, 4 Nov 2012 05:25:08 -0500 Received: (from nobody@localhost) by webmail7.opentransfer.com (8.13.8/8.13.8/Submit) id qA4AP8Ot016136; Sun, 4 Nov 2012 12:25:08 +0200 X-Authentication-Warning: webmail7.opentransfer.com: nobody set sender to oleg@opentransfer.com using -f Received: from 92-49-244-190.dynamic.peoplenet.ua (92-49-244-190.dynamic.peoplenet.ua [92.49.244.190]) by webmail.opentransfer.com (Horde Framework) with HTTP; for ; Sun, 04 Nov 2012 12:25:08 +0200 X-Opentransfer-Authenticated: oleg@opentransfer.com Message-ID: <20121104122508.12113ue1iu4bryio@webmail7.opentransfer.com> Date: Sun, 04 Nov 2012 12:25:08 +0200 From: "Oleg V. Nauman" To: Dimitry Andric Subject: Re: WITH_LIBCPLUSPLUS buildworld broken on STABLE-9 References: <20121102202258.12004cox9k4zrq0w@webmail7.opentransfer.com> <5095AAE1.5070901@FreeBSD.org> In-Reply-To: <5095AAE1.5070901@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 92.49.244.190 Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 10:25:15 -0000 Quoting Dimitry Andric : > On 2012-11-02 19:22, Oleg V. Nauman wrote: > ... >> /usr/src/lib/libc++/../../contrib/libc++/include/cstdlib:134:9: error: >> no member named >> 'at_quick_exit' in the global namespace >> using ::at_quick_exit; >> ~~^ > > This was fixed in head by r242472, I will merge it as soon as the MFC > timer expires (Nov 5). Sorry about the breakage, this was my fault. No problem. Thanks for your hard work. > > In the meantime, you can use the attached diff. > That patch fixes the issue, thank you. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 10:25:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 454E6C5F for ; Sun, 4 Nov 2012 10:25:51 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id D52838FC0A for ; Sun, 4 Nov 2012 10:25:50 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TUxOv-000722-BZ for freebsd-stable@freebsd.org; Sun, 04 Nov 2012 11:25:57 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2012 11:25:57 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2012 11:25:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: freebsd-update and sources of 9.1-RC3 Date: Sun, 4 Nov 2012 10:25:38 +0000 (UTC) Lines: 97 Message-ID: References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> <50961FF1.9010605@ose.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 10:25:51 -0000 Bas Smeelen ose.nl> writes: > ... > Can't this be accomplished by setting > StrictComponents yes > in /etc/freebsd-update.conf ? > > Then feebsd-update does not try to figure out the components to update > by itself, but updates the components mentioned in > Components src world kernel > > I didn't try what happens if no source is installed. Good shot, that could be the "override" option ... I did the test and it did not work out for me. # cat /etc/freebsd-update.conf ... Components src world kernel ... StrictComponents yes ... # # freebsd-update rollback # shutdown -r now # rm -rf /usr/src/ # freebsd-update upgrade -r 9.1-RC3 Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.1-RC2 from update4.FreeBSD.org... done. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Fetching metadata signature for 9.1-RC3 from update4.FreeBSD.org... done. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Inspecting system... done. Preparing to download files... done. The following files will be added as part of updating to 9.1-RC3-p0: /usr/src/release/doc/de_DE.ISO8859-1/early-adopter/article.xml ... The following files will be updated as part of updating to 9.1-RC3-p0: /boot/kernel/hpt27xx.ko /boot/kernel/kernel ... To install the downloaded upgrades, run "/usr/sbin/freebsd-update install". # # freebsd-update install Installing updates... Kernel updates have been installed. Please reboot and run "/usr/sbin/freebsd-update install" again to finish installing updates. # # shutdown -r now # freebsd-update install Installing updates...install: ///usr/src/release/doc/de_DE.ISO8859-1/early-adopt er/article.xml: No such file or directory ... # # ls -al /usr/src/ total 12 drwxr-xr-x 3 root wheel 512 Nov 4 10:17 . drwxr-xr-x 16 root wheel 512 Nov 4 10:17 .. drwxr-xr-x 3 root wheel 512 Nov 4 10:17 release # ls -al /usr/src/release/doc/ total 36 drwxr-xr-x 9 root wheel 512 Nov 4 10:17 . drwxr-xr-x 3 root wheel 512 Nov 4 10:17 .. drwxr-xr-x 3 root wheel 512 Nov 4 10:17 de_DE.ISO8859-1 drwxr-xr-x 3 root wheel 512 Nov 4 10:17 en_US.ISO8859-1 drwxr-xr-x 3 root wheel 512 Nov 4 10:17 fr_FR.ISO8859-1 drwxr-xr-x 3 root wheel 512 Nov 4 10:17 ja_JP.eucJP drwxr-xr-x 3 root wheel 512 Nov 4 10:17 ru_RU.KOI8-R drwxr-xr-x 3 root wheel 512 Nov 4 10:17 share drwxr-xr-x 3 root wheel 512 Nov 4 10:17 zh_CN.GB2312 # ls -al /usr/src/release/doc/de_DE.ISO8859-1/ total 12 drwxr-xr-x 3 root wheel 512 Nov 4 10:17 . drwxr-xr-x 9 root wheel 512 Nov 4 10:17 .. drwxr-xr-x 3 root wheel 512 Nov 4 10:17 share # # shutdown -r now # uname -a FreeBSD localhost.localdomain 9.1-RC3 FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00: 18:27 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i38 6 No luck. Should we file a PR# (there are some error msgs anyway) ? jb From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 10:26:08 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5048D55 for ; Sun, 4 Nov 2012 10:26:08 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 815B78FC0A for ; Sun, 4 Nov 2012 10:26:08 +0000 (UTC) Received: from [192.168.15.220] (gw.digitalspark.net [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 49DACBBAAC; Sun, 4 Nov 2012 05:26:06 -0500 (EST) Message-ID: <509642C2.4000903@ateamsystems.com> Date: Sun, 04 Nov 2012 17:26:10 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Karl Denninger Subject: Re: Why is SU+J undesirable on SSDs? References: <201211032130.PAA04484@lariat.net> <50959B63.9070709@denninger.net> In-Reply-To: <50959B63.9070709@denninger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brett Glass , stable@freebsd.org, Jeff Roberson X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 10:26:08 -0000 On 11/4/2012 5:32, Karl Denninger wrote: > It is utter insanity to enable, by default, filesystem options that > break _*the canonical backup solution*_ in the handbook ("dump", when > used with "-L", which it must be to dump a live filesystem SAFELY.) Exactly. -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 10:55:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F27D2368 for ; Sun, 4 Nov 2012 10:55:49 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 823FD8FC14 for ; Sun, 4 Nov 2012 10:55:49 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Sun, 4 Nov 2012 11:55:48 +0100 Message-ID: <509649B3.70700@ose.nl> Date: Sun, 04 Nov 2012 11:55:47 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: freebsd-update and sources of 9.1-RC3 References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> <50961FF1.9010605@ose.nl> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 10:55:50 -0000 On 11/04/2012 11=3A25 AM=2C jb wrote=3A =3E Bas Smeelen =3Cb=2Esmeelen =3Cat=3E ose=2Enl=3E writes=3A =3E =3E=3E =2E=2E=2E =3E=3E Can=27t this be accomplished by setting =3E=3E StrictComponents yes =3E=3E in /etc/freebsd-update=2Econf =3F =3E=3E =3E=3E Then feebsd-update does not try to figure out the components to upda= te =3E=3E by itself=2C but updates the components mentioned in =3E=3E Components src world kernel =3E=3E =3E=3E I didn=27t try what happens if no source is installed=2E =3E Good shot=2C that could be the =22override=22 option =2E=2E=2E =3E =3E I did the test and it did not work out for me=2E OK=2C well this could have been expected because freebsd-update is meant=20= to update the components on a system and not to install new components=2E= =20 On the update servers there are delta binaries present but not full=20 binaries =28or archives=29 to add new components=2E See further below=2E =3E =3E =23 cat /etc/freebsd-update=2Econf =3E =2E=2E=2E =3E Components src world kernel =3E =2E=2E=2E =3E StrictComponents yes =3E =2E=2E=2E =3E =23 =3Csnip=3E =3E =3E =23 uname -a =3E FreeBSD localhost=2Elocaldomain 9=2E1-RC3 FreeBSD 9=2E1-RC3 =230 r24232= 4=3A Tue Oct 30 00=3A =3E 18=3A27 UTC 2012 root=40obrian=2Ecse=2Ebuffalo=2Eedu=3A/usr/obj/usr= /src/sys/GENERIC i38 =3E 6 =3E =3E No luck=2E Should we file a PR=23 =28there are some error msgs anyway= =29 =3F =3E jb To file a PR it will require some work to find out exactly what the PR=20= should be about=2E Since freebsd-update is meant to update the system I don=27t really see a= =20 point to make it install sources =28or others things=29 if they are not=20= present on the system being updated=2E To get the sources you can always use csup and set default release=3Dcvs tag=3DRELENG=5F9=5F1 or use subversion This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 10:59:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26AC74D6 for ; Sun, 4 Nov 2012 10:59:40 +0000 (UTC) (envelope-from prabhpal@digital-infotech.net) Received: from mail.digital-infotech.net (mail.digital-infotech.net [41.211.25.193]) by mx1.freebsd.org (Postfix) with ESMTP id B6A118FC0A for ; Sun, 4 Nov 2012 10:59:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id D8ACD2E4101 for ; Sun, 4 Nov 2012 10:56:33 +0000 (GMT) Received: from mail.digital-infotech.net ([127.0.0.1]) by localhost (mail.digital-infotech.net [127.0.0.1]) (maiad, port 10024) with ESMTP id 01398-04 for ; Sun, 4 Nov 2012 10:56:33 +0000 (GMT) Received: from mail.digital-infotech.net (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id AC2272E404A for ; Sun, 4 Nov 2012 10:56:33 +0000 (GMT) X-DKIM: OpenDKIM Filter v2.5.0 mail.digital-infotech.net AC2272E404A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digital-infotech.net; s=digital; t=1352026593; bh=BxD0g3QeC25cB7HHmXnNK9mo9feRyRSLefeUREX4P70=; h=Date:Subject:From:To:Reply-To; b=KCpIdNkn9Ouyw4zSY4jNjIHFEu4ChisUg8VXfsf81662wqd5/SH+z5OLRSggMmFoM KfSrcd5/mMmVFHXB071meqy1HgMn3alHNl/o7kiGHgF5Fb6zxr3QiPlqg4YP5hFMOC qqGSfN3D6C3y6M30QmzsfULawXwEQa/yVHw2Ssys= Received: from 41.211.0.76 (SquirrelMail authenticated user prabhpal@digital-infotech.net) by mail.digital-infotech.net with HTTP; Sun, 4 Nov 2012 10:56:33 -0000 Message-ID: Date: Sun, 4 Nov 2012 10:56:33 -0000 Subject: Failed to attach P_CNT - FreeBSD 9.1 RC3 From: "Shiv. Nath" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: prabhpal@digital-infotech.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 10:59:40 -0000 Dear FreeBSD Community Friends, It is FreeBSD 9.1 RC3, i get the following warning in the message log file. i need assistance to understand the meaning of this error, how serious is it? acpi_throttle23: failed to attach P_CNT History: This error is following FreeBSD for long time because when i was googled the error. i can across a post that was belongs to FreeBSD 6x. http://tgrove.com/2007/10/07/freebsd-6-acpi_throttle1-failed-to-attach-p_cnt/ They Provided the solution as well but did not work. They also said that is is only happening with Intel dual core processor but that is not true. As it is virtual machine, i tried to restore the FreeBSD VM on three different servers, those having different specification of processors (dual cores, quad cores, six cores) still the same then decided to consult with experts. Following was the solution but did not remove the error/warning vi /boot/device.hints # Add this to the end of the file hint.acpi_throttle.0.disabled="1" vi /boot/loader.conf # Add this to the end of the file hint.acpi_throttle.0.disabled=”1″ Thanks / Shiv. Nath From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 11:08:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7877678 for ; Sun, 4 Nov 2012 11:08:37 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 543F48FC0A for ; Sun, 4 Nov 2012 11:08:37 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TUy4I-00074o-J4 for freebsd-stable@freebsd.org; Sun, 04 Nov 2012 12:08:44 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2012 12:08:42 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2012 12:08:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: freebsd-update and sources of 9.1-RC3 Date: Sun, 4 Nov 2012 11:08:19 +0000 (UTC) Lines: 28 Message-ID: References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> <50961FF1.9010605@ose.nl> <509649B3.70700@ose.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 11:08:37 -0000 Bas Smeelen ose.nl> writes: > ... > To file a PR it will require some work to find out exactly what the PR > should be about. > Since freebsd-update is meant to update the system I don't really see a > point to make it install sources (or others things) if they are not > present on the system being updated. > ... Well, that proves my earlier point. But, you brought up that "StrictComponents yes" option and we have to figure out what it means ... # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which FreeBSD Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no The components are: Components src world kernel Then what gives ? Does it not apply to src component ? jb From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 11:23:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7F71CBA for ; Sun, 4 Nov 2012 11:23:36 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 72B558FC08 for ; Sun, 4 Nov 2012 11:23:35 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Sun, 4 Nov 2012 12:23:34 +0100 Message-ID: <50965035.8030508@ose.nl> Date: Sun, 04 Nov 2012 12:23:33 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: freebsd-update and sources of 9.1-RC3 References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> <50961FF1.9010605@ose.nl> <509649B3.70700@ose.nl> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 11:23:37 -0000 On 11/04/2012 12=3A08 PM=2C jb wrote=3A =3E Bas Smeelen =3Cb=2Esmeelen =3Cat=3E ose=2Enl=3E writes=3A =3E =3E=3E =2E=2E=2E =3E=3E To file a PR it will require some work to find out exactly what the= PR =3E=3E should be about=2E =3E=3E Since freebsd-update is meant to update the system I don=27t really= see a =3E=3E point to make it install sources =28or others things=29 if they are= not =3E=3E present on the system being updated=2E =3E=3E =2E=2E=2E =3E Well=2C that proves my earlier point=2E You are right=2E =3E =3E But=2C you brought up that =22StrictComponents yes=22 option and we hav= e to figure =3E out what it means =2E=2E=2E From looking at the freebsd-update script =28it=27s in /usr/sbin=29 I=20= understand when StrictComponents is set to yes it skips the step=2C=20 inspecting system=2E=2E=2E=2E and uses the list provided in freebsd-update= =2Econf=2C=20 so this option might save some time and disk activity=2E I don=27t fully understand what the impact might be when running a custom= =20 kernel=2E =3E =3E =23 When upgrading between releases=2C should the list of Components be= =3E =23 read strictly =28StrictComponents yes=29 or merely as a list of com= ponents =3E =23 which *might* be installed of which FreeBSD Update should figure ou= t =3E =23 which actually are installed and upgrade those =28StrictComponents= no=29=3F =3E =23 StrictComponents no =3E =3E The components are=3A =3E Components src world kernel =3E =3E Then what gives =3F Does it not apply to src component =3F =3E jb =3E =3E This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 12:13:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F24693C; Sun, 4 Nov 2012 12:13:44 +0000 (UTC) (envelope-from hatanou@infolab.ne.jp) Received: from moon.infolab.ne.jp (unknown [IPv6:2001:3e0:90c::1]) by mx1.freebsd.org (Postfix) with ESMTP id DCEE48FC0A; Sun, 4 Nov 2012 12:13:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by moon.infolab.ne.jp (8.14.5/8.14.5) with ESMTP id qA4CDb0X035948; Sun, 4 Nov 2012 21:13:37 +0900 (JST) (envelope-from hatanou@infolab.ne.jp) Date: Sun, 04 Nov 2012 21:13:36 +0900 (JST) Message-Id: <20121104.211336.244701604.hatanou@infolab.ne.jp> To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO From: HATANO Tomomi In-Reply-To: <5095B89F.4070705@freebsd.org> References: <20121103190930.GA23145@icarus.home.lan> <5095B89F.4070705@freebsd.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Nov__4_21_13_36_2012_719)--" Content-Transfer-Encoding: 7bit Cc: jdc@koitsu.org, b.smeelen@ose.nl, fnwhitehorn@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:13:44 -0000 ----Next_Part(Sun_Nov__4_21_13_36_2012_719)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all. The point is: There is completely no way to take a snapshot of SU+J partition unless modify one's kernel. Whether some issue still exist or not, how about enabling snapshoting SU+J partition through sysctl variable? Would you mind to see patch attached? 1. Taking a snapshot of SU+J partition is controlled through sysctl variable. 2. Default to disable. One who want to enable it should set the variable manually. 3. The default value in bsdinstall(8) may be left as is. -- HATANO Tomomi. ----Next_Part(Sun_Nov__4_21_13_36_2012_719)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="snapsuj.patch" --- src/sys/ufs/ffs/ffs_snapshot.c.orig 2012-11-04 11:01:58.000000000 +0900 +++ src/sys/ufs/ffs/ffs_snapshot.c 2012-11-04 11:13:32.000000000 +0900 @@ -182,8 +182,10 @@ */ int dopersistence = 0; -#ifdef DEBUG #include +int snapsuj = 0; +SYSCTL_INT(_debug, OID_AUTO, snapsuj, CTLFLAG_RW, &snapsuj, 0, ""); +#ifdef DEBUG SYSCTL_INT(_debug, OID_AUTO, dopersistence, CTLFLAG_RW, &dopersistence, 0, ""); static int snapdebug = 0; SYSCTL_INT(_debug, OID_AUTO, snapdebug, CTLFLAG_RW, &snapdebug, 0, ""); @@ -230,7 +232,7 @@ * At the moment, journaled soft updates cannot support * taking snapshots. */ - if (MOUNTEDSUJ(mp)) { + if (MOUNTEDSUJ(mp) && (snapsuj == 0)) { vfs_mount_error(mp, "%s: Snapshots are not yet supported when " "running with journaled soft updates", fs->fs_fsmnt); return (EOPNOTSUPP); ----Next_Part(Sun_Nov__4_21_13_36_2012_719)---- From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 12:42:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BC8E131 for ; Sun, 4 Nov 2012 12:42:44 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 921728FC12 for ; Sun, 4 Nov 2012 12:42:42 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Sun, 4 Nov 2012 13:42:39 +0100 Message-ID: <509662BE.3070600@ose.nl> Date: Sun, 04 Nov 2012 13:42:38 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO References: <20121103190930.GA23145@icarus.home.lan> <5095B89F.4070705@freebsd.org> <20121104.211336.244701604.hatanou@infolab.ne.jp> In-Reply-To: <20121104.211336.244701604.hatanou@infolab.ne.jp> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:42:44 -0000 On 11/04/2012 01=3A13 PM=2C HATANO Tomomi wrote=3A =3E Hi all=2E =3E =3E The point is=3A =3E =3E There is completely no way to take a snapshot of SU+J partition =3E unless modify one=27s kernel=2E =3E =3E Whether some issue still exist or not=2C =3E how about enabling snapshoting SU+J partition =3E through sysctl variable=3F =3E =3E Would you mind to see patch attached=3F =3E =3E 1=2E Taking a snapshot of SU+J partition is controlled through sysctl v= ariable=2E =3E =3E 2=2E Default to disable=2E =3E One who want to enable it should set the variable manually=2E =3E =3E 3=2E The default value in bsdinstall=288=29 may be left as is=2E Hi If I understand correctly this still leaves your default installed=20 system with SU+J and if you set the sysctl variable it means okay I am=20= prepared for trouble when taking a snapshot of a SU+J filesystem=3F Why would I want a sysctl variable that gives me known trouble=3F Or have I misread your patch=3F When taking a snapshot of a SU+J filesystem we already get the nice not=20= supported error instead of getting into trouble=2E I think SU+J should not be default unless it works fine with the rest of=20= the system as described in the handbook=2E This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 13:09:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0847DAB3 for ; Sun, 4 Nov 2012 13:09:18 +0000 (UTC) (envelope-from hatanou@infolab.ne.jp) Received: from moon.infolab.ne.jp (unknown [IPv6:2001:3e0:90c::1]) by mx1.freebsd.org (Postfix) with ESMTP id 699FF8FC0A for ; Sun, 4 Nov 2012 13:09:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by moon.infolab.ne.jp (8.14.5/8.14.5) with ESMTP id qA4D9Fmr044434; Sun, 4 Nov 2012 22:09:15 +0900 (JST) (envelope-from hatanou@infolab.ne.jp) Date: Sun, 04 Nov 2012 22:09:14 +0900 (JST) Message-Id: <20121104.220914.375550153.hatanou@infolab.ne.jp> To: b.smeelen@ose.nl Subject: Re: SU+J on 9.1-RC2 ISO From: HATANO Tomomi In-Reply-To: <509662BE.3070600@ose.nl> References: <5095B89F.4070705@freebsd.org> <20121104.211336.244701604.hatanou@infolab.ne.jp> <509662BE.3070600@ose.nl> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:09:18 -0000 Hi Bas, thank you for your response. >When taking a snapshot of a SU+J filesystem we already get the nice not >supported error instead of getting into trouble. It's not nice. Hiding problem will never solve problem. Currently we have no choice. If we have a way to choose (e.g. through sysctl), one who want to use can test it. -- HATANO Tomomi From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 13:24:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F6E7ED8 for ; Sun, 4 Nov 2012 13:24:09 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 48BA48FC16 for ; Sun, 4 Nov 2012 13:24:08 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TV0BL-0004Ul-Md for freebsd-stable@freebsd.org; Sun, 04 Nov 2012 05:24:07 -0800 Date: Sun, 4 Nov 2012 05:24:07 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1352035447442-5757907.post@n5.nabble.com> In-Reply-To: <201211032130.PAA04484@lariat.net> References: <201211032130.PAA04484@lariat.net> Subject: Re: Why is SU+J undesirable on SSDs? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:24:09 -0000 Imho, at least wiki page (http://wiki.freebsd.org/) on setting up FreeBSD on SSDs is needed. Lots of confusion and different opinions (sector size!)... -- View this message in context: http://freebsd.1045724.n5.nabble.com/Why-is-SU-J-undesirable-on-SSDs-tp5757733p5757907.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 14:43:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D216B57 for ; Sun, 4 Nov 2012 14:43:58 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 930248FC12 for ; Sun, 4 Nov 2012 14:43:57 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qA4EhpdH073579 for ; Sun, 4 Nov 2012 09:43:56 -0500 (EST) (envelope-from george@m5p.com) Message-ID: <50967F27.80909@m5p.com> Date: Sun, 04 Nov 2012 09:43:51 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120923 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO References: <20121103190930.GA23145@icarus.home.lan> In-Reply-To: <20121103190930.GA23145@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 04 Nov 2012 09:43:56 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 14:43:58 -0000 On 11/03/12 15:09, Jeremy Chadwick wrote: > (Please keep me CC'd, as I'm not subscribed to -stable) > > I've CC'd Nathan Whitehorn, who according to bsdinstall(8) is the > author (not sure if maintainer) of the code. > > This default has already begun to bite users/SAs in the ass: > > http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html > > SU+J (the journalling part specifically) needs to be disabled by default > in the installer. This default was a very bad choice and should not > have been done. It either indicates someone was out of touch with the > rest of the issues surrounding the feature, or that someone > intentionally decided "it's the best way to get people using it for > testing" (I have seen this justification presented in the past, and it > is the wrong approach). > > However, since some people DO want it (and those folks don't use dump), > the installer should be modified to make SU+J support toggleable via a a > checkbox. The default, obviously, should be unchecked. > > If the user checks the checkbox, an ominous warning message should be > displayed informing the user of the repercussions. The only option at > that point should be "OK", after which the checkbox is checked. > > Do not tell me "send patches". This issue/problem has gone on long > enough, and the community bitched hard/long enough, that the person who > committed this default should be responsible for fixing it. > > We should operate under the assumption that this bug/problem will never > be fixed. It probably will be, but again, we must operate with the > assumption that Kirk et al will require years to fix it. (It has > already been something like 9 months. Or is it a year?) > > [...] I will give this comment a BIG, BIG, +1! -- George From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 15:09:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDF54802 for ; Sun, 4 Nov 2012 15:09:56 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 71C8E8FC0A for ; Sun, 4 Nov 2012 15:09:56 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Sun, 4 Nov 2012 16:09:53 +0100 Message-ID: <50968540.4010105@ose.nl> Date: Sun, 04 Nov 2012 16:09:52 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO References: <20121103190930.GA23145@icarus.home.lan> <50967F27.80909@m5p.com> In-Reply-To: <50967F27.80909@m5p.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:09:56 -0000 On 11/04/2012 03=3A43 PM=2C George Mitchell wrote=3A =3E On 11/03/12 15=3A09=2C Jeremy Chadwick wrote=3A =3E=3E =28Please keep me CC=27d=2C as I=27m not subscribed to -stable=29 =3E=3E =3E=3E I=27ve CC=27d Nathan Whitehorn=2C who according to bsdinstall=288=29= is the =3E=3E author =28not sure if maintainer=29 of the code=2E =3E=3E =3E=3E This default has already begun to bite users/SAs in the ass=3A =3E=3E =3E=3E http=3A//lists=2Efreebsd=2Eorg/pipermail/freebsd-questions/2012-Nove= mber/246069=2Ehtml=20 =3E=3E =3E=3E =3E=3E SU+J =28the journalling part specifically=29 needs to be disabled by= default =3E=3E in the installer=2E This default was a very bad choice and should n= ot =3E=3E have been done=2E It either indicates someone was out of touch with= the =3E=3E rest of the issues surrounding the feature=2C or that someone =3E=3E intentionally decided =22it=27s the best way to get people using it= for =3E=3E testing=22 =28I have seen this justification presented in the past= =2C and it =3E=3E is the wrong approach=29=2E =3E=3E =3E=3E However=2C since some people DO want it =28and those folks don=27t u= se dump=29=2C =3E=3E the installer should be modified to make SU+J support toggleable via= a a =3E=3E checkbox=2E The default=2C obviously=2C should be unchecked=2E =3E=3E =3E=3E If the user checks the checkbox=2C an ominous warning message should= be =3E=3E displayed informing the user of the repercussions=2E The only optio= n at =3E=3E that point should be =22OK=22=2C after which the checkbox is checked= =2E =3E=3E =3E=3E Do not tell me =22send patches=22=2E This issue/problem has gone on= long =3E=3E enough=2C and the community bitched hard/long enough=2C that the per= son who =3E=3E committed this default should be responsible for fixing it=2E =3E=3E =3E=3E We should operate under the assumption that this bug/problem will ne= ver =3E=3E be fixed=2E It probably will be=2C but again=2C we must operate wit= h the =3E=3E assumption that Kirk et al will require years to fix it=2E =28It ha= s =3E=3E already been something like 9 months=2E Or is it a year=3F=29 =3E=3E =3E=3E =5B=2E=2E=2E=5D =3E =3E I will give this comment a BIG=2C BIG=2C +1! -- Georg= e A small patch already sent via pr http=3A//www=2Efreebsd=2Eorg/cgi/query-pr=2Ecgi=3Fpr=3D173301 Let=27s see what goes This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 15:58:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A55746FE for ; Sun, 4 Nov 2012 15:58:02 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp1.sbb.rs (smtp1.sbb.rs [89.216.2.33]) by mx1.freebsd.org (Postfix) with ESMTP id 185A38FC14 for ; Sun, 4 Nov 2012 15:58:01 +0000 (UTC) Received: from mycenae (cable-178-148-98-90.dynamic.sbb.rs [178.148.98.90]) by smtp1.sbb.rs (8.14.0/8.14.0) with ESMTP id qA4FXp4m007941 for ; Sun, 4 Nov 2012 16:33:56 +0100 Received: by mycenae (Postfix, from userid 1001) id 226255C2F; Sun, 4 Nov 2012 16:33:55 +0100 (CET) Date: Sun, 4 Nov 2012 16:33:54 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO Message-ID: <20121104153354.GA1187@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:58:02 -0000 > Just rebooting to single user mode after the install and then tunefs -j > disable /dev/ada0p2 works for me. > After a reboot then I just removed /.sujournal That crystillized to me as a correct way in this situation. Just one "fsck" at the very beginning? Manual says about some options available after it only. People mostly mention journaling for servers. Anybody using 9.x on laptop with ssd? Thanks all for help, regarding this option. Zoran From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 16:28:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 048BFBBA for ; Sun, 4 Nov 2012 16:28:17 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 883488FC0A for ; Sun, 4 Nov 2012 16:28:16 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Sun, 4 Nov 2012 17:28:13 +0100 Message-ID: <5096979C.2040703@ose.nl> Date: Sun, 04 Nov 2012 17:28:12 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO References: <20121104153354.GA1187@mycenae.sbb.rs> In-Reply-To: <20121104153354.GA1187@mycenae.sbb.rs> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 16:28:17 -0000 On 11/04/2012 04=3A33 PM=2C Zoran Kolic wrote=3A =3E=3E Just rebooting to single user mode after the install and then tunefs= -j =3E=3E disable /dev/ada0p2 works for me=2E =3E=3E After a reboot then I just removed /=2Esujournal =3E That crystillized to me as a correct way in this situation=2E =3E Just one =22fsck=22 at the very beginning=3F Manual says about =3E some options available after it only=2E I did not fsck just disable journaling for soft updates reboot and=20 delete =2E/sujournal =3E People mostly mention journaling for servers=2E Anybody using =3E 9=2Ex on laptop with ssd=3F =3E Thanks all for help=2C regarding this option=2E I don=27t have a laptop with ssd Journaling SU is not recommended because of the extra writes but=20 nowadays ssd should be fine with it=2C though less writes is less wear=2E= =20 Just take care to align your partitions to 1 or 2 MB which can be=20 accomplished by going to shell on the partedit part of bsdinstall and=20 use gpart -a or gpart -b This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 17:28:19 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECD6AC57 for ; Sun, 4 Nov 2012 17:28:19 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 31CCE8FC08 for ; Sun, 4 Nov 2012 17:28:18 +0000 (UTC) Received: (qmail 44953 invoked by uid 89); 4 Nov 2012 17:28:17 -0000 Received: by simscan 1.4.0 ppid: 44948, pid: 44950, t: 0.0866s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15536 Received: from unknown (HELO linux-wb36.example.org) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 4 Nov 2012 17:28:17 -0000 Date: Sun, 4 Nov 2012 18:28:13 +0100 From: Rainer Duffner To: Rick Miller Subject: Re: FreeBSD 9.1 stability/robustness? Message-ID: <20121104182813.304419d9@linux-wb36.example.org> In-Reply-To: References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; i586-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:28:20 -0000 Am Sat, 3 Nov 2012 21:56:45 -0400 schrieb Rick Miller : > On Fri, Nov 2, 2012 at 4:10 AM, Rainer Duffner > wrote: > > Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) > > schrieb Brett Glass : > > > >> I need to build up a few servers and routers, and am wondering how > >> FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > >> robust than 9.0-RELEASE? Are there issues that will have to wait > >> until 9.2-RELEASE to be fixed? Opinions welcome. > > > > > > If I'm not mistaken, the bge-stuff that makes the default NICs ins > > HP G8 servers (360+380) actually run will not make it back into 9.1. > > Intel cards work much better anyway... > > I have a blog post at > http://blog.hostileadmin.com/2012/06/14/freebsd-on-hp-proliant-dl360p-g8-servers/ > which touches on this. It comes up invariably once you google for "FreeBSD DL 380 G8"... > I heard as recently as today that the fixes > for the BCM5719 and 5720 were recently committed to -CURRENT. It's > too late for them to be rolled into 9.1. Not sure if they'll be > committed to to stable/8 or not, but if so they could make it into > 8.4-R. Oh - will were be an 8.4 release? That would be interesting. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 17:58:41 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0E99520 for ; Sun, 4 Nov 2012 17:58:41 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 59F378FC14 for ; Sun, 4 Nov 2012 17:58:41 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id KAA14121; Sun, 4 Nov 2012 10:58:05 -0700 (MST) Message-Id: <201211041758.KAA14121@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 10:58:03 -0700 To: Rainer Duffner , Rick Miller From: Brett Glass Subject: Re: FreeBSD 9.1 stability/robustness? In-Reply-To: <20121104182813.304419d9@linux-wb36.example.org> References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> <20121104182813.304419d9@linux-wb36.example.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:58:41 -0000 At 10:28 AM 11/4/2012, Rainer Duffner wrote: >Oh - will were be an 8.4 release? That would be interesting. I'd like to see a trend toward more point versions of FreeBSD. Particularly in 9.x, because it incorporates most of the items that have been on people's wish lists. 4.11 was one of the most robust and stable releases ever, and I used it for many years. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 18:15:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13CCE76A for ; Sun, 4 Nov 2012 18:15:05 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id C03C58FC08 for ; Sun, 4 Nov 2012 18:15:04 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TV4iu-000Jr8-Bi for stable@freebsd.org; Sun, 04 Nov 2012 19:15:04 +0100 Date: Sun, 4 Nov 2012 19:15:04 +0100 From: Kurt Jaeger To: stable@freebsd.org Subject: Re: FreeBSD 9.1 stability/robustness? Message-ID: <20121104181504.GM12114@home.opsec.eu> References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> <20121104182813.304419d9@linux-wb36.example.org> <201211041758.KAA14121@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201211041758.KAA14121@lariat.net> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 18:15:05 -0000 Hi! > >Oh - will were be an 8.4 release? That would be interesting. > > I'd like to see a trend toward more point versions of FreeBSD. > Particularly in 9.x, because it incorporates most of the items that > have been on people's wish lists. 4.11 was one of the most robust > and stable releases ever, and I used it for many years. I still use 4.11 on two servers 8-} -- pi@opsec.eu +49 171 3101372 8 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 18:53:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADA181ED for ; Sun, 4 Nov 2012 18:53:45 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 52F238FC17 for ; Sun, 4 Nov 2012 18:53:44 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 5E105EC2BF8; Sun, 4 Nov 2012 19:47:38 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 9.8345] X-CRM114-CacheID: sfid-20121104_19473_DD27A69F X-CRM114-Status: Good ( pR: 9.8345 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Nov 4 19:47:38 2012 X-DSPAM-Confidence: 0.6518 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5096b84a362368999711359 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, bytes, 0.00286, (it, 0.00402, the+error, 0.00772, 09+12, 0.00772, error+message, 0.01000, shared+memory, 0.01000, Date*Sun+04, 0.99000, I've+just, 0.01000, is+enabled, 0.01000, 04+16, 0.01000, Date*04+Nov, 0.99000, Date*47+36, 0.99000, Date*19+47, 0.99000, the+latter, 0.01000, enabled, 0.01011, User-Agent*i686, 0.01134, User-Agent*Mozilla/5.0+(X11, 0.01175, User-Agent*Linux+i686, 0.01266, implemented, 0.01432, versions, 0.01464, doesn't, 0.01478, To*stable+freebsd.org, 0.01519, apache, 0.01608, User-Agent*i686+en, 0.01649, To*stable, 0.01721, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id AD4D7EC2BEC for ; Sun, 4 Nov 2012 19:47:37 +0100 (CET) Message-ID: <5096B848.60801@fsn.hu> Date: Sun, 04 Nov 2012 19:47:36 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: mod_fcgid doesn't work in 9-stable jails after upgrade from 8.x Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 18:53:45 -0000 Hi, I've just tried to upgrade a machine running an older 8-stable to 9-stable@r242549M without success. It runs an apache with mod_fcgid in a jail and the latter can't start with the error message of: [Sun Nov 04 16:09:12 2012] [emerg] (78)Function not implemented: mod_fcgid: Can't create shared memory for size 1192488 bytes security.jail.sysvipc_allowed is enabled (it was needed on 8.x too), nothing else has changed. There are some reports from this, but from earlier versions, and the only confirmed solution was sysvipc_allowed, which works for 8.x, but doesn't with the above version. Any ideas? From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 19:05:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0E1C45B for ; Sun, 4 Nov 2012 19:05:42 +0000 (UTC) (envelope-from freebsd-stable@chef-ingenieur.de) Received: from mail.webmatic.de (mail.webmatic.de [IPv6:2a00:1d08:0:403::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4778FC08 for ; Sun, 4 Nov 2012 19:05:42 +0000 (UTC) Received: from [127.0.0.1] (p54B7AEEF.dip.t-dialin.net [84.183.174.239]) by mail.webmatic.de (Postfix) with ESMTPSA id 278378A04F for ; Sun, 4 Nov 2012 20:05:44 +0100 (CET) Message-ID: <5096BC83.8000005@chef-ingenieur.de> Date: Sun, 04 Nov 2012 20:05:39 +0100 From: Thomas Krause User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1-RC3 not booting References: <1351973965.39027.14.camel@neo.cse.buffalo.edu> In-Reply-To: <1351973965.39027.14.camel@neo.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:05:42 -0000 Hi, after upgrading Kernel from 9.1-RC2 # freebsd-update upgrade -r 9.1-RC3 # freebsd-update install # shutdown -r now the Kernel ist not booting. It just reboot's after the boot loader. There no kernel.old. Safe mode also reboots. What can I do to recover the machine? (It was booting/running fine with 9.1-RC2) Thanks for any help! Regards, Thomas. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 19:48:10 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26948DD; Sun, 4 Nov 2012 19:48:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id D45598FC17; Sun, 4 Nov 2012 19:48:09 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qA4Jm95V066565; Sun, 4 Nov 2012 19:48:09 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qA4Jm942066560; Sun, 4 Nov 2012 19:48:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Nov 2012 19:48:09 GMT Message-Id: <201211041948.qA4Jm942066560@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9_1 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:48:10 -0000 TB --- 2012-11-04 19:42:16 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-04 19:42:16 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-04 19:42:16 - starting RELENG_9_1 tinderbox run for mips/mips TB --- 2012-11-04 19:42:16 - cleaning the object tree TB --- 2012-11-04 19:42:16 - checking out /src from svn://svn.freebsd.org/base/releng/9.1 TB --- 2012-11-04 19:42:16 - cd /tinderbox/RELENG_9_1/mips/mips TB --- 2012-11-04 19:42:16 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:43:08 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:43:08 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:43:08 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:43:38 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:43:38 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:43:38 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 19:44:38 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:44:38 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:44:38 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 19:46:08 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:46:08 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:46:08 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 19:48:08 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:48:09 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:48:09 - ERROR: unable to check out the source tree TB --- 2012-11-04 19:48:09 - 3.87 user 4.41 system 352.80 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 19:53:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6F1F74E; Sun, 4 Nov 2012 19:53:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 4BA9E8FC08; Sun, 4 Nov 2012 19:53:34 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qA4JrXfP089270; Sun, 4 Nov 2012 19:53:33 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qA4JrXHs089269; Sun, 4 Nov 2012 19:53:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Nov 2012 19:53:33 GMT Message-Id: <201211041953.qA4JrXHs089269@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9_1 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:53:34 -0000 TB --- 2012-11-04 19:48:09 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-04 19:48:09 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-04 19:48:09 - starting RELENG_9_1 tinderbox run for powerpc/powerpc TB --- 2012-11-04 19:48:09 - cleaning the object tree TB --- 2012-11-04 19:48:09 - checking out /src from svn://svn.freebsd.org/base/releng/9.1 TB --- 2012-11-04 19:48:09 - cd /tinderbox/RELENG_9_1/powerpc/powerpc TB --- 2012-11-04 19:48:09 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:48:33 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:48:33 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:48:33 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:49:03 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:49:03 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:49:03 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 19:50:03 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:50:03 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:50:03 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 19:51:33 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:51:33 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:51:33 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 19:53:33 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:53:33 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:53:33 - ERROR: unable to check out the source tree TB --- 2012-11-04 19:53:33 - 3.93 user 4.62 system 324.50 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 19:59:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B80AC9DC; Sun, 4 Nov 2012 19:59:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB0D8FC12; Sun, 4 Nov 2012 19:59:03 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qA4Jx2Eg049510; Sun, 4 Nov 2012 19:59:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qA4Jx28m049507; Sun, 4 Nov 2012 19:59:02 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Nov 2012 19:59:02 GMT Message-Id: <201211041959.qA4Jx28m049507@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9_1 tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:59:03 -0000 TB --- 2012-11-04 19:53:34 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-04 19:53:34 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-04 19:53:34 - starting RELENG_9_1 tinderbox run for powerpc64/powerpc TB --- 2012-11-04 19:53:34 - cleaning the object tree TB --- 2012-11-04 19:53:34 - checking out /src from svn://svn.freebsd.org/base/releng/9.1 TB --- 2012-11-04 19:53:34 - cd /tinderbox/RELENG_9_1/powerpc64/powerpc TB --- 2012-11-04 19:53:34 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:54:02 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:54:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:54:02 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:54:32 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:54:32 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:54:32 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 19:55:32 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:55:32 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:55:32 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 19:57:02 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:57:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:57:02 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 19:59:02 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:59:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:59:02 - ERROR: unable to check out the source tree TB --- 2012-11-04 19:59:02 - 3.92 user 4.38 system 328.82 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 20:04:49 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0BF8E64; Sun, 4 Nov 2012 20:04:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 552868FC18; Sun, 4 Nov 2012 20:04:49 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qA4K4m8O074911; Sun, 4 Nov 2012 20:04:48 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qA4K4mNU074907; Sun, 4 Nov 2012 20:04:48 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Nov 2012 20:04:48 GMT Message-Id: <201211042004.qA4K4mNU074907@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9_1 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:04:49 -0000 TB --- 2012-11-04 19:59:03 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-04 19:59:03 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-04 19:59:03 - starting RELENG_9_1 tinderbox run for sparc64/sparc64 TB --- 2012-11-04 19:59:03 - cleaning the object tree TB --- 2012-11-04 19:59:03 - checking out /src from svn://svn.freebsd.org/base/releng/9.1 TB --- 2012-11-04 19:59:03 - cd /tinderbox/RELENG_9_1/sparc64/sparc64 TB --- 2012-11-04 19:59:03 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:59:48 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:59:48 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:59:48 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 20:00:18 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:00:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:00:18 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 20:01:18 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:01:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:01:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 20:02:48 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:02:48 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:02:48 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 20:04:48 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:04:48 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:04:48 - ERROR: unable to check out the source tree TB --- 2012-11-04 20:04:48 - 3.54 user 4.41 system 345.77 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 20:07:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF0BBFF0 for ; Sun, 4 Nov 2012 20:07:07 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 7D44B8FC08 for ; Sun, 4 Nov 2012 20:07:07 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qA4K70hF075819 for ; Sun, 4 Nov 2012 15:07:05 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <5096CAE4.1000900@m5p.com> Date: Sun, 04 Nov 2012 15:07:00 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120923 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: [releng_9_1 tinderbox] failure on powerpc64/powerpc References: <201211041959.qA4Jx28m049507@freebsd-stable.sentex.ca> In-Reply-To: <201211041959.qA4Jx28m049507@freebsd-stable.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 04 Nov 2012 15:07:06 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:07:08 -0000 On 11/04/12 14:59, FreeBSD Tinderbox wrote: > TB --- 2012-11-04 19:53:34 - tinderbox 2.9 running on freebsd-stable.sentex.ca > TB --- 2012-11-04 19:53:34 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 > TB --- 2012-11-04 19:53:34 - starting RELENG_9_1 tinderbox run for powerpc64/powerpc > TB --- 2012-11-04 19:53:34 - cleaning the object tree > TB --- 2012-11-04 19:53:34 - checking out /src from svn://svn.freebsd.org/base/releng/9.1 > TB --- 2012-11-04 19:53:34 - cd /tinderbox/RELENG_9_1/powerpc64/powerpc > TB --- 2012-11-04 19:53:34 - /usr/local/bin/svn cleanup /src > TB --- 2012-11-04 19:54:02 - /usr/local/bin/svn update /src > TB --- 2012-11-04 19:54:02 - WARNING: /usr/local/bin/svn returned exit code 1 > TB --- 2012-11-04 19:54:02 - WARNING: sleeping 30 s and retrying... > TB --- 2012-11-04 19:54:32 - /usr/local/bin/svn update /src > TB --- 2012-11-04 19:54:32 - WARNING: /usr/local/bin/svn returned exit code 1 > TB --- 2012-11-04 19:54:32 - WARNING: sleeping 60 s and retrying... > TB --- 2012-11-04 19:55:32 - /usr/local/bin/svn update /src > TB --- 2012-11-04 19:55:32 - WARNING: /usr/local/bin/svn returned exit code 1 > TB --- 2012-11-04 19:55:32 - WARNING: sleeping 90 s and retrying... > TB --- 2012-11-04 19:57:02 - /usr/local/bin/svn update /src > TB --- 2012-11-04 19:57:02 - WARNING: /usr/local/bin/svn returned exit code 1 > TB --- 2012-11-04 19:57:02 - WARNING: sleeping 120 s and retrying... > TB --- 2012-11-04 19:59:02 - /usr/local/bin/svn update /src > TB --- 2012-11-04 19:59:02 - WARNING: /usr/local/bin/svn returned exit code 1 > TB --- 2012-11-04 19:59:02 - ERROR: unable to check out the source tree > TB --- 2012-11-04 19:59:02 - 3.92 user 4.38 system 328.82 real > > > http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-powerpc64-powerpc.full > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Gosh, I'm SO looking forward to depending on svn instead of csup for software updates. -- George From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 20:10:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B774430F; Sun, 4 Nov 2012 20:10:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2F48FC08; Sun, 4 Nov 2012 20:10:27 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qA4KAQ8M089803; Sun, 4 Nov 2012 20:10:26 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qA4KAQ50089802; Sun, 4 Nov 2012 20:10:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Nov 2012 20:10:26 GMT Message-Id: <201211042010.qA4KAQ50089802@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:10:27 -0000 TB --- 2012-11-04 20:04:49 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-04 20:04:49 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-04 20:04:49 - starting RELENG_9 tinderbox run for amd64/amd64 TB --- 2012-11-04 20:04:49 - cleaning the object tree TB --- 2012-11-04 20:04:49 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2012-11-04 20:04:49 - cd /tinderbox/RELENG_9/amd64/amd64 TB --- 2012-11-04 20:04:49 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 20:05:26 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:05:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:05:26 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 20:05:56 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:05:56 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:05:56 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 20:06:56 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:06:56 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:06:56 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 20:08:26 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:08:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:08:26 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 20:10:26 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:10:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:10:26 - ERROR: unable to check out the source tree TB --- 2012-11-04 20:10:26 - 3.83 user 4.66 system 337.72 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 20:15:59 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0DA84E7; Sun, 4 Nov 2012 20:15:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 536AC8FC12; Sun, 4 Nov 2012 20:15:59 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qA4KFwsk009816; Sun, 4 Nov 2012 20:15:58 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qA4KFwcb009815; Sun, 4 Nov 2012 20:15:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Nov 2012 20:15:58 GMT Message-Id: <201211042015.qA4KFwcb009815@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:15:59 -0000 TB --- 2012-11-04 20:10:27 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-04 20:10:27 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-04 20:10:27 - starting RELENG_9 tinderbox run for arm/arm TB --- 2012-11-04 20:10:27 - cleaning the object tree TB --- 2012-11-04 20:10:27 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2012-11-04 20:10:27 - cd /tinderbox/RELENG_9/arm/arm TB --- 2012-11-04 20:10:27 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 20:10:58 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:10:58 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:10:58 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 20:11:28 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:11:28 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:11:28 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 20:12:28 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:12:28 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:12:28 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 20:13:58 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:13:58 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:13:58 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 20:15:58 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:15:58 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:15:58 - ERROR: unable to check out the source tree TB --- 2012-11-04 20:15:58 - 3.73 user 4.64 system 331.82 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 20:21:42 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B63B065C; Sun, 4 Nov 2012 20:21:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 58AD38FC08; Sun, 4 Nov 2012 20:21:42 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qA4KLfNi053428; Sun, 4 Nov 2012 20:21:41 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qA4KLfqd053425; Sun, 4 Nov 2012 20:21:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 Nov 2012 20:21:41 GMT Message-Id: <201211042021.qA4KLfqd053425@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:21:42 -0000 TB --- 2012-11-04 20:15:59 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-11-04 20:15:59 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-11-04 20:15:59 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2012-11-04 20:15:59 - cleaning the object tree TB --- 2012-11-04 20:15:59 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2012-11-04 20:15:59 - cd /tinderbox/RELENG_9/i386/i386 TB --- 2012-11-04 20:15:59 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 20:16:41 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:16:41 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:16:41 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 20:17:11 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:17:11 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:17:11 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 20:18:11 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:18:11 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:18:11 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 20:19:41 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:19:41 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:19:41 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 20:21:41 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:21:41 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:21:41 - ERROR: unable to check out the source tree TB --- 2012-11-04 20:21:41 - 3.76 user 4.77 system 342.83 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 20:25:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 162247F6 for ; Sun, 4 Nov 2012 20:25:23 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 912E08FC0C for ; Sun, 4 Nov 2012 20:25:22 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so2008039bkc.13 for ; Sun, 04 Nov 2012 12:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T5P9AzfEFQsbqqDHHBgi9ZzsusDnqUFB1Fe9rg1Y2qs=; b=cgYmpnrFbytbrN+ow1cf/YJU+uEuRsfBy/MoFKsJ63r5g9ZBE354r6e3vfsZWQqTct mqUQDlby5XzRniJcSt2UY3Bop59plPf4d0VySwa0SqtxJpxsH7ie9B6hr8d6VqqaM0ZN TI2NvlNB1p3TNMFUQwgVHVaxiRIgC4Umt+Ak9lj2UkCi5k6lDGHnVPPvX94oSqe2JJD7 u9h1TvAb7MlEz9dcXPMNCGAniWHoyzvPY3XInGTlFPMFHuHeVSAXdaE/oxQAE5cZ9bak rKOMyuMZGoO8qenid41wNkHShS7NAPpy5yk6vJfxAGrbHt2jLzTe7mAd3WKa+FST7AW+ hn5w== MIME-Version: 1.0 Received: by 10.205.137.7 with SMTP id im7mr1840130bkc.25.1352060721412; Sun, 04 Nov 2012 12:25:21 -0800 (PST) Received: by 10.204.50.197 with HTTP; Sun, 4 Nov 2012 12:25:21 -0800 (PST) Received: by 10.204.50.197 with HTTP; Sun, 4 Nov 2012 12:25:21 -0800 (PST) In-Reply-To: <5096CAE4.1000900@m5p.com> References: <201211041959.qA4Jx28m049507@freebsd-stable.sentex.ca> <5096CAE4.1000900@m5p.com> Date: Sun, 4 Nov 2012 20:25:21 +0000 Message-ID: Subject: Re: [releng_9_1 tinderbox] failure on powerpc64/powerpc From: Chris Rees To: George Mitchell Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:25:23 -0000 On 4 Nov 2012 20:12, "George Mitchell" wrote: > > On 11/04/12 14:59, FreeBSD Tinderbox wrote: >> >> TB --- 2012-11-04 19:53:34 - tinderbox 2.9 running on freebsd-stable.sentex.ca >> TB --- 2012-11-04 19:53:34 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 >> TB --- 2012-11-04 19:53:34 - starting RELENG_9_1 tinderbox run for powerpc64/powerpc >> TB --- 2012-11-04 19:53:34 - cleaning the object tree >> TB --- 2012-11-04 19:53:34 - checking out /src from svn:// svn.freebsd.org/base/releng/9.1 >> TB --- 2012-11-04 19:53:34 - cd /tinderbox/RELENG_9_1/powerpc64/powerpc >> TB --- 2012-11-04 19:53:34 - /usr/local/bin/svn cleanup /src >> TB --- 2012-11-04 19:54:02 - /usr/local/bin/svn update /src >> TB --- 2012-11-04 19:54:02 - WARNING: /usr/local/bin/svn returned exit code 1 >> TB --- 2012-11-04 19:54:02 - WARNING: sleeping 30 s and retrying... >> TB --- 2012-11-04 19:54:32 - /usr/local/bin/svn update /src >> TB --- 2012-11-04 19:54:32 - WARNING: /usr/local/bin/svn returned exit code 1 >> TB --- 2012-11-04 19:54:32 - WARNING: sleeping 60 s and retrying... >> TB --- 2012-11-04 19:55:32 - /usr/local/bin/svn update /src >> TB --- 2012-11-04 19:55:32 - WARNING: /usr/local/bin/svn returned exit code 1 >> TB --- 2012-11-04 19:55:32 - WARNING: sleeping 90 s and retrying... >> TB --- 2012-11-04 19:57:02 - /usr/local/bin/svn update /src >> TB --- 2012-11-04 19:57:02 - WARNING: /usr/local/bin/svn returned exit code 1 >> TB --- 2012-11-04 19:57:02 - WARNING: sleeping 120 s and retrying... >> TB --- 2012-11-04 19:59:02 - /usr/local/bin/svn update /src >> TB --- 2012-11-04 19:59:02 - WARNING: /usr/local/bin/svn returned exit code 1 >> TB --- 2012-11-04 19:59:02 - ERROR: unable to check out the source tree >> TB --- 2012-11-04 19:59:02 - 3.92 user 4.38 system 328.82 real >> >> >> http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-powerpc64-powerpc.full >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > Gosh, I'm SO looking forward to depending on svn instead of csup for > software updates. The subversion server is being moved; a one off thing. No major drama here. Chris From owner-freebsd-stable@FreeBSD.ORG Sun Nov 4 20:26:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29CB88F7 for ; Sun, 4 Nov 2012 20:26:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D6F338FC15 for ; Sun, 4 Nov 2012 20:26:21 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:dc:ffe:46f:81d2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 052A94AC31; Mon, 5 Nov 2012 00:26:19 +0400 (MSK) Date: Mon, 5 Nov 2012 00:26:12 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <163169416.20121105002612@serebryakov.spb.ru> To: George Mitchell Subject: Re: [releng_9_1 tinderbox] failure on powerpc64/powerpc In-Reply-To: <5096CAE4.1000900@m5p.com> References: <201211041959.qA4Jx28m049507@freebsd-stable.sentex.ca> <5096CAE4.1000900@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:26:22 -0000 Hello, George. You wrote 5 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2012 =D0=B3., 0:07:00: GM> Gosh, I'm SO looking forward to depending on svn instead of csup for GM> software updates. -- George It is planned server outage (migration). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 02:17:02 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7593657C for ; Mon, 5 Nov 2012 02:17:02 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E76588FC0A for ; Mon, 5 Nov 2012 02:17:01 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so4794645lbd.13 for ; Sun, 04 Nov 2012 18:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eYPLywy6HIUMN6gJSKJwouPyHz9v9boh1vag/yPT/hY=; b=LDz/ROQ/xqJZxSuQnPmP6vYwNmpSe9D+sSIV+0dtNP4nNerDCf4JhUoGDjzn8drx6b CBv8gO5JPLWRsZaU0rmeFWnC6R6N4sFnc0ml9jnPNu56xjXhXiJLn7rYSb5F0QgEwEsn O/bDRTgBJGAqbwmbhsEtmxHCgg+crqR433pK/gqeaRXI5fGIahOp1Ys7wNfQQxEd65OM y5OkNQrX2MBHF2NHheem8oTKFvoFQ53v/Mu9bS8mi81QKGnIuQNCSXKyV0hmcfwMYjfT nP214g3jC67atUzYNNKmduNNbmQ3EpW5EhhKV2oy9wGkWQjGzpW+/22dUDFC9xjEtNmF Az3Q== MIME-Version: 1.0 Received: by 10.112.43.34 with SMTP id t2mr3366860lbl.109.1352081820753; Sun, 04 Nov 2012 18:17:00 -0800 (PST) Sender: vrwmiller@gmail.com Received: by 10.112.4.97 with HTTP; Sun, 4 Nov 2012 18:17:00 -0800 (PST) In-Reply-To: <20121104182813.304419d9@linux-wb36.example.org> References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> <20121104182813.304419d9@linux-wb36.example.org> Date: Sun, 4 Nov 2012 21:17:00 -0500 X-Google-Sender-Auth: hbzkNzwdkCdhGnJfu5pMZvTkuW8 Message-ID: Subject: Re: FreeBSD 9.1 stability/robustness? From: Rick Miller To: Rainer Duffner Content-Type: text/plain; charset=ISO-8859-1 Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 02:17:02 -0000 On Sun, Nov 4, 2012 at 12:28 PM, Rainer Duffner wrote: > > Oh - will were be an 8.4 release? That would be interesting. History shows that every release, since 4.x has gone to at least .4. I'd be willing to bet we will see an 8.4. The branch is still being developed. http://en.wikipedia.org/wiki/FreeBSD#Timeline -- Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 08:04:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F43984D for ; Mon, 5 Nov 2012 08:04:30 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93F808FC15 for ; Mon, 5 Nov 2012 08:04:29 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so4899882lag.13 for ; Mon, 05 Nov 2012 00:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=rs01T4lJGqIhLF0XcW9mgglRXxt2c/+KHtsS6c1zHIo=; b=xt+eaeS37uyALPjPahetB6idsRQo2c9+44C9ZoLZjsN7V2MK66HFgajZQoMV4gcZVs FqPpLPTVRwVbt2R5YR+83l1Gvy+rSwJgFov8Q+m8j1O7OlQDzqHw38YXEikOF0odC/th ftp1/JG+8R4gF3NHBi3ylZPE050c1zBvDfkti4sf/oP4Ooh+AZ2lsyTnV+5pcHMV7BpG eh8iHJo1ezAy63f1wn9PuwF/7XBHL2juQhJimK6UMI8itUr58g45evs7r0nm2xVpv1qO kTAfQk3WLFaOkF5Fq7NPjaCP6LXyvJXVuwPiLU/CKGRL2f0NbYsgCODrQp1uuBzkKDTe 9EMA== Received: by 10.112.45.165 with SMTP id o5mr3583220lbm.74.1352102668027; Mon, 05 Nov 2012 00:04:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.57.40 with HTTP; Mon, 5 Nov 2012 00:03:56 -0800 (PST) From: arrowdodger <6yearold@gmail.com> Date: Mon, 5 Nov 2012 11:03:56 +0300 Message-ID: Subject: Hangs with nvidia-driver. To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 08:04:30 -0000 I've started experiencing hangs after 9.1-RC2 update. These hangs are caused by indefinitly looping somewhere inside nvidia_drv.so. As time passes, X server figures it out somehow and escapes from loop, but after short time everything hangs again. I've tried downgrading to RC1 and upgrading to RC3, downgrading NVIDIA driver to 295 and upgrading to the latest, downgrading Xorg and friends to 1.7.7 and upgrading to the latest with WITHOUT_NOUVEAU set. Nothing helped. Interesting lines from dmesg: NVRM: Xid (0000:01:00): 8, Channel 00000000 NVRM: Xid (0000:01:00): 8, Channel 00000000 NVRM: Xid (0000:01:00): 8, Channel 00000000 NVRM: Xid (0000:01:00): 13, 0000 e0014a00 0000004a 00000100 ffffffff 00000010 NVRM: Xid (0000:01:00): 12, COCOD 00000000 e0013900 00000039 00000300 00000006 Xorg.0.log: (WW) Nov 05 10:54:18 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0000f7a0, 0x0000fb54) (WW) Nov 05 10:54:26 NVIDIA(0): WAIT (0, 6, 0x8000, 0x000006e8, 0x000006e8) (WW) Nov 05 10:54:29 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000006e8, 0x00000814) (WW) Nov 05 10:54:37 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000bc38, 0x0000c520) (WW) Nov 05 10:55:10 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c30, 0x00005c30) (WW) Nov 05 10:55:13 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c54, 0x00005c54) (WW) Nov 05 10:55:16 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c78, 0x00005c78) [mi] EQ overflowing. The server is probably stuck in an infinite loop. (WW) Nov 05 10:55:41 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:48 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:51 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000d100, 0x0000f8c0) (WW) Nov 05 10:56:04 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000c340, 0x0000d534) (WW) Nov 05 10:56:18 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000eb10, 0x0000eee4) [mi] EQ overflowing. The server is probably stuck in an infinite loop. uname -a: FreeBSD alore 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 03:56:40 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 My video card is GeForce 6600. Please CC me, since i'm not subscribed to the list. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 08:20:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51BBD4B3 for ; Mon, 5 Nov 2012 08:20:21 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E04D8FC0A for ; Mon, 5 Nov 2012 08:20:20 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so6891447oag.13 for ; Mon, 05 Nov 2012 00:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yJgbYoclttbIP2m5oPXWohIF1pbgICyfUDN4Wkz3fK4=; b=r/vBh9Tmw/crQJD5dKDb5Dj/Nc93saEVvNuOjiqc6AJ5/nl4HDjWnAnwWSgOQDoVpv lK2Y6p35NQCgk/6r9D42DDXNsrrHipLBek/k2JgLY/F+cRKNrc6HQedFz9clqDx1s/DM veURXxA+CDcmNeCmrX4qDeAg4NaoEvnn1LMxCrKZd87NW5oMGwBoXbqySRgtkWRywgx5 NGL8cyx1NGZYzyhYHpg+VondVg6EEIgP9hKixpbx9k2peA2JWy4zOuVa8LuOvmTu9d7t ax4IZ5BNF/BIa/eFPg3gRsmFA4Q12P8pagK7gglqfkTXh2nSjLBwoZ943DkHvQPtEUGg +aTw== MIME-Version: 1.0 Received: by 10.60.172.171 with SMTP id bd11mr7514574oec.4.1352103620210; Mon, 05 Nov 2012 00:20:20 -0800 (PST) Received: by 10.76.170.36 with HTTP; Mon, 5 Nov 2012 00:20:20 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Nov 2012 09:20:20 +0100 Message-ID: Subject: Re: Hangs with nvidia-driver. From: Andreas Nilsson To: arrowdodger <6yearold@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 08:20:21 -0000 On Mon, Nov 5, 2012 at 9:03 AM, arrowdodger <6yearold@gmail.com> wrote: > I've started experiencing hangs after 9.1-RC2 update. These hangs are > caused by indefinitly looping somewhere inside nvidia_drv.so. As time > passes, X server figures it out somehow and escapes from loop, but after > short time everything hangs again. > > I've tried downgrading to RC1 and upgrading to RC3, downgrading NVIDIA > driver to 295 and upgrading to the latest, downgrading Xorg and friends to > 1.7.7 and upgrading to the latest with WITHOUT_NOUVEAU set. Nothing helped. > > Interesting lines from dmesg: > > NVRM: Xid (0000:01:00): 8, Channel 00000000 > NVRM: Xid (0000:01:00): 8, Channel 00000000 > NVRM: Xid (0000:01:00): 8, Channel 00000000 > NVRM: Xid (0000:01:00): 13, 0000 e0014a00 0000004a 00000100 ffffffff > 00000010 > NVRM: Xid (0000:01:00): 12, COCOD 00000000 e0013900 00000039 00000300 > 00000006 > > Xorg.0.log: > > (WW) Nov 05 10:54:18 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0000f7a0, 0x0000fb54) > (WW) Nov 05 10:54:26 NVIDIA(0): WAIT (0, 6, 0x8000, 0x000006e8, 0x000006e8) > (WW) Nov 05 10:54:29 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000006e8, 0x00000814) > (WW) Nov 05 10:54:37 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000bc38, 0x0000c520) > (WW) Nov 05 10:55:10 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c30, 0x00005c30) > (WW) Nov 05 10:55:13 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c54, 0x00005c54) > (WW) Nov 05 10:55:16 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c78, 0x00005c78) > [mi] EQ overflowing. The server is probably stuck in an infinite loop. > (WW) Nov 05 10:55:41 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000d100, 0x0000e444) > (WW) Nov 05 10:55:48 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0000d100, 0x0000e444) > (WW) Nov 05 10:55:51 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000d100, 0x0000f8c0) > (WW) Nov 05 10:56:04 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000c340, 0x0000d534) > (WW) Nov 05 10:56:18 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000eb10, 0x0000eee4) > [mi] EQ overflowing. The server is probably stuck in an infinite loop. > > uname -a: > > FreeBSD alore 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 03:56:40 UTC 2012 > root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > My video card is GeForce 6600. > Please CC me, since i'm not subscribed to the list. > I have similar experience, but for me it only happens after a suspend-to-ram cycle, and more often then with external screen connected. I use WITH_NEW_XORG and the xorg-dev repo. Regards Andreas From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 09:27:18 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A8D7177 for ; Mon, 5 Nov 2012 09:27:18 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0E58FC17 for ; Mon, 5 Nov 2012 09:27:17 +0000 (UTC) Received: (qmail 64465 invoked by uid 89); 5 Nov 2012 09:27:09 -0000 Received: by simscan 1.4.0 ppid: 64460, pid: 64462, t: 0.0530s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15536 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 5 Nov 2012 09:27:09 -0000 Date: Mon, 5 Nov 2012 10:27:09 +0100 From: Rainer Duffner To: Rick Miller Subject: Re: FreeBSD 9.1 stability/robustness? Message-ID: <20121105102709.6fb64c54@suse3> In-Reply-To: References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 09:27:18 -0000 Am Sat, 3 Nov 2012 21:56:45 -0400 schrieb Rick Miller : > On Fri, Nov 2, 2012 at 4:10 AM, Rainer Duffner > wrote: > > Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) > > schrieb Brett Glass : > > > >> I need to build up a few servers and routers, and am wondering how > >> FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > >> robust than 9.0-RELEASE? Are there issues that will have to wait > >> until 9.2-RELEASE to be fixed? Opinions welcome. > > > > > > If I'm not mistaken, the bge-stuff that makes the default NICs ins > > HP G8 servers (360+380) actually run will not make it back into 9.1. > > Intel cards work much better anyway... > > I have a blog post at > http://blog.hostileadmin.com/2012/06/14/freebsd-on-hp-proliant-dl360p-g8-servers/ > which touches on this. I heard as recently as today that the fixes > for the BCM5719 and 5720 were recently committed to -CURRENT. It's > too late for them to be rolled into 9.1. Not sure if they'll be > committed to to stable/8 or not, but if so they could make it into > 8.4-R. How did you PXE-boot the box, BTW? I ask, because I see no option during booting-up the DL380G8 to pxe-boot from the NC365T igb(4) NICs.... http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02607548&lang=en&cc=us&taskId=135&prodSeriesId=4189874&prodTypeId=329290 Rainer From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 10:26:55 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDD8A9B9; Mon, 5 Nov 2012 10:26:55 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by mx1.freebsd.org (Postfix) with ESMTP id 239718FC0A; Mon, 5 Nov 2012 10:26:53 +0000 (UTC) Received: from mail55-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 10:26:47 +0000 Received: from mail55-am1 (localhost [127.0.0.1]) by mail55-am1-R.bigfish.com (Postfix) with ESMTP id 6B079440061; Mon, 5 Nov 2012 10:26:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:195.159.75.198; KIP:(null); UIP:(null); IPV:NLI; H:nomtaout01.proact.no; RD:nomtaout01.proact.no; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zzbb2dI542M1432Izz1de0h1d18h1202h1d1ah1d2ahzz8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1 (MessageSwitch) id 1352111204573544_25782; Mon, 5 Nov 2012 10:26:44 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.248]) by mail55-am1.bigfish.com (Postfix) with ESMTP id 8028A18007C; Mon, 5 Nov 2012 10:26:44 +0000 (UTC) Received: from nomtaout01.proact.no (195.159.75.198) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 10:26:37 +0000 Received: from Semail04.proact.local (outside.proact.se [212.214.215.3]) by nomtaout01.proact.no (Postfix) with ESMTP id ACB195DD85; Mon, 5 Nov 2012 11:26:37 +0100 (MET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 11:26:37 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqAAF8a9gAAYYgXwAAYhBQAAk9ux8A== Date: Mon, 5 Nov 2012 10:26:35 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> In-Reply-To: <5093BECC.1030709@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" , "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 10:26:56 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 2. november 2012 13:39 > To: Tom Lislegaard > Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 02/11/2012 11:56 Tom Lislegaard said the following: > > The machine is usually connected to a docking station and I believe the= power is very stable. I > sometimes take it home and connect it to a different powersupply and sees= the same behavior with > panics there. Panics can occur while I'm at the machine working, or if I = leave the machine idle for > some time I find it has paniced/rebooted when I come back. > > The time of panic seems totally random and I can't correlate this to an= y particular activity like > cronjobs, etc. >=20 > I see. Could you please try setting debug.acpi.max_threads=3D1 in /boot/= loader.conf, reboot and see if > that makes any difference? >=20 > -- > Andriy Gapon It does make a difference. I've had the machine running over the week-end, = and haven't had a crash in 56 hours. After applying the setting I get some errors on reboot, no idea if they are= harmful in any way (none that I have notced): AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.m= ax_tasks tunable ACPI Error: Method parse/execution failed [\\PNOT] (Node 0xfffffe00052e6400= ), AE_NO_MEMORY (20110527/psparse-560) ACPI Error: Method parse/execution failed [\\_SB_.AC__._PSR] (Node 0xfffffe= 00052f57c0), AE_NO_MEMORY (20110527/psparse-560) The same messages repeats 6 times -tom From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 10:58:28 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20F09A45; Mon, 5 Nov 2012 10:58:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 34DBF8FC08; Mon, 5 Nov 2012 10:58:26 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28185; Mon, 05 Nov 2012 12:58:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TVKNq-0004Nm-Va; Mon, 05 Nov 2012 12:58:23 +0200 Message-ID: <50979BCD.3060000@FreeBSD.org> Date: Mon, 05 Nov 2012 12:58:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 10:58:28 -0000 on 05/11/2012 12:26 Tom Lislegaard said the following: >> -----Original Message----- >> From: Andriy Gapon [mailto:avg@FreeBSD.org] >> I see. Could you please try setting debug.acpi.max_threads=1 in /boot/loader.conf, reboot and see if >> that makes any difference? > > It does make a difference. I've had the machine running over the week-end, and haven't had a crash in 56 hours. > > After applying the setting I get some errors on reboot, no idea if they are harmful in any way (none that I have notced): > > AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable > ACPI Error: Method parse/execution failed [\\PNOT] (Node 0xfffffe00052e6400), AE_NO_MEMORY (20110527/psparse-560) > ACPI Error: Method parse/execution failed [\\_SB_.AC__._PSR] (Node 0xfffffe00052f57c0), AE_NO_MEMORY (20110527/psparse-560) > > The same messages repeats 6 times Thank you for the test! Try to set debug.acpi.max_tasks to 128 or even higher to get rid of the new ACPI errors. Additionally I would like to ask you to do the following test. Please stop devd and then run it (as root) from command line as such devd -D -d. Please check what event are reported by devd. In particular I am interested in ACAD events, but all high frequency events are important. Thanks! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 11:13:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09E8380D for ; Mon, 5 Nov 2012 11:13:55 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8E08FC12 for ; Mon, 5 Nov 2012 11:13:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Z/JTlRLxG7DxB3dh7Ww9rkXRheXb4+P6Vhh/uE8G6cY=; b=S6vLzHidoykGd5n3mYbd4Jq8vk7McYo84odl0DDtfxOVRlVXx3+CtpT735C4ZifInISvwnwOLnvRpiLyziUn9BOD1TMYoYReQgN/Lqh08uR7+uyr9lHm/5s/Su0K8uCw9eNJrDkJf0nCf95LOlfm3zV/IxDSssquk3iT38Hx5Bg=; Received: from [178.137.138.140] (helo=nonamehost) by fsm2.ukr.net with esmtpsa ID 1TVI3P-0003LE-16 ; Mon, 05 Nov 2012 10:29:07 +0200 Date: Mon, 5 Nov 2012 10:29:06 +0200 From: Ivan Klymenko To: arrowdodger <6yearold@gmail.com> Subject: Re: Hangs with nvidia-driver. Message-ID: <20121105102906.2635449a@nonamehost> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:13:55 -0000 =D0=92 Mon, 5 Nov 2012 11:03:56 +0300 arrowdodger <6yearold@gmail.com> =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > I've started experiencing hangs after 9.1-RC2 update. These hangs are > caused by indefinitly looping somewhere inside nvidia_drv.so. As time > passes, X server figures it out somehow and escapes from loop, but > after short time everything hangs again. >=20 > I've tried downgrading to RC1 and upgrading to RC3, downgrading NVIDIA > driver to 295 and upgrading to the latest, downgrading Xorg and > friends to 1.7.7 and upgrading to the latest with WITHOUT_NOUVEAU > set. Nothing helped. >=20 > Interesting lines from dmesg: >=20 > NVRM: Xid (0000:01:00): 8, Channel 00000000 > NVRM: Xid (0000:01:00): 8, Channel 00000000 > NVRM: Xid (0000:01:00): 8, Channel 00000000 > NVRM: Xid (0000:01:00): 13, 0000 e0014a00 0000004a 00000100 ffffffff > 00000010 > NVRM: Xid (0000:01:00): 12, COCOD 00000000 e0013900 00000039 00000300 > 00000006 >=20 > Xorg.0.log: >=20 > (WW) Nov 05 10:54:18 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0000f7a0, > 0x0000fb54) (WW) Nov 05 10:54:26 NVIDIA(0): WAIT (0, 6, 0x8000, > 0x000006e8, 0x000006e8) (WW) Nov 05 10:54:29 NVIDIA(0): WAIT (2, 6, > 0x8000, 0x000006e8, 0x00000814) (WW) Nov 05 10:54:37 NVIDIA(0): WAIT > (2, 6, 0x8000, 0x0000bc38, 0x0000c520) (WW) Nov 05 10:55:10 > NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c30, 0x00005c30) (WW) Nov 05 > 10:55:13 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c54, 0x00005c54) (WW) > Nov 05 10:55:16 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c78, > 0x00005c78) [mi] EQ overflowing. The server is probably stuck in an > infinite loop. (WW) Nov 05 10:55:41 NVIDIA(0): WAIT (2, 6, 0x8000, > 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:48 NVIDIA(0): WAIT (1, 6, > 0x8000, 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:51 NVIDIA(0): WAIT > (2, 6, 0x8000, 0x0000d100, 0x0000f8c0) (WW) Nov 05 10:56:04 > NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000c340, 0x0000d534) (WW) Nov 05 > 10:56:18 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000eb10, 0x0000eee4) [mi] > EQ overflowing. The server is probably stuck in an infinite loop. >=20 > uname -a: >=20 > FreeBSD alore 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 03:56:40 UTC 2012 > root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >=20 > My video card is GeForce 6600. > Please CC me, since i'm not subscribed to the list. I would recommend using a script to generate a report nvidia-bug-report.sh, which is on file with the drivers and send the report file nvidia-bug-report.log.gz to the mailing address freebsd-gfx-bugs@nvidia.com From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 11:41:30 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82A7DE77 for ; Mon, 5 Nov 2012 11:41:30 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 535BF8FC0A for ; Mon, 5 Nov 2012 11:41:30 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so4067414pad.13 for ; Mon, 05 Nov 2012 03:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=twBFlTtiH2UrwBnlDvKXMYXXF+HyHNEoWx6yCNQ089M=; b=fYTtm4rC3ghwM2v7gy0VLWzP2yCL7hMZLrQZYFg60L7Wi9pqn7777Bu3pNtu1T8MVe 6b5uyRuxZ5lr8d4jIMNtuGl/AnWa62naHJJEWZHcSMJassUaisFZcfx4DaS850d1l4bR ylogqDqBDKyHQThUevE7MyEfEyxQFfAcQ0m/8ip9o09gR9B4j1J+A3o/l6kcyJplepIy RYkJjP1aKVULmtExWMzqGAYs173JQwNLffwVCe8vXvgxuVdySBobrsjFQ6sd/xy+aNq/ OtKvFuJGoeCAiHUUO9N70ffQhAj9ZwevWlg084OzXuDuAVcJAZehmhWRopJFPhNbTe5h 4yMA== Received: by 10.68.197.71 with SMTP id is7mr29335523pbc.79.1352115684240; Mon, 05 Nov 2012 03:41:24 -0800 (PST) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id v2sm8815762paz.27.2012.11.05.03.41.22 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 03:41:23 -0800 (PST) Message-ID: <5097A5E0.2000502@gmail.com> Date: Mon, 05 Nov 2012 13:41:20 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: stable@freebsd.org Subject: buildworld fails on recent stable Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:41:30 -0000 Hi all. When CLANG_IS_CC build fails at sys/boot/i386/boot2: ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 -5 bytes available *** [boot2] Error code 1 The relevant output before r242562 looked like: ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1569 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1df9 text=200 data=1bf9 org=0 entry=0 7 bytes available dd if=boot2.ld of=boot2 obs=7680 conv=osync -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 11:45:29 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53A01FE7 for ; Mon, 5 Nov 2012 11:45:29 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 113AF8FC0C for ; Mon, 5 Nov 2012 11:45:27 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so6985475obb.13 for ; Mon, 05 Nov 2012 03:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l6wdx1Oocshlcm6VjvSvojZdiD1DSuenY1MJjvpixEo=; b=pyAdYg670xFAJ685YmGaLV9E1qqn0tAzEuzddH9vmki3UiYJGfBL8fu0HstEfhsyt9 e4DTiwMkPYUGNIttqWdYBSd+/+PPZPESq351rmsokgEXbX8+3hn7i4vBrqVqeS0dfvnN AJUgtVFcj00FgIT9G25cUrdZaFwhZoVWt+dNwc0JTeaUp5v/Vj2Nef+6s+QHV3Y4ICVv ajNGiQtHqiwYFdCb0L4gOiL2mWL2r2cBkuqLmf+Uee8WO8yk5UoWWfx9YsV/C+i1C1bv 8T0KoTZf5lJRc8lfLHE0Pd5FKRvGPvR3grdvparZtW3b6V5Pt7V5HmiUQOpFp42jYTqZ T+tA== MIME-Version: 1.0 Received: by 10.60.169.234 with SMTP id ah10mr7701920oec.12.1352115927552; Mon, 05 Nov 2012 03:45:27 -0800 (PST) Received: by 10.76.170.36 with HTTP; Mon, 5 Nov 2012 03:45:27 -0800 (PST) In-Reply-To: <5097A5E0.2000502@gmail.com> References: <5097A5E0.2000502@gmail.com> Date: Mon, 5 Nov 2012 12:45:27 +0100 Message-ID: Subject: Re: buildworld fails on recent stable From: Andreas Nilsson To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:45:29 -0000 On Mon, Nov 5, 2012 at 12:41 PM, Volodymyr Kostyrko wrote: > Hi all. > > When CLANG_IS_CC build fails at sys/boot/i386/boot2: > > ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o > boot2.out /usr/obj/usr/src/sys/boot/**i386/boot2/../btx/lib/crt0.o > boot2.o sio.o > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/**i386/boot2/../btx/btx/btx > -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 > -5 bytes available > *** [boot2] Error code 1 > > The relevant output before r242562 looked like: > > ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o > boot2.out /usr/obj/usr/src/sys/boot/**i386/boot2/../btx/lib/crt0.o > boot2.o sio.o > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/**i386/boot2/../btx/btx/btx > -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=1569 text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1df9 text=200 data=1bf9 org=0 entry=0 > 7 bytes available > dd if=boot2.ld of=boot2 obs=7680 conv=osync > > -- > Sphinx of black quartz, judge my vow. > I can confirm, for at least revisions 242602 and 242605. Regards Andreas From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 13:55:04 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6761C03; Mon, 5 Nov 2012 13:55:04 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by mx1.freebsd.org (Postfix) with ESMTP id 167758FC17; Mon, 5 Nov 2012 13:55:03 +0000 (UTC) Received: from mail2-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 13:54:56 +0000 Received: from mail2-db3 (localhost [127.0.0.1]) by mail2-db3-R.bigfish.com (Postfix) with ESMTP id D0BD34402DE; Mon, 5 Nov 2012 13:54:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:195.159.75.198; KIP:(null); UIP:(null); IPV:NLI; H:nomtaout01.proact.no; RD:nomtaout01.proact.no; EFVD:NLI X-SpamScore: -10 X-BigFish: VPS-10(zzbb2dI103dK542M1432Izz1de0h1d18h1202h1d1ah1d2ahzz8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail2-db3 (localhost.localdomain [127.0.0.1]) by mail2-db3 (MessageSwitch) id 1352123679394215_26717; Mon, 5 Nov 2012 13:54:39 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.245]) by mail2-db3.bigfish.com (Postfix) with ESMTP id 5DCEB2C0045; Mon, 5 Nov 2012 13:54:39 +0000 (UTC) Received: from nomtaout01.proact.no (195.159.75.198) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 13:54:38 +0000 Received: from Semail04.proact.local (outside.proact.se [212.214.215.3]) by nomtaout01.proact.no (Postfix) with ESMTP id BE0BD5DD81; Mon, 5 Nov 2012 14:54:38 +0100 (MET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 14:54:38 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqAAF8a9gAAYYgXwAAYhBQAAk9ux8P///B6A//+/I1A= Date: Mon, 5 Nov 2012 13:54:37 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> In-Reply-To: <50979BCD.3060000@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" , "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:55:04 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 5. november 2012 11:58 > To: Tom Lislegaard > Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 05/11/2012 12:26 Tom Lislegaard said the following: > >> -----Original Message----- > >> From: Andriy Gapon [mailto:avg@FreeBSD.org] I see. Could you please > >> try setting debug.acpi.max_threads=3D1 in /boot/loader.conf, reboot an= d > >> see if that makes any difference? > > > > It does make a difference. I've had the machine running over the week-e= nd, and haven't had a crash > in 56 hours. > > > > After applying the setting I get some errors on reboot, no idea if they= are harmful in any way (none > that I have notced): > > > > AcpiOsExecute: failed to enqueue task, consider increasing the > > debug.acpi.max_tasks tunable ACPI Error: Method parse/execution failed > > [\\PNOT] (Node 0xfffffe00052e6400), AE_NO_MEMORY > > (20110527/psparse-560) ACPI Error: Method parse/execution failed > > [\\_SB_.AC__._PSR] (Node 0xfffffe00052f57c0), AE_NO_MEMORY > > (20110527/psparse-560) > > > > The same messages repeats 6 times >=20 > Thank you for the test! > Try to set debug.acpi.max_tasks to 128 or even higher to get rid of the n= ew ACPI errors. >=20 > Additionally I would like to ask you to do the following test. > Please stop devd and then run it (as root) from command line as such devd= -D -d. > Please check what event are reported by devd. In particular I am interes= ted in ACAD events, but all > high frequency events are important. >=20 > Thanks! > -- > Andriy Gapon Here's the distribution from running devd over 40 minutes 589 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU0 notify=3D0x81' 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU1 notify=3D0x81' 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU2 notify=3D0x81' 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU3 notify=3D0x81' 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU4 notify=3D0x81' 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU5 notify=3D0x81' 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU6 notify=3D0x81' 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_PR_.= CPU7 notify=3D0x81' 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev= =3Ddsp4.1' 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev= =3Dpts/2' 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev= =3Dvboxdrv0' 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTROY cde= v=3Ddsp4.1' 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTROY cde= v=3Dvboxdrv0' Any use in running it over a longer period of time? -tom From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 14:20:36 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D0AAFFD; Mon, 5 Nov 2012 14:20:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6168FC08; Mon, 5 Nov 2012 14:20:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA01659; Mon, 05 Nov 2012 16:20:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5097CB27.8040802@FreeBSD.org> Date: Mon, 05 Nov 2012 16:20:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:20:36 -0000 on 05/11/2012 15:54 Tom Lislegaard said the following: > Here's the distribution from running devd over 40 minutes > > 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 notify=0x81' > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=dsp4.1' > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=vboxdrv0' > 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=dsp4.1' > 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=vboxdrv0' > > Any use in running it over a longer period of time? Very interesting. So the processors get _CST change notifications rather frequently, but there is no obvious source/cause for them... Could you please send to me acpidump -dt output or upload it somewhere and post a link? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 14:34:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE4C14D9 for ; Mon, 5 Nov 2012 14:34:02 +0000 (UTC) (envelope-from pulley@dabus.com) Received: from aegir.dabus.com (aegir.dabus.com [173.14.229.218]) by mx1.freebsd.org (Postfix) with ESMTP id 710C08FC0C for ; Mon, 5 Nov 2012 14:34:02 +0000 (UTC) Received: from aegir.dabus.com (localhost [127.0.0.1]) by aegir.dabus.com (Processor) with ESMTP id 1A6805F318 for ; Mon, 5 Nov 2012 07:33:55 -0700 (MST) DomainKey-Signature: a=rsa-sha1; b=s2T5n4G7mthIxVNqBt7RW1FXO8amF0Z237jxzyGUY3v9AY4xELUEdw7fdK13/1iW0kpd6IGLhUUe6m1AoXlEBCQ67RU7aZKNosxTC18a+enJquRlQuqgEV2AwiK8OKTQfzFsgjdQdm/+JFdbNdztPJTnKVnWByzjpCFzGVAIgOc=; c=nofws; d=dabus.com; q=dns; s=aegir1 Received: from aldebaran.dabus.com (unknown [192.168.10.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by aegir.dabus.com (Dabus) with ESMTPSA id 4BED75F30C for ; Mon, 5 Nov 2012 07:33:54 -0700 (MST) Date: Mon, 5 Nov 2012 07:33:55 -0700 From: Eric S Pulley To: freebsd-stable@freebsd.org Subject: Re: Hangs with nvidia-driver. Message-ID: <20121105073355.0e0fc40e@aldebaran.dabus.com> In-Reply-To: References: Organization: Dabus X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:34:02 -0000 On Mon, 5 Nov 2012 09:20:20 +0100 Andreas Nilsson wrote: > On Mon, Nov 5, 2012 at 9:03 AM, arrowdodger <6yearold@gmail.com> > wrote: > > > I've started experiencing hangs after 9.1-RC2 update. These hangs > > are caused by indefinitly looping somewhere inside nvidia_drv.so. > > As time passes, X server figures it out somehow and escapes from > > loop, but after short time everything hangs again. > > > > I've tried downgrading to RC1 and upgrading to RC3, downgrading > > NVIDIA driver to 295 and upgrading to the latest, downgrading Xorg > > and friends to 1.7.7 and upgrading to the latest with > > WITHOUT_NOUVEAU set. Nothing helped. > > > > Interesting lines from dmesg: > > > > NVRM: Xid (0000:01:00): 8, Channel 00000000 > > NVRM: Xid (0000:01:00): 8, Channel 00000000 > > NVRM: Xid (0000:01:00): 8, Channel 00000000 > > NVRM: Xid (0000:01:00): 13, 0000 e0014a00 0000004a 00000100 ffffffff > > 00000010 > > NVRM: Xid (0000:01:00): 12, COCOD 00000000 e0013900 00000039 > > 00000300 00000006 > > > > Xorg.0.log: > > > > (WW) Nov 05 10:54:18 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0000f7a0, > > 0x0000fb54) (WW) Nov 05 10:54:26 NVIDIA(0): WAIT (0, 6, 0x8000, > > 0x000006e8, 0x000006e8) (WW) Nov 05 10:54:29 NVIDIA(0): WAIT (2, 6, > > 0x8000, 0x000006e8, 0x00000814) (WW) Nov 05 10:54:37 NVIDIA(0): > > WAIT (2, 6, 0x8000, 0x0000bc38, 0x0000c520) (WW) Nov 05 10:55:10 > > NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c30, 0x00005c30) (WW) Nov 05 > > 10:55:13 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c54, 0x00005c54) > > (WW) Nov 05 10:55:16 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c78, > > 0x00005c78) [mi] EQ overflowing. The server is probably stuck in an > > infinite loop. (WW) Nov 05 10:55:41 NVIDIA(0): WAIT (2, 6, 0x8000, > > 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:48 NVIDIA(0): WAIT (1, 6, > > 0x8000, 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:51 NVIDIA(0): > > WAIT (2, 6, 0x8000, 0x0000d100, 0x0000f8c0) (WW) Nov 05 10:56:04 > > NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000c340, 0x0000d534) (WW) Nov 05 > > 10:56:18 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000eb10, 0x0000eee4) > > [mi] EQ overflowing. The server is probably stuck in an infinite > > loop. > > > > uname -a: > > > > FreeBSD alore 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 03:56:40 UTC > > 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > > > My video card is GeForce 6600. > > Please CC me, since i'm not subscribed to the list. > > > > I have similar experience, but for me it only happens after a > suspend-to-ram cycle, and more often then with external screen > connected. And just to muddy the waters... No problems at all here for a heavy graphics desktop on RC1-3 [16]pulley@aldebaran:~ >dmesg Copyright (c) 1992-2012 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 9.1-RC3 #0 r242324: Tue Oct 30 00:58:57 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU) . . . nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 14:40:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2CEB6AA for ; Mon, 5 Nov 2012 14:40:11 +0000 (UTC) (envelope-from pulley@dabus.com) Received: from aegir.dabus.com (aegir.dabus.com [173.14.229.218]) by mx1.freebsd.org (Postfix) with ESMTP id 8B2C48FC12 for ; Mon, 5 Nov 2012 14:40:11 +0000 (UTC) Received: from aegir.dabus.com (localhost [127.0.0.1]) by aegir.dabus.com (Processor) with ESMTP id ECE235F318 for ; Mon, 5 Nov 2012 07:40:10 -0700 (MST) DomainKey-Signature: a=rsa-sha1; b=l7XZM8ql+1oRr75gwZ5RzcXRvZ5z/QA4VRZ5dyYy+8Xh9tMhmQjAii4Y3UygyUXTCSMwtf8y45H4w3vJ5PefW97gaK6JWEJkYjvvzuNEcdTcmCyQNeVmR79/ijTcLjRNutTS4SpddTtbVV5wCnSt/YgrlvgHWMZdMBZF0rI3lpA=; c=nofws; d=dabus.com; q=dns; s=aegir1 Received: from aldebaran.dabus.com (unknown [192.168.10.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by aegir.dabus.com (Dabus) with ESMTPSA id 2E2555F30C for ; Mon, 5 Nov 2012 07:40:10 -0700 (MST) Date: Mon, 5 Nov 2012 07:40:10 -0700 From: Eric S Pulley To: freebsd-stable@freebsd.org Subject: Re: Hangs with nvidia-driver. Message-ID: <20121105074010.14d03e85@aldebaran.dabus.com> In-Reply-To: <20121105073355.0e0fc40e@aldebaran.dabus.com> References: <20121105073355.0e0fc40e@aldebaran.dabus.com> Organization: Dabus X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:40:11 -0000 On Mon, 5 Nov 2012 07:33:55 -0700 Eric S Pulley wrote: > On Mon, 5 Nov 2012 09:20:20 +0100 > Andreas Nilsson wrote: > > > On Mon, Nov 5, 2012 at 9:03 AM, arrowdodger <6yearold@gmail.com> > > wrote: > > > > > I've started experiencing hangs after 9.1-RC2 update. These hangs > > > are caused by indefinitly looping somewhere inside nvidia_drv.so. > > > As time passes, X server figures it out somehow and escapes from > > > loop, but after short time everything hangs again. > > > > > > I've tried downgrading to RC1 and upgrading to RC3, downgrading > > > NVIDIA driver to 295 and upgrading to the latest, downgrading Xorg > > > and friends to 1.7.7 and upgrading to the latest with > > > WITHOUT_NOUVEAU set. Nothing helped. > > > > > > Interesting lines from dmesg: > > > > > > NVRM: Xid (0000:01:00): 8, Channel 00000000 > > > NVRM: Xid (0000:01:00): 8, Channel 00000000 > > > NVRM: Xid (0000:01:00): 8, Channel 00000000 > > > NVRM: Xid (0000:01:00): 13, 0000 e0014a00 0000004a 00000100 > > > ffffffff 00000010 > > > NVRM: Xid (0000:01:00): 12, COCOD 00000000 e0013900 00000039 > > > 00000300 00000006 > > > > > > Xorg.0.log: > > > > > > (WW) Nov 05 10:54:18 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0000f7a0, > > > 0x0000fb54) (WW) Nov 05 10:54:26 NVIDIA(0): WAIT (0, 6, 0x8000, > > > 0x000006e8, 0x000006e8) (WW) Nov 05 10:54:29 NVIDIA(0): WAIT (2, > > > 6, 0x8000, 0x000006e8, 0x00000814) (WW) Nov 05 10:54:37 NVIDIA(0): > > > WAIT (2, 6, 0x8000, 0x0000bc38, 0x0000c520) (WW) Nov 05 10:55:10 > > > NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c30, 0x00005c30) (WW) Nov 05 > > > 10:55:13 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c54, 0x00005c54) > > > (WW) Nov 05 10:55:16 NVIDIA(0): WAIT (0, 7, 0x8000, 0x00005c78, > > > 0x00005c78) [mi] EQ overflowing. The server is probably stuck in > > > an infinite loop. (WW) Nov 05 10:55:41 NVIDIA(0): WAIT (2, 6, > > > 0x8000, 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:48 NVIDIA(0): > > > WAIT (1, 6, 0x8000, 0x0000d100, 0x0000e444) (WW) Nov 05 10:55:51 > > > NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000d100, 0x0000f8c0) (WW) Nov > > > 05 10:56:04 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000c340, > > > 0x0000d534) (WW) Nov 05 10:56:18 NVIDIA(0): WAIT (2, 6, 0x8000, > > > 0x0000eb10, 0x0000eee4) [mi] EQ overflowing. The server is > > > probably stuck in an infinite loop. > > > > > > uname -a: > > > > > > FreeBSD alore 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 03:56:40 UTC > > > 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > > > > > My video card is GeForce 6600. > > > Please CC me, since i'm not subscribed to the list. > > > > > > > I have similar experience, but for me it only happens after a > > suspend-to-ram cycle, and more often then with external screen > > connected. > > And just to muddy the waters... No problems at all here for a heavy > graphics desktop on RC1-3 > > [16]pulley@aldebaran:~ >dmesg > Copyright (c) 1992-2012 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 9.1-RC3 #0 r242324: Tue Oct 30 00:58:57 UTC 2012 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class > CPU) . > . > . > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io Also using the latest from ports: nvidia-driver-304.60 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 14:51:46 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A8C2D10; Mon, 5 Nov 2012 14:51:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id F2CBD8FC16; Mon, 5 Nov 2012 14:51:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:d493:276:882f:463e] (unknown [IPv6:2001:7b8:3a7:0:d493:276:882f:463e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7EDF95C59; Mon, 5 Nov 2012 15:51:44 +0100 (CET) Message-ID: <5097D27E.1050705@FreeBSD.org> Date: Mon, 05 Nov 2012 15:51:42 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: buildworld fails on recent stable References: <5097A5E0.2000502@gmail.com> In-Reply-To: <5097A5E0.2000502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:51:46 -0000 On 2012-11-05 12:41, Volodymyr Kostyrko wrote: > When CLANG_IS_CC build fails at sys/boot/i386/boot2: > > ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o > boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o > sio.o > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b > /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o > boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 > -5 bytes available This seems to be caused by r242562, which is an MFC of r241301. The code changes are quite trivial though. Strangely enough, on head it does build successfully, but head is using a newer version of clang, so that may explain the difference. Investigating... From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 14:52:42 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CD3CE21; Mon, 5 Nov 2012 14:52:42 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by mx1.freebsd.org (Postfix) with ESMTP id ABC2B8FC0C; Mon, 5 Nov 2012 14:52:41 +0000 (UTC) Received: from mail39-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 14:52:40 +0000 Received: from mail39-db3 (localhost [127.0.0.1]) by mail39-db3-R.bigfish.com (Postfix) with ESMTP id 5D7361801C2; Mon, 5 Nov 2012 14:52:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:212.214.215.133; KIP:(null); UIP:(null); IPV:NLI; H:semtaout01.proact.se; RD:semtaout01.proact.se; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zzbb2dI542M1432Izz1de0h1d18h1202h1d1ah1d2ahzz8275bh8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail39-db3 (localhost.localdomain [127.0.0.1]) by mail39-db3 (MessageSwitch) id 1352127157256193_3348; Mon, 5 Nov 2012 14:52:37 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.229]) by mail39-db3.bigfish.com (Postfix) with ESMTP id 32AD94E010B; Mon, 5 Nov 2012 14:52:37 +0000 (UTC) Received: from semtaout01.proact.se (212.214.215.133) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 14:52:35 +0000 Received: from Semail04.proact.local (unknown [10.7.1.58]) by semtaout01.proact.se (Postfix) with ESMTP id 15F6D5727C; Mon, 5 Nov 2012 15:52:35 +0100 (CET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 15:52:34 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqAAF8a9gAAYYgXwAAYhBQAAk9ux8P///B6A//+/I1CAAHlQgP//5ozA Date: Mon, 5 Nov 2012 14:52:33 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> In-Reply-To: <5097CB27.8040802@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" , "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:52:42 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 5. november 2012 15:21 > To: Tom Lislegaard > Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 05/11/2012 15:54 Tom Lislegaard said the following: > > Here's the distribution from running devd over 40 minutes > > > > 589 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU0 notify=3D0x81' > > 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU1 notify=3D0x81' > > 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU2 notify=3D0x81' > > 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU3 notify=3D0x81' > > 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU4 notify=3D0x81' > > 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU5 notify=3D0x81' > > 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU6 notify=3D0x81' > > 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\\_= PR_.CPU7 notify=3D0x81' > > 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREATE = cdev=3Ddsp4.1' > > 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREATE = cdev=3Dpts/2' > > 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREATE = cdev=3Dvboxdrv0' > > 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTROY= cdev=3Ddsp4.1' > > 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTROY= cdev=3Dvboxdrv0' > > > > Any use in running it over a longer period of time? >=20 > Very interesting. > So the processors get _CST change notifications rather frequently, but th= ere is no obvious > source/cause for them... >=20 > Could you please send to me acpidump -dt output or upload it somewhere an= d post a link? >=20 > -- > Andriy Gapon Here you go https://dl.dropbox.com/u/13263820/acpidump.txt -tom From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 14:56:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EF02158 for ; Mon, 5 Nov 2012 14:56:04 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7C58FC16 for ; Mon, 5 Nov 2012 14:56:03 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so5301726lbd.13 for ; Mon, 05 Nov 2012 06:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=kyLoElbzcGzWbI7PvzNsvdXjC1qiZbrjD729ksfFLww=; b=hh8nbJUByfnIdtk8jwbR5qZQrrqYitLqnZjuH26oICLhj19YdUuD0i9iZ9P7WICgxY sfMug/Ba3m7+5yKX0C385pXiD4Yx6yFqXJJYKRbxjcgoRuycv4VORB0wSuX4lCz+EjAz 97xEVvM1dsqrcZ86c3h5mjA0GlvgY6keTI24nOxWkGPbLWU8ObCodBMi704gk/uUpLmh 7hkBN8XpkPCRVF4CIdvPqj7If13DzADIEEqqT1Fr2LuMAn7Ot9MwDDSBeptxEakzVS15 QxIUkFexNlyHO4H9/cppjdu3ysZ6DJg3vCXMhM709EPbn61lSEpbhwyrn5tyao7boUE0 07mQ== Received: by 10.112.47.129 with SMTP id d1mr4017820lbn.115.1352127362625; Mon, 05 Nov 2012 06:56:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.57.40 with HTTP; Mon, 5 Nov 2012 06:55:32 -0800 (PST) In-Reply-To: <20121105102906.2635449a@nonamehost> References: <20121105102906.2635449a@nonamehost> From: arrowdodger <6yearold@gmail.com> Date: Mon, 5 Nov 2012 17:55:32 +0300 Message-ID: Subject: Re: Hangs with nvidia-driver. To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:56:04 -0000 Okay, i booted OpenIndiana live cd and experiencing same problem. So, it's just my videocard decided to retire. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 15:19:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ED3C746 for ; Mon, 5 Nov 2012 15:19:06 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp3.sbb.rs (smtp3.sbb.rs [89.216.2.35]) by mx1.freebsd.org (Postfix) with ESMTP id D50478FC0A for ; Mon, 5 Nov 2012 15:19:05 +0000 (UTC) Received: from mycenae (cable-178-148-98-153.dynamic.sbb.rs [178.148.98.153]) by smtp3.sbb.rs (8.14.0/8.14.0) with ESMTP id qA5F0tG5016963 for ; Mon, 5 Nov 2012 16:01:00 +0100 Received: by mycenae (Postfix, from userid 1001) id 539425C23; Mon, 5 Nov 2012 16:00:58 +0100 (CET) Date: Mon, 5 Nov 2012 16:00:58 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: agp in kernel Message-ID: <20121105150057.GA1151@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -2.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:19:06 -0000 After several years I replaced desktop and laptop and wait for release to start fresh. On desktop I put nvidia gt520. Forums say nvidia prop driver dislikes agp op- tion in kernel and recommend removing it. Laptop is sandy bridge with hd3000 integrated. Would I trigger something if I delete agp from conf file in both cases? Another issue bothers me also. RC version of amdtemp failed to read temperatures on 8120. What version will be included in release? Some months ago there was a post of people taking source from current and compiling mo- dule. It worked on 8 core bulldozer. Best regards all Zoran From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 15:41:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBED1D05 for ; Mon, 5 Nov 2012 15:41:05 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 857628FC0C for ; Mon, 5 Nov 2012 15:41:05 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so10649284iea.13 for ; Mon, 05 Nov 2012 07:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=4jNqrbk27MR5Ywf2nlhiYo/k/dghwimdPZSchgvsKlI=; b=t16nX5jvoJA0EnERLbUZ8CZSo5QvKdP3edwg24xNtEHaR/Rh7AOYXc1u1bHCpYu9g+ 6mkPiQsjRxjfYRoKPGV4Fj7Fkn4bIHw9bKzrhsGDMHjMyVM0HhvtmCSbZrJvxtyJvnIQ tBz8FrXJ3ml1VUFk4asWWt+lWEN55PRb/pALuLnV4N8FEqbzEzTCZmtXIYUPqSEfeiS+ xWOdoT2gtbILIDqTMEuuq9Q4NCpUpVct4/Ao5Na+4ImfHGTwEMAQ99Y597YTExkUDaLk 33oqzawRK6N64iv1kf34KkvHVMeGrj+GY7Gbg/gETuFzxRORYiRH30AJjnwACkGTTGI9 7C3A== Received: by 10.50.207.36 with SMTP id lt4mr9749966igc.66.1352130064796; Mon, 05 Nov 2012 07:41:04 -0800 (PST) Received: from al-mb-mws0001.localnet ([173.157.242.189]) by mx.google.com with ESMTPS id x7sm6387052igk.8.2012.11.05.07.41.03 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 07:41:04 -0800 (PST) From: Chuck Burns To: freebsd-stable@freebsd.org Subject: Re: agp in kernel Date: Mon, 05 Nov 2012 09:40:52 -0600 Message-ID: <2308986.BjMotPlPyq@al-mb-mws0001> User-Agent: KMail/4.8.0 (Windows/6.1; KDE/4.8.0; i686; ; ) In-Reply-To: <20121105150057.GA1151@mycenae.sbb.rs> References: <20121105150057.GA1151@mycenae.sbb.rs> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:41:06 -0000 On Monday, November 05, 2012 04:00:58 PM Zoran Kolic wrote: > After several years I replaced desktop and laptop and > wait for release to start fresh. On desktop I put nvidia > gt520. Forums say nvidia prop driver dislikes agp op- > tion in kernel and recommend removing it. Laptop is > sandy bridge with hd3000 integrated. Would I trigger > something if I delete agp from conf file in both cases? > > Another issue bothers me also. RC version of amdtemp > failed to read temperatures on 8120. What version will > be included in release? Some months ago there was a post > of people taking source from current and compiling mo- > dule. It worked on 8 core bulldozer. > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" I am using latest nvidia-driver, and GENERIC 9.1-RC3, which has agp in the kernel, and have no issues.. I don't have an FX- cpu, so can't speak to the 2nd part of your post. -- Chuck Burns From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 15:42:25 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74538E28; Mon, 5 Nov 2012 15:42:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9293D8FC17; Mon, 5 Nov 2012 15:42:24 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA04644; Mon, 05 Nov 2012 17:42:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5097DE5E.6020405@FreeBSD.org> Date: Mon, 05 Nov 2012 17:42:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: buildworld fails on recent stable References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> In-Reply-To: <5097D27E.1050705@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Volodymyr Kostyrko , stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:42:25 -0000 on 05/11/2012 16:51 Dimitry Andric said the following: > On 2012-11-05 12:41, Volodymyr Kostyrko wrote: >> When CLANG_IS_CC build fails at sys/boot/i386/boot2: >> >> ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o >> boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o >> sio.o >> objcopy -S -O binary boot2.out boot2.bin >> btxld -v -E 0x2000 -f bin -b >> /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o >> boot2.ld -P 1 boot2.bin >> kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 >> client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 >> output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 >> -5 bytes available > > This seems to be caused by r242562, which is an MFC of r241301. The > code changes are quite trivial though. Strangely enough, on head it > does build successfully, but head is using a newer version of clang, so > that may explain the difference. Investigating... I suspect that some earlier space-saving commit was not MFC-ed to stable/9. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 15:47:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9821FF80 for ; Mon, 5 Nov 2012 15:47:39 +0000 (UTC) (envelope-from hg@queue.to) Received: from pickle.queue.to (pickle.queue.to [71.180.69.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2C38FC08 for ; Mon, 5 Nov 2012 15:47:38 +0000 (UTC) Received: (qmail 91979 invoked from network); 5 Nov 2012 10:47:32 -0500 Received: from cally.queue.to (172.16.0.6) by pickle.queue.to with ESMTP; 5 Nov 2012 10:47:32 -0500 Message-ID: <5097DF8E.3020803@queue.to> Date: Mon, 05 Nov 2012 10:47:26 -0500 From: Howard Goldstein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> <5087C428.2020908@gmail.com> <5087CA5D.2090407@FreeBSD.org> <5087D069.7040700@gmail.com> In-Reply-To: <5087D069.7040700@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5E68B7ADD8839155983C941" Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:47:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5E68B7ADD8839155983C941 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/24/2012 07:26, Volodymyr Kostyrko wrote: > 24.10.2012 14:00, Dimitry Andric wrote: >>>> On the problematic athlons, can you please post the exact CPUIDs fro= m >>>> dmesg? If you have WITH_CLANG_EXTRAS enabled, please also post the >>>> output of "opt -version". >>> >>> Oct 24 01:47:20 limbo kernel: CPU: AMD Athlon(tm) XP 2500+ (1833.95-M= Hz >>> 686-class CPU) >>> Oct 24 01:47:20 limbo kernel: Origin =3D "AuthenticAMD" Id =3D 0x6a0= >>> Family =3D 0x6 Model =3D 0xa Stepping =3D 0 >> >> Ok, this CPU should be recognized by llvm as "athlon-xp". There is in= >> fact no need to compile all the WITH_CLANG_EXTRAS programs, I just >> remembered. >> >> If you compile a sample program with -march=3Dnative -v, it should sho= w >> you the detected CPU in the verbose command line output, e.g.: >> Volodymyr, your initial email in this thread regarding clang's being stuck on native code generation allowed me to wrap up a week of fighting with an updated production box with a weird wine issue - thank you! FWIW I filed a pr on this. You've done much more useful legwork towards a solution of the problem and I wanted to point it out to everyone how helpful it was. THANK YOU! The pr is at http://www.freebsd.org/cgi/query-pr.cgi?pr=3D173337 Howard --------------enigE5E68B7ADD8839155983C941 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQl9+UdYVFuiUUgywRAttyAKCTAXa+IszhZd+OYtBRbuthmQ+REgCg8Rjn 2vrLR7IUHAlNW3UiyeXTNFI= =Q/Ca -----END PGP SIGNATURE----- --------------enigE5E68B7ADD8839155983C941-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 15:52:35 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72BEB142; Mon, 5 Nov 2012 15:52:35 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 31FF98FC0C; Mon, 5 Nov 2012 15:52:34 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so4226250pbb.13 for ; Mon, 05 Nov 2012 07:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8jq4OdCtfp2Z5duDIHiBVMQBVMC5N4X1kmUtfRbNM00=; b=eHaYxoG7JkgQpn2O6F2lvId17Bm1AqDRiIDAFjyfxqOAEfnjttaM5asttA/pTLX5sF Uvxwb/y2jmToZM3wFkNM4KaCjHlH4aezBiYMXvZB9CPf6xBr+Q8+j1je57GjwreUtLL2 sXm6jmGdMLpBOjZoSuYWNFPcogNEaPiW/Ot+9eXq8BEmCbbAsQ3W67EKBx4zFn9HS5Ya m+WqoSQF0N1nK48h4BKkn6e9INvA3U149oY9ChP+LKM2aOrkKoWDITKQa1qwNVHthIpM qn+5gP3laXBia/i4rA0uB1f7H1Bla5dYhKuiYAih/b4Ysjsv1ew1GyHaFG9baYI23XsF z1Dg== Received: by 10.68.193.163 with SMTP id hp3mr31198292pbc.21.1352130754505; Mon, 05 Nov 2012 07:52:34 -0800 (PST) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id uh10sm6006314pbc.35.2012.11.05.07.52.32 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 07:52:34 -0800 (PST) Message-ID: <5097E0BD.50909@gmail.com> Date: Mon, 05 Nov 2012 17:52:29 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: buildworld fails on recent stable References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> <5097DE5E.6020405@FreeBSD.org> In-Reply-To: <5097DE5E.6020405@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:52:35 -0000 05.11.2012 17:42, Andriy Gapon wrote: > on 05/11/2012 16:51 Dimitry Andric said the following: >> On 2012-11-05 12:41, Volodymyr Kostyrko wrote: >>> When CLANG_IS_CC build fails at sys/boot/i386/boot2: >>> >>> ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o >>> boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o >>> sio.o >>> objcopy -S -O binary boot2.out boot2.bin >>> btxld -v -E 0x2000 -f bin -b >>> /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o >>> boot2.ld -P 1 boot2.bin >>> kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 >>> client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 >>> output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 >>> -5 bytes available >> >> This seems to be caused by r242562, which is an MFC of r241301. The >> code changes are quite trivial though. Strangely enough, on head it >> does build successfully, but head is using a newer version of clang, so >> that may explain the difference. Investigating... > > I suspect that some earlier space-saving commit was not MFC-ed to stable/9. > This can be easily checked: # cd /usr/src/sys/boot/i386/boot2/ # make clean # svn up Updated to revision 242616. # setenv PATH /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # unsetenv CCACHE_PATH # /usr/local/bin/clang -v clang version 3.2 (trunk) Target: amd64-portbld-freebsd9.1 Thread model: posix # echo CC=/usr/local/bin/clang >> /etc/src.conf # echo CXX=/usr/local/bin/clang++ >> /etc/src.conf # make .... ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=154d text=0 data=0 bss=0 entry=0 output: fmt=bin size=1ddd text=200 data=1bdd org=0 entry=0 35 bytes available dd if=boot2.ld of=boot2 obs=7680 conv=osync 14+1 records in 1+0 records out 7680 bytes transferred in 0.000099 secs (77433305 bytes/sec) I bet on clang 3.2. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 16:00:51 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C8B5403; Mon, 5 Nov 2012 16:00:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 423728FC0A; Mon, 5 Nov 2012 16:00:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA05239; Mon, 05 Nov 2012 18:00:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5097E2AF.2010000@FreeBSD.org> Date: Mon, 05 Nov 2012 18:00:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Volodymyr Kostyrko , Dimitry Andric Subject: Re: buildworld fails on recent stable References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> <5097DE5E.6020405@FreeBSD.org> <5097E0BD.50909@gmail.com> In-Reply-To: <5097E0BD.50909@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:00:51 -0000 on 05/11/2012 17:52 Volodymyr Kostyrko said the following: > I bet on clang 3.2. Thank you for checking. So how do we proceed from here? I could just revert the MFC-es, but the functionality could be desirable to some users. Are there any alternatives? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 16:28:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A71FCFC7; Mon, 5 Nov 2012 16:28:58 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62AF18FC0C; Mon, 5 Nov 2012 16:28:58 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so4253511pad.13 for ; Mon, 05 Nov 2012 08:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dnyvGoaUj6UDeRpwLcovBeQwe3R3CYWmMCsBxOO0BSc=; b=AXCnsLoJ3pHGTJvXHN6NwhyfWzzyo2aUdTC5vtDicwUelnOcy1xdIIJFE/ewVoCyw/ v7dv2tKWe3s+MI1koEFoV6K/UeNoLc52XU3cXoHzUQMF7seAkxYlPwbDqg3ptInpKE87 4NRC54KbbbJ2PNQ0fK6H1DCD8Y0Y83lF4FFlHYEvvd4eVSLqc89RL3J7hq3F6b8H4Vi0 /lJxp5ih98oToVGuLHsXN4YoBH7NPdvQinLGz9HiF0X+DLut9WA+enlzSIpgm1KYWL57 u2qhL6vqat+ZzdfttCQkC2JD5p7RWGhwXeLwKknF8Mc1ZIVn1h2FV3u4N+YU0NnVmwSc +/cQ== Received: by 10.68.234.201 with SMTP id ug9mr31699805pbc.63.1352132937956; Mon, 05 Nov 2012 08:28:57 -0800 (PST) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id f2sm10869091paz.25.2012.11.05.08.28.55 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 08:28:57 -0800 (PST) Message-ID: <5097E944.1000405@gmail.com> Date: Mon, 05 Nov 2012 18:28:52 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: buildworld fails on recent stable References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> <5097DE5E.6020405@FreeBSD.org> <5097E0BD.50909@gmail.com> <5097E2AF.2010000@FreeBSD.org> In-Reply-To: <5097E2AF.2010000@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:28:58 -0000 05.11.2012 18:00, Andriy Gapon wrote: >> I bet on clang 3.2. > > Thank you for checking. > > So how do we proceed from here? > I could just revert the MFC-es, but the functionality could be desirable to some > users. Are there any alternatives? Dunno, clang 3.2 is still pending so I guess it wouldn't be MFC'ed until December 16th? Being a minor issue it can make some people shrug from using clang for testing stable... I think reverting the working change is not good as far as building world with clang is still not the true and default way. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 16:32:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E96162A5 for ; Mon, 5 Nov 2012 16:32:45 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B2E228FC16 for ; Mon, 5 Nov 2012 16:32:45 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so4255542pbb.13 for ; Mon, 05 Nov 2012 08:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Xd8gITV0ZeZnjNNenEXzNl4YgsHQqqhAJQrrmIWYmc0=; b=YdhWBQGgcf+RVJipEQFrSgLPHWzaPSfcicL4NIaCevo3N9wYTCJJvRC6CdcroFtPgq p3Q4Nl9ujyMjEpK+s22DvTGDg4WnaTnDd1nC2cQQQsZuc4CrEJKLVqWse+ULQbdQeKXQ vXwyZ9hj1oopPtE+sRTqxCOmtqX/UzKjHv0LjxhSfAqCIGEp+NxwqTiPp+4f4sO7mtTy J+I/PlWXjVunRDOnLrQR6iGjep+nJ6X0cwv4z8yxzrF5Ha9qKu2XWH+4GTvZSH+BgKPg WZY5nfIGMpexugX4kyJftx3jI4YcAx7cpc4ucfFjOdHTE5fjvloRDjuzRwGnYjen8SWV W0NQ== Received: by 10.68.228.130 with SMTP id si2mr31999798pbc.126.1352133165124; Mon, 05 Nov 2012 08:32:45 -0800 (PST) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id b6sm10867083pav.33.2012.11.05.08.32.43 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 08:32:44 -0800 (PST) Message-ID: <5097EA28.5000801@gmail.com> Date: Mon, 05 Nov 2012 18:32:40 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Howard Goldstein Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> <5087C428.2020908@gmail.com> <5087CA5D.2090407@FreeBSD.org> <5087D069.7040700@gmail.com> <5097DF8E.3020803@queue.to> In-Reply-To: <5097DF8E.3020803@queue.to> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:32:46 -0000 05.11.2012 17:47, Howard Goldstein wrote: > Volodymyr, your initial email in this thread regarding clang's being > stuck on native code generation allowed me to wrap up a week of fighting > with an updated production box with a weird wine issue - thank you! > > FWIW I filed a pr on this. You've done much more useful legwork towards > a solution of the problem and I wanted to point it out to everyone how > helpful it was. THANK YOU! > > The pr is at http://www.freebsd.org/cgi/query-pr.cgi?pr=173337 I'm still unsure of my results though. I can't reproduce gcc core dump anymore. I think it's shadowed by some later fix. As for wine my results are not complete: 1. Building a world with CPUTYPE=athlon-tbird on a world built with CPUTYPE=k6 makes wine work. 2. Building a world with CPUTYPE=athlon-tbird on a world built with CPUTYPE=athlon-xp makes wine fail. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 16:50:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61D408E7 for ; Mon, 5 Nov 2012 16:50:04 +0000 (UTC) (envelope-from hg@queue.to) Received: from pickle.queue.to (pickle.queue.to [71.180.69.18]) by mx1.freebsd.org (Postfix) with ESMTP id DA4918FC12 for ; Mon, 5 Nov 2012 16:50:03 +0000 (UTC) Received: (qmail 8775 invoked from network); 5 Nov 2012 11:50:02 -0500 Received: from cally.queue.to (172.16.0.6) by pickle.queue.to with ESMTP; 5 Nov 2012 11:50:02 -0500 Message-ID: <5097EE3A.1010904@queue.to> Date: Mon, 05 Nov 2012 11:50:02 -0500 From: Howard Goldstein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> <5087C428.2020908@gmail.com> <5087CA5D.2090407@FreeBSD.org> <5087D069.7040700@gmail.com> <5097DF8E.3020803@queue.to> <5097EA28.5000801@gmail.com> In-Reply-To: <5097EA28.5000801@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9FFBBC3149A2F01DC04393A2" Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:50:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9FFBBC3149A2F01DC04393A2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/05/2012 11:32, Volodymyr Kostyrko wrote: > 05.11.2012 17:47, Howard Goldstein wrote: >> Volodymyr, your initial email in this thread regarding clang's being >> stuck on native code generation allowed me to wrap up a week of fighti= ng >> with an updated production box with a weird wine issue - thank you! >> >> FWIW I filed a pr on this. You've done much more useful legwork towar= ds >> a solution of the problem and I wanted to point it out to everyone how= >> helpful it was. THANK YOU! >> >> The pr is at http://www.freebsd.org/cgi/query-pr.cgi?pr=3D173337 >=20 > I'm still unsure of my results though. I can't reproduce gcc core dump > anymore. I think it's shadowed by some later fix. >=20 > As for wine my results are not complete: >=20 > 1. Building a world with CPUTYPE=3Dathlon-tbird on a world built with > CPUTYPE=3Dk6 makes wine work. > 2. Building a world with CPUTYPE=3Dathlon-tbird on a world built with > CPUTYPE=3Dathlon-xp makes wine fail. >=20 Like the other poster I'm not familiar with the amd world but if the host you built on didn't support the same instruction set as the target I suspect you see the same weirdness. For what it's worth wine never dumped .core for me (background: i386, world and kern built with clang to CPUTYPE?=3Dpentium4, then world and ports built with old gcc 4.2 also targeting pentium4, then finally kernel build with old gcc 4.2 is what fixed it. For me winedbg never got far enough in starting up the simplest wine (winecfg) to debug which was a great clue but it didn't sink in until I found your post. I failed to try building wine with symbols so I didn't have a meaningful gdb session. In my eyes you are "da man" as it was a terrible week getting the box back into use until I encountered your list post. Save my email if you're ever in southwest Florida, US because I owe you a couple of brewskis or whatever you prefer. The box is now on its way back to the law office. --------------enig9FFBBC3149A2F01DC04393A2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQl+46dYVFuiUUgywRAvMMAKCFzavWLyvcQa+VPk/KawwNgwekyQCeIO3z md9K3mAx5MHYQsGUXQNnqic= =CJuG -----END PGP SIGNATURE----- --------------enig9FFBBC3149A2F01DC04393A2-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 16:55:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28714B04; Mon, 5 Nov 2012 16:55:16 +0000 (UTC) (envelope-from prvs=1656497edf=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7414B8FC0C; Mon, 5 Nov 2012 16:55:14 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000960905.msg; Mon, 05 Nov 2012 16:55:12 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 05 Nov 2012 16:55:12 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1656497edf=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> From: "Steven Hartland" To: , References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Date: Mon, 5 Nov 2012 16:55:11 -0000 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 Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:55:16 -0000 I've managed to get the machine to reproduce this fairly regularly now. Without a debug kernel it still results in a panic, just at a later stage or so I believe, the none debug panic messages is "command not in queue". In each none debug panic I've seen the cm_flags indicates the command being dequeued is on the busy queue and not on the expected free or ready queue which is being processed at the time. The triggering issue seems to be the adapter reset code run from mfi_timeout. I've had a good look but can't see how a cm could be in a queue yet have its cm_flags set to that of a different queue as all manipulation seems to be being done via the "mfi_ ## name" macros which all correctly maintain the queue / cm_flags relationship. At this point I believe it could be a thread being interrupted by a timeout part way the processing of a queue request hence queue and cm_flags being out of sync. Any pointers on how to debug this issue further / fix it would be most appreciated. Regards Steve ----- Original Message ----- From: "Steven Hartland" > Testing a new machine which is based on 8.3-RELEASE with the mfi > driver from 8-STABLE and just got a panic. > > > The below is translation of the hand copied from console:- > mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > mfisyspd5: hard error cmd=write 90827650-90827905 > mfi0: I/O error, status= 46 scsi_status= 240 > mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > mfisyspd5: hard error cmd=write 90827394-90827649 > mfi0: I/O error, status= 46 scsi_status= 240 > mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > mfisyspd5: hard error cmd=write 90827138-90827393 > mfi0: I/O error, status= 46 scsi_status= 240 > mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > mfisyspd5: hard error cmd=write 90826882-90827137 > mfi0: I/O error, status= 2 scsi_status= 2 > mfi0: sense error 112, sense_key 6, asc 41, ascq 0 > mfisyspd4: hard error cmd=write 90830466-90830721 > mfi0: I/O error, status= 2 scsi_status= 2 > mfi0: sense error 112, sense_key 6, asc 41, ascq 0 > mfisyspd5: hard error cmd=write 90830722-90830977 > mfi0: Adapter RESET condition detected > mfi0: First state FW reset initiated... > mfi0: ADP_RESET_TBOLT: HostDiag=a0 > mfi0: first state of reset complete, second state initiated... > mfi0: Second state FW reset initiated... > panic: _mtx_lock_sleep: recursed on non-recusive mutex MFI I/O lock @ /usr/src/sys/dev/mfi/mfi_tbolt:346 > > cpuid = 6 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x178 > _mtx_lock_sleep() at _mtx_lock_sleep+0x152 > _mtx_lock_flags() at _mtx_lock_flags+0x80 > mfi_tbolt_init_MFI_queue() at mfi_tbolt_init_MFI_queue+0x72 > mfi_timeout() at mfi_timeout+0x27 > softclock() at softclock+0x2aa > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > ithread_loop() at ithread_loop+0xb2 > fork_exit() at fork_exit+0x135 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80005ccd00, rbp = 0 --- > KDB: enter panic > [thread pid 12 tid 100020 ] > Stopperd at kdb_enter+0x3b: movq $0,0x51cb32(%rip) > db> > > So questions:- > 1. What are the "hard error" errors? The machine was testing IO > with dd but due to the panic I cant tell if that was the cause. > 2. Looking at the code this seems like the reset was tripped by > firmware bug, is that the case? > 3. Is the fix the panic a simple one we cat test? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 17:07:34 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD0AAEE1; Mon, 5 Nov 2012 17:07:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F14928FC0A; Mon, 5 Nov 2012 17:07:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07201; Mon, 05 Nov 2012 19:07:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5097F24D.7040206@FreeBSD.org> Date: Mon, 05 Nov 2012 19:07:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:07:34 -0000 on 05/11/2012 16:52 Tom Lislegaard said the following: > > >> -----Original Message----- >> From: Andriy Gapon [mailto:avg@FreeBSD.org] >> Sent: 5. november 2012 15:21 >> To: Tom Lislegaard >> Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >> >> on 05/11/2012 15:54 Tom Lislegaard said the following: >>> Here's the distribution from running devd over 40 minutes >>> >>> 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 notify=0x81' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=dsp4.1' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=vboxdrv0' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=dsp4.1' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=vboxdrv0' >>> >>> Any use in running it over a longer period of time? >> >> Very interesting. >> So the processors get _CST change notifications rather frequently, but there is no obvious >> source/cause for them... >> >> Could you please send to me acpidump -dt output or upload it somewhere and post a link? > > Here you go > > https://dl.dropbox.com/u/13263820/acpidump.txt So, ACPI platform on your machine sends 0x81 notification for processors objects each time "_PSR" method of AC Adapter / Power Source device is queried. There could be a number of reason to invoke the method - either AC line status queries from userland (some battery / line monitoring program/applet) or internal ACPI notifications. Are you willing to go as far as recompiling your kernel with 'options ACPI_DEBUG' to get to the bottom of this issue? If yes, then please do that and also add the following lines to loader.conf: debug.acpi.layer="ACPI_EVENTS ACPI_AC_ADAPTER" debug.acpi.level="ACPI_LV_INFO" I would be interested in all periodically occurring ACPI debug messages (after boot is finished). I suspect that the ACPI platform and/or embedded controller send too many notifications when they are not strictly necessary. Maybe there is a BIOS update for your machine? In any case, I am starting to work on a patch that should fix this problem without resorting to any special configuration. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 5 21:29:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 163855CD; Mon, 5 Nov 2012 21:29:14 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 973628FC08; Mon, 5 Nov 2012 21:29:13 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 05 Nov 2012 13:30:30 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id qA5LTCS6019319; Mon, 5 Nov 2012 13:29:12 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id qA5LTBl2019318; Mon, 5 Nov 2012 13:29:11 -0800 (PST) (envelope-from ambrisko) Date: Mon, 5 Nov 2012 13:29:11 -0800 From: Doug Ambrisko To: Steven Hartland Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Message-ID: <20121105212911.GA17904@ambrisko.com> References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:29:14 -0000 --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 05, 2012 at 04:55:11PM -0000, Steven Hartland wrote: | I've managed to get the machine to reproduce this fairly regularly | now. | | Without a debug kernel it still results in a panic, just at a later | stage or so I believe, the none debug panic messages is "command not | in queue". | | In each none debug panic I've seen the cm_flags indicates the | command being dequeued is on the busy queue and not on the expected | free or ready queue which is being processed at the time. | | The triggering issue seems to be the adapter reset code run from | mfi_timeout. | | I've had a good look but can't see how a cm could be in a queue yet | have its cm_flags set to that of a different queue as all manipulation | seems to be being done via the "mfi_ ## name" macros which | all correctly maintain the queue / cm_flags relationship. | | At this point I believe it could be a thread being interrupted by | a timeout part way the processing of a queue request hence queue | and cm_flags being out of sync. | | Any pointers on how to debug this issue further / fix it would be most | appreciated. | | Regards | Steve | | ----- Original Message ----- | From: "Steven Hartland" | >Testing a new machine which is based on 8.3-RELEASE with the mfi | >driver from 8-STABLE and just got a panic. | > | > | >The below is translation of the hand copied from console:- | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 | >mfisyspd5: hard error cmd=write 90827650-90827905 | >mfi0: I/O error, status= 46 scsi_status= 240 | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 | >mfisyspd5: hard error cmd=write 90827394-90827649 | >mfi0: I/O error, status= 46 scsi_status= 240 | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 | >mfisyspd5: hard error cmd=write 90827138-90827393 | >mfi0: I/O error, status= 46 scsi_status= 240 | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 | >mfisyspd5: hard error cmd=write 90826882-90827137 | >mfi0: I/O error, status= 2 scsi_status= 2 | >mfi0: sense error 112, sense_key 6, asc 41, ascq 0 | >mfisyspd4: hard error cmd=write 90830466-90830721 | >mfi0: I/O error, status= 2 scsi_status= 2 | >mfi0: sense error 112, sense_key 6, asc 41, ascq 0 | >mfisyspd5: hard error cmd=write 90830722-90830977 | >mfi0: Adapter RESET condition detected | >mfi0: First state FW reset initiated... | >mfi0: ADP_RESET_TBOLT: HostDiag=a0 | >mfi0: first state of reset complete, second state initiated... | >mfi0: Second state FW reset initiated... | >panic: _mtx_lock_sleep: recursed on non-recusive mutex MFI I/O lock @ | >/usr/src/sys/dev/mfi/mfi_tbolt:346 | > | >cpuid = 6 | >KDB: stack backtrace: | >db_trace_self_wrapper() at db_trace_self_wrapper+0x2a | >kdb_backtrace() at kdb_backtrace+0x37 | >panic() at panic+0x178 | >_mtx_lock_sleep() at _mtx_lock_sleep+0x152 | >_mtx_lock_flags() at _mtx_lock_flags+0x80 | >mfi_tbolt_init_MFI_queue() at mfi_tbolt_init_MFI_queue+0x72 | >mfi_timeout() at mfi_timeout+0x27 | >softclock() at softclock+0x2aa | >intr_event_execute_handlers() at intr_event_execute_handlers+0x66 | >ithread_loop() at ithread_loop+0xb2 | >fork_exit() at fork_exit+0x135 | >fork_trampoline() at fork_trampoline+0xe | >--- trap 0, rip = 0, rsp = 0xffffff80005ccd00, rbp = 0 --- | >KDB: enter panic | >[thread pid 12 tid 100020 ] | >Stopperd at kdb_enter+0x3b: movq $0,0x51cb32(%rip) | >db> | > | >So questions:- | >1. What are the "hard error" errors? The machine was testing IO | >with dd but due to the panic I cant tell if that was the cause. | >2. Looking at the code this seems like the reset was tripped by | >firmware bug, is that the case? | >3. Is the fix the panic a simple one we cat test? As soon as I get caught up on email, I'll be checking in some updates that fix a bunch of issues. I don't know if it will fix this but it could help. At any case it would get us to a common base line to look at debugging this. The patch is attached and follows. It is relative to -head. It should be easy to head and this to stable. Index: mfi_tbolt.c =================================================================== --- mfi_tbolt.c (revision 242617) +++ mfi_tbolt.c (working copy) @@ -69,13 +69,10 @@ mfi_build_mpt_pass_thru(struct mfi_softc *sc, struct mfi_command *mfi_cmd); union mfi_mpi2_request_descriptor *mfi_build_and_issue_cmd(struct mfi_softc *sc, struct mfi_command *mfi_cmd); -int mfi_tbolt_is_ldio(struct mfi_command *mfi_cmd); void mfi_tbolt_build_ldio(struct mfi_softc *sc, struct mfi_command *mfi_cmd, struct mfi_cmd_tbolt *cmd); static int mfi_tbolt_make_sgl(struct mfi_softc *sc, struct mfi_command *mfi_cmd, pMpi25IeeeSgeChain64_t sgl_ptr, struct mfi_cmd_tbolt *cmd); -static int mfi_tbolt_build_cdb(struct mfi_softc *sc, struct mfi_command - *mfi_cmd, uint8_t *cdb); void map_tbolt_cmd_status(struct mfi_command *mfi_cmd, uint8_t status, uint8_t ext_status); @@ -502,6 +499,7 @@ + i * MEGASAS_MAX_SZ_CHAIN_FRAME); cmd->sg_frame_phys_addr = sc->sg_frame_busaddr + i * MEGASAS_MAX_SZ_CHAIN_FRAME; + cmd->sync_cmd_idx = sc->mfi_max_fw_cmds; TAILQ_INSERT_TAIL(&(sc->mfi_cmd_tbolt_tqh), cmd, next); } @@ -608,6 +606,8 @@ } } +int outstanding = 0; + /* * mfi_tbolt_return_cmd - Return a cmd to free command pool * @instance: Adapter soft state @@ -618,7 +618,9 @@ { mtx_assert(&sc->mfi_io_lock, MA_OWNED); + cmd->sync_cmd_idx = sc->mfi_max_fw_cmds; TAILQ_INSERT_TAIL(&sc->mfi_cmd_tbolt_tqh, cmd, next); + outstanding--; } void @@ -667,16 +669,27 @@ extStatus = cmd_mfi->cm_frame->dcmd.header.scsi_status; map_tbolt_cmd_status(cmd_mfi, status, extStatus); - /* remove command from busy queue if not polled */ - TAILQ_FOREACH(cmd_mfi_check, &sc->mfi_busy, cm_link) { - if (cmd_mfi_check == cmd_mfi) { - mfi_remove_busy(cmd_mfi); - break; + if (cmd_mfi->cm_flags & MFI_CMD_SCSI && + (cmd_mfi->cm_flags & MFI_CMD_POLLED) != 0) { + /* polled LD/SYSPD IO command */ + cmd_mfi->cm_error = 0; + cmd_mfi->cm_frame->header.cmd_status = 0; + mfi_tbolt_return_cmd(sc, cmd_tbolt); + } else { + + /* remove command from busy queue if not polled */ + TAILQ_FOREACH(cmd_mfi_check, &sc->mfi_busy, cm_link) { + if (cmd_mfi_check == cmd_mfi) { + mfi_remove_busy(cmd_mfi); + break; + } } + + /* complete the command */ + cmd_mfi->cm_error = 0; + mfi_complete(sc, cmd_mfi); + mfi_tbolt_return_cmd(sc, cmd_tbolt); } - cmd_mfi->cm_error = 0; - mfi_complete(sc, cmd_mfi); - mfi_tbolt_return_cmd(sc, cmd_tbolt); sc->last_reply_idx++; if (sc->last_reply_idx >= sc->mfi_max_fw_cmds) { @@ -746,6 +759,7 @@ p = sc->request_desc_pool + sizeof(union mfi_mpi2_request_descriptor) * index; memset(p, 0, sizeof(union mfi_mpi2_request_descriptor)); + outstanding++; return (union mfi_mpi2_request_descriptor *)p; } @@ -811,13 +825,13 @@ MFI_FRAME_DIR_READ) io_info.isRead = 1; - io_request->RaidContext.timeoutValue - = MFI_FUSION_FP_DEFAULT_TIMEOUT; - io_request->Function = MPI2_FUNCTION_LD_IO_REQUEST; - io_request->DevHandle = device_id; - cmd->request_desc->header.RequestFlags - = (MFI_REQ_DESCRIPT_FLAGS_LD_IO - << MFI_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); + io_request->RaidContext.timeoutValue + = MFI_FUSION_FP_DEFAULT_TIMEOUT; + io_request->Function = MPI2_FUNCTION_LD_IO_REQUEST; + io_request->DevHandle = device_id; + cmd->request_desc->header.RequestFlags + = (MFI_REQ_DESCRIPT_FLAGS_LD_IO + << MFI_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); if ((io_request->IoFlags == 6) && (io_info.numBlocks == 0)) io_request->RaidContext.RegLockLength = 0x100; io_request->DataLength = mfi_cmd->cm_frame->io.header.data_len @@ -825,41 +839,37 @@ } int -mfi_tbolt_is_ldio(struct mfi_command *mfi_cmd) -{ - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_READ - || mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - return 1; - else - return 0; -} - -int mfi_tbolt_build_io(struct mfi_softc *sc, struct mfi_command *mfi_cmd, struct mfi_cmd_tbolt *cmd) { - uint32_t device_id; + struct mfi_mpi2_request_raid_scsi_io *io_request; uint32_t sge_count; - uint8_t cdb[32], cdb_len; + uint8_t cdb_len; + int readop; + u_int64_t lba; - memset(cdb, 0, 32); - struct mfi_mpi2_request_raid_scsi_io *io_request = cmd->io_request; - - device_id = mfi_cmd->cm_frame->header.target_id; - - /* Have to build CDB here for TB as BSD don't have a scsi layer */ - if ((cdb_len = mfi_tbolt_build_cdb(sc, mfi_cmd, cdb)) == 1) + io_request = cmd->io_request; + if (!(mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_READ + || mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE)) return 1; - /* Just the CDB length,rest of the Flags are zero */ - io_request->IoFlags = cdb_len; - memcpy(io_request->CDB.CDB32, cdb, 32); + mfi_tbolt_build_ldio(sc, mfi_cmd, cmd); - if (mfi_tbolt_is_ldio(mfi_cmd)) - mfi_tbolt_build_ldio(sc, mfi_cmd , cmd); + /* Convert to SCSI command CDB */ + bzero(io_request->CDB.CDB32, sizeof(io_request->CDB.CDB32)); + if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) + readop = 0; else - return 1; + readop = 1; + lba = mfi_cmd->cm_frame->io.lba_hi; + lba = (lba << 32) + mfi_cmd->cm_frame->io.lba_lo; + cdb_len = mfi_build_cdb(readop, 0, lba, + mfi_cmd->cm_frame->io.header.data_len, io_request->CDB.CDB32); + + /* Just the CDB length, rest of the Flags are zero */ + io_request->IoFlags = cdb_len; + /* * Construct SGL */ @@ -883,85 +893,13 @@ io_request->SenseBufferLowAddress = mfi_cmd->cm_sense_busaddr; io_request->SenseBufferLength = MFI_SENSE_LEN; + io_request->RaidContext.Status = MFI_STAT_INVALID_STATUS; + io_request->RaidContext.exStatus = MFI_STAT_INVALID_STATUS; + return 0; } -static int -mfi_tbolt_build_cdb(struct mfi_softc *sc, struct mfi_command *mfi_cmd, - uint8_t *cdb) -{ - uint32_t lba_lo, lba_hi, num_lba; - uint8_t cdb_len; - if (mfi_cmd == NULL || cdb == NULL) - return 1; - num_lba = mfi_cmd->cm_frame->io.header.data_len; - lba_lo = mfi_cmd->cm_frame->io.lba_lo; - lba_hi = mfi_cmd->cm_frame->io.lba_hi; - - if (lba_hi == 0 && (num_lba <= 0xFF) && (lba_lo <= 0x1FFFFF)) { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - /* Read 6 or Write 6 */ - cdb[0] = (uint8_t) (0x0A); - else - cdb[0] = (uint8_t) (0x08); - - cdb[4] = (uint8_t) num_lba; - cdb[3] = (uint8_t) (lba_lo & 0xFF); - cdb[2] = (uint8_t) (lba_lo >> 8); - cdb[1] = (uint8_t) ((lba_lo >> 16) & 0x1F); - cdb_len = 6; - } - else if (lba_hi == 0 && (num_lba <= 0xFFFF) && (lba_lo <= 0xFFFFFFFF)) { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - /* Read 10 or Write 10 */ - cdb[0] = (uint8_t) (0x2A); - else - cdb[0] = (uint8_t) (0x28); - cdb[8] = (uint8_t) (num_lba & 0xFF); - cdb[7] = (uint8_t) (num_lba >> 8); - cdb[5] = (uint8_t) (lba_lo & 0xFF); - cdb[4] = (uint8_t) (lba_lo >> 8); - cdb[3] = (uint8_t) (lba_lo >> 16); - cdb[2] = (uint8_t) (lba_lo >> 24); - cdb_len = 10; - } else if ((num_lba > 0xFFFF) && (lba_hi == 0)) { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - /* Read 12 or Write 12 */ - cdb[0] = (uint8_t) (0xAA); - else - cdb[0] = (uint8_t) (0xA8); - cdb[9] = (uint8_t) (num_lba & 0xFF); - cdb[8] = (uint8_t) (num_lba >> 8); - cdb[7] = (uint8_t) (num_lba >> 16); - cdb[6] = (uint8_t) (num_lba >> 24); - cdb[5] = (uint8_t) (lba_lo & 0xFF); - cdb[4] = (uint8_t) (lba_lo >> 8); - cdb[3] = (uint8_t) (lba_lo >> 16); - cdb[2] = (uint8_t) (lba_lo >> 24); - cdb_len = 12; - } else { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - cdb[0] = (uint8_t) (0x8A); - else - cdb[0] = (uint8_t) (0x88); - cdb[13] = (uint8_t) (num_lba & 0xFF); - cdb[12] = (uint8_t) (num_lba >> 8); - cdb[11] = (uint8_t) (num_lba >> 16); - cdb[10] = (uint8_t) (num_lba >> 24); - cdb[9] = (uint8_t) (lba_lo & 0xFF); - cdb[8] = (uint8_t) (lba_lo >> 8); - cdb[7] = (uint8_t) (lba_lo >> 16); - cdb[6] = (uint8_t) (lba_lo >> 24); - cdb[5] = (uint8_t) (lba_hi & 0xFF); - cdb[4] = (uint8_t) (lba_hi >> 8); - cdb[3] = (uint8_t) (lba_hi >> 16); - cdb[2] = (uint8_t) (lba_hi >> 24); - cdb_len = 16; - } - return cdb_len; -} - static int mfi_tbolt_make_sgl(struct mfi_softc *sc, struct mfi_command *mfi_cmd, pMpi25IeeeSgeChain64_t sgl_ptr, struct mfi_cmd_tbolt *cmd) @@ -1100,8 +1038,7 @@ if ((cm->cm_flags & MFI_CMD_POLLED) == 0) { cm->cm_timestamp = time_uptime; mfi_enqueue_busy(cm); - } - else { /* still get interrupts for it */ + } else { /* still get interrupts for it */ hdr->cmd_status = MFI_STAT_INVALID_STATUS; hdr->flags |= MFI_FRAME_DONT_POST_IN_REPLY_QUEUE; } @@ -1118,31 +1055,49 @@ } else device_printf(sc->mfi_dev, "DJA NA XXX SYSPDIO\n"); - } - else if (hdr->cmd == MFI_CMD_LD_SCSI_IO || + } else if (hdr->cmd == MFI_CMD_LD_SCSI_IO || hdr->cmd == MFI_CMD_LD_READ || hdr->cmd == MFI_CMD_LD_WRITE) { + cm->cm_flags |= MFI_CMD_SCSI; if ((req_desc = mfi_build_and_issue_cmd(sc, cm)) == NULL) { device_printf(sc->mfi_dev, "LDIO Failed \n"); return 1; } - } else - if ((req_desc = mfi_tbolt_build_mpt_cmd(sc, cm)) == NULL) { + } else if ((req_desc = mfi_tbolt_build_mpt_cmd(sc, cm)) == NULL) { device_printf(sc->mfi_dev, "Mapping from MFI to MPT " "Failed\n"); return 1; - } + } + + if (cm->cm_flags & MFI_CMD_SCSI) { + /* + * LD IO needs to be posted since it doesn't get + * acknowledged via a status update so have the + * controller reply via mfi_tbolt_complete_cmd. + */ + hdr->flags &= ~MFI_FRAME_DONT_POST_IN_REPLY_QUEUE; + } + MFI_WRITE4(sc, MFI_ILQP, (req_desc->words & 0xFFFFFFFF)); MFI_WRITE4(sc, MFI_IHQP, (req_desc->words >>0x20)); if ((cm->cm_flags & MFI_CMD_POLLED) == 0) return 0; + if (cm->cm_flags & MFI_CMD_SCSI) { + /* check reply queue */ + mfi_tbolt_complete_cmd(sc); + } + /* This is a polled command, so busy-wait for it to complete. */ while (hdr->cmd_status == MFI_STAT_INVALID_STATUS) { DELAY(1000); tm -= 1; if (tm <= 0) - break; + break; + if (cm->cm_flags & MFI_CMD_SCSI) { + /* check reply queue */ + mfi_tbolt_complete_cmd(sc); + } } if (hdr->cmd_status == MFI_STAT_INVALID_STATUS) { @@ -1375,7 +1330,7 @@ free(ld_sync, M_MFIBUF); goto out; } - + context = cmd->cm_frame->header.context; bzero(cmd->cm_frame, sizeof(union mfi_frame)); cmd->cm_frame->header.context = context; Index: mfi_disk.c =================================================================== --- mfi_disk.c (revision 242617) +++ mfi_disk.c (working copy) @@ -93,6 +93,7 @@ { struct mfi_disk *sc; struct mfi_ld_info *ld_info; + struct mfi_disk_pending *ld_pend; uint64_t sectors; uint32_t secsize; char *state; @@ -111,6 +112,13 @@ secsize = MFI_SECTOR_LEN; mtx_lock(&sc->ld_controller->mfi_io_lock); TAILQ_INSERT_TAIL(&sc->ld_controller->mfi_ld_tqh, sc, ld_link); + TAILQ_FOREACH(ld_pend, &sc->ld_controller->mfi_ld_pend_tqh, + ld_link) { + TAILQ_REMOVE(&sc->ld_controller->mfi_ld_pend_tqh, + ld_pend, ld_link); + free(ld_pend, M_MFIBUF); + break; + } mtx_unlock(&sc->ld_controller->mfi_io_lock); switch (ld_info->ld_config.params.state) { @@ -131,16 +139,16 @@ break; } - if ( strlen(ld_info->ld_config.properties.name) == 0 ) { - device_printf(dev, - "%juMB (%ju sectors) RAID volume (no label) is %s\n", - sectors / (1024 * 1024 / secsize), sectors, state); - } else { - device_printf(dev, - "%juMB (%ju sectors) RAID volume '%s' is %s\n", - sectors / (1024 * 1024 / secsize), sectors, - ld_info->ld_config.properties.name, state); - } + if ( strlen(ld_info->ld_config.properties.name) == 0 ) { + device_printf(dev, + "%juMB (%ju sectors) RAID volume (no label) is %s\n", + sectors / (1024 * 1024 / secsize), sectors, state); + } else { + device_printf(dev, + "%juMB (%ju sectors) RAID volume '%s' is %s\n", + sectors / (1024 * 1024 / secsize), sectors, + ld_info->ld_config.properties.name, state); + } sc->ld_disk = disk_alloc(); sc->ld_disk->d_drv1 = sc; Index: mfivar.h =================================================================== --- mfivar.h (revision 242617) +++ mfivar.h (working copy) @@ -106,6 +106,7 @@ #define MFI_ON_MFIQ_READY (1<<6) #define MFI_ON_MFIQ_BUSY (1<<7) #define MFI_ON_MFIQ_MASK ((1<<5)|(1<<6)|(1<<7)) +#define MFI_CMD_SCSI (1<<8) uint8_t retry_for_fw_reset; void (* cm_complete)(struct mfi_command *cm); void *cm_private; @@ -126,6 +127,11 @@ #define MFI_DISK_FLAGS_DISABLED 0x02 }; +struct mfi_disk_pending { + TAILQ_ENTRY(mfi_disk_pending) ld_link; + int ld_id; +}; + struct mfi_system_pd { TAILQ_ENTRY(mfi_system_pd) pd_link; device_t pd_dev; @@ -137,6 +143,11 @@ int pd_flags; }; +struct mfi_system_pending { + TAILQ_ENTRY(mfi_system_pending) pd_link; + int pd_id; +}; + struct mfi_evt_queue_elm { TAILQ_ENTRY(mfi_evt_queue_elm) link; struct mfi_evt_detail detail; @@ -285,6 +296,8 @@ TAILQ_HEAD(,mfi_disk) mfi_ld_tqh; TAILQ_HEAD(,mfi_system_pd) mfi_syspd_tqh; + TAILQ_HEAD(,mfi_disk_pending) mfi_ld_pend_tqh; + TAILQ_HEAD(,mfi_system_pending) mfi_syspd_pend_tqh; eventhandler_tag mfi_eh; struct cdev *mfi_cdev; @@ -421,7 +434,8 @@ extern void mfi_tbolt_sync_map_info(struct mfi_softc *sc); extern void mfi_handle_map_sync(void *context, int pending); extern int mfi_dcmd_command(struct mfi_softc *, struct mfi_command **, - uint32_t, void **, size_t); + uint32_t, void **, size_t); +extern int mfi_build_cdb(int, uint8_t, u_int64_t, u_int32_t, uint8_t *); #define MFIQ_ADD(sc, qname) \ do { \ Index: mfi.c =================================================================== --- mfi.c (revision 242617) +++ mfi.c (working copy) @@ -106,11 +106,9 @@ static struct mfi_command * mfi_bio_command(struct mfi_softc *); static void mfi_bio_complete(struct mfi_command *); static struct mfi_command *mfi_build_ldio(struct mfi_softc *,struct bio*); -static int mfi_build_syspd_cdb(struct mfi_pass_frame *pass, uint32_t block_count, - uint64_t lba, uint8_t byte2, int readop); static struct mfi_command *mfi_build_syspdio(struct mfi_softc *,struct bio*); static int mfi_send_frame(struct mfi_softc *, struct mfi_command *); -static int mfi_abort(struct mfi_softc *, struct mfi_command *); +static int mfi_abort(struct mfi_softc *, struct mfi_command **); static int mfi_linux_ioctl_int(struct cdev *, u_long, caddr_t, int, struct thread *); static void mfi_timeout(void *); static int mfi_user_command(struct mfi_softc *, @@ -376,6 +374,8 @@ sx_init(&sc->mfi_config_lock, "MFI config"); TAILQ_INIT(&sc->mfi_ld_tqh); TAILQ_INIT(&sc->mfi_syspd_tqh); + TAILQ_INIT(&sc->mfi_ld_pend_tqh); + TAILQ_INIT(&sc->mfi_syspd_pend_tqh); TAILQ_INIT(&sc->mfi_evt_queue); TASK_INIT(&sc->mfi_evt_task, 0, mfi_handle_evt, sc); TASK_INIT(&sc->mfi_map_sync_task, 0, mfi_handle_map_sync, sc); @@ -1281,6 +1281,17 @@ struct mfi_command *cm; int error; + + if (sc->mfi_aen_cm) + sc->cm_aen_abort = 1; + if (sc->mfi_aen_cm != NULL) + mfi_abort(sc, &sc->mfi_aen_cm); + + if (sc->mfi_map_sync_cm) + sc->cm_map_abort = 1; + if (sc->mfi_map_sync_cm != NULL) + mfi_abort(sc, &sc->mfi_map_sync_cm); + mtx_lock(&sc->mfi_io_lock); error = mfi_dcmd_command(sc, &cm, MFI_DCMD_CTRL_SHUTDOWN, NULL, 0); if (error) { @@ -1288,12 +1299,6 @@ return (error); } - if (sc->mfi_aen_cm != NULL) - mfi_abort(sc, sc->mfi_aen_cm); - - if (sc->mfi_map_sync_cm != NULL) - mfi_abort(sc, sc->mfi_map_sync_cm); - dcmd = &cm->cm_frame->dcmd; dcmd->header.flags = MFI_FRAME_DIR_NONE; cm->cm_flags = MFI_CMD_POLLED; @@ -1315,6 +1320,7 @@ struct mfi_command *cm = NULL; struct mfi_pd_list *pdlist = NULL; struct mfi_system_pd *syspd, *tmp; + struct mfi_system_pending *syspd_pend; int error, i, found; sx_assert(&sc->mfi_config_lock, SA_XLOCKED); @@ -1355,6 +1361,10 @@ if (syspd->pd_id == pdlist->addr[i].device_id) found = 1; } + TAILQ_FOREACH(syspd_pend, &sc->mfi_syspd_pend_tqh, pd_link) { + if (syspd_pend->pd_id == pdlist->addr[i].device_id) + found = 1; + } if (found == 0) mfi_add_sys_pd(sc, pdlist->addr[i].device_id); } @@ -1390,6 +1400,7 @@ struct mfi_command *cm = NULL; struct mfi_ld_list *list = NULL; struct mfi_disk *ld; + struct mfi_disk_pending *ld_pend; int error, i; sx_assert(&sc->mfi_config_lock, SA_XLOCKED); @@ -1418,6 +1429,10 @@ if (ld->ld_id == list->ld_list[i].ld.v.target_id) goto skip_add; } + TAILQ_FOREACH(ld_pend, &sc->mfi_ld_pend_tqh, ld_link) { + if (ld_pend->ld_id == list->ld_list[i].ld.v.target_id) + goto skip_add; + } mfi_add_ld(sc, list->ld_list[i].ld.v.target_id); skip_add:; } @@ -1620,9 +1635,7 @@ < current_aen.members.evt_class) current_aen.members.evt_class = prior_aen.members.evt_class; - mtx_lock(&sc->mfi_io_lock); - mfi_abort(sc, sc->mfi_aen_cm); - mtx_unlock(&sc->mfi_io_lock); + mfi_abort(sc, &sc->mfi_aen_cm); } } @@ -1814,10 +1827,17 @@ struct mfi_command *cm; struct mfi_dcmd_frame *dcmd = NULL; struct mfi_ld_info *ld_info = NULL; + struct mfi_disk_pending *ld_pend; int error; mtx_assert(&sc->mfi_io_lock, MA_OWNED); + ld_pend = malloc(sizeof(*ld_pend), M_MFIBUF, M_NOWAIT | M_ZERO); + if (ld_pend != NULL) { + ld_pend->ld_id = id; + TAILQ_INSERT_TAIL(&sc->mfi_ld_pend_tqh, ld_pend, ld_link); + } + error = mfi_dcmd_command(sc, &cm, MFI_DCMD_LD_GET_INFO, (void **)&ld_info, sizeof(*ld_info)); if (error) { @@ -1858,11 +1878,13 @@ hdr = &cm->cm_frame->header; ld_info = cm->cm_private; - if (hdr->cmd_status != MFI_STAT_OK) { + if (sc->cm_map_abort || hdr->cmd_status != MFI_STAT_OK) { free(ld_info, M_MFIBUF); + wakeup(&sc->mfi_map_sync_cm); mfi_release_command(cm); return; } + wakeup(&sc->mfi_map_sync_cm); mfi_release_command(cm); mtx_unlock(&sc->mfi_io_lock); @@ -1887,10 +1909,17 @@ struct mfi_command *cm; struct mfi_dcmd_frame *dcmd = NULL; struct mfi_pd_info *pd_info = NULL; + struct mfi_system_pending *syspd_pend; int error; mtx_assert(&sc->mfi_io_lock, MA_OWNED); + syspd_pend = malloc(sizeof(*syspd_pend), M_MFIBUF, M_NOWAIT | M_ZERO); + if (syspd_pend != NULL) { + syspd_pend->pd_id = id; + TAILQ_INSERT_TAIL(&sc->mfi_syspd_pend_tqh, syspd_pend, pd_link); + } + error = mfi_dcmd_command(sc, &cm, MFI_DCMD_PD_GET_INFO, (void **)&pd_info, sizeof(*pd_info)); if (error) { @@ -1985,9 +2014,12 @@ return cm; } -static int -mfi_build_syspd_cdb(struct mfi_pass_frame *pass, uint32_t block_count, - uint64_t lba, uint8_t byte2, int readop) +/* + * mostly copied from cam/scsi/scsi_all.c:scsi_read_write + */ + +int +mfi_build_cdb(int readop, uint8_t byte2, u_int64_t lba, u_int32_t block_count, uint8_t *cdb) { int cdb_len; @@ -1997,7 +2029,7 @@ /* We can fit in a 6 byte cdb */ struct scsi_rw_6 *scsi_cmd; - scsi_cmd = (struct scsi_rw_6 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_6 *)cdb; scsi_cmd->opcode = readop ? READ_6 : WRITE_6; scsi_ulto3b(lba, scsi_cmd->addr); scsi_cmd->length = block_count & 0xff; @@ -2007,7 +2039,7 @@ /* Need a 10 byte CDB */ struct scsi_rw_10 *scsi_cmd; - scsi_cmd = (struct scsi_rw_10 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_10 *)cdb; scsi_cmd->opcode = readop ? READ_10 : WRITE_10; scsi_cmd->byte2 = byte2; scsi_ulto4b(lba, scsi_cmd->addr); @@ -2020,7 +2052,7 @@ /* Block count is too big for 10 byte CDB use a 12 byte CDB */ struct scsi_rw_12 *scsi_cmd; - scsi_cmd = (struct scsi_rw_12 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_12 *)cdb; scsi_cmd->opcode = readop ? READ_12 : WRITE_12; scsi_cmd->byte2 = byte2; scsi_ulto4b(lba, scsi_cmd->addr); @@ -2035,7 +2067,7 @@ */ struct scsi_rw_16 *scsi_cmd; - scsi_cmd = (struct scsi_rw_16 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_16 *)cdb; scsi_cmd->opcode = readop ? READ_16 : WRITE_16; scsi_cmd->byte2 = byte2; scsi_u64to8b(lba, scsi_cmd->addr); @@ -2053,15 +2085,15 @@ { struct mfi_command *cm; struct mfi_pass_frame *pass; - int flags = 0; + uint32_t context = 0; + int flags = 0, blkcount = 0, readop; uint8_t cdb_len; - uint32_t block_count, context = 0; if ((cm = mfi_dequeue_free(sc)) == NULL) return (NULL); /* Zero out the MFI frame */ - context = cm->cm_frame->header.context; + context = cm->cm_frame->header.context; bzero(cm->cm_frame, sizeof(union mfi_frame)); cm->cm_frame->header.context = context; pass = &cm->cm_frame->pass; @@ -2070,22 +2102,24 @@ switch (bio->bio_cmd & 0x03) { case BIO_READ: flags = MFI_CMD_DATAIN; + readop = 1; break; case BIO_WRITE: flags = MFI_CMD_DATAOUT; + readop = 0; break; default: /* TODO: what about BIO_DELETE??? */ - panic("Unsupported bio command"); + panic("Unsupported bio command %x\n", bio->bio_cmd); } /* Cheat with the sector length to avoid a non-constant division */ - block_count = (bio->bio_bcount + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; + blkcount = (bio->bio_bcount + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; /* Fill the LBA and Transfer length in CDB */ - cdb_len = mfi_build_syspd_cdb(pass, block_count, bio->bio_pblkno, 0, - flags == MFI_CMD_DATAIN); - + cdb_len = mfi_build_cdb(readop, 0, bio->bio_pblkno, blkcount, + pass->cdb); pass->header.target_id = (uintptr_t)bio->bio_driver1; + pass->header.lun_id = 0; pass->header.timeout = 0; pass->header.flags = 0; pass->header.scsi_status = 0; @@ -2132,7 +2166,7 @@ break; default: /* TODO: what about BIO_DELETE??? */ - panic("Unsupported bio command"); + panic("Unsupported bio command %x\n", bio->bio_cmd); } /* Cheat with the sector length to avoid a non-constant division */ @@ -2422,15 +2456,14 @@ } static int -mfi_abort(struct mfi_softc *sc, struct mfi_command *cm_abort) +mfi_abort(struct mfi_softc *sc, struct mfi_command **cm_abort) { struct mfi_command *cm; struct mfi_abort_frame *abort; int i = 0; uint32_t context = 0; - mtx_assert(&sc->mfi_io_lock, MA_OWNED); - + mtx_lock(&sc->mfi_io_lock); if ((cm = mfi_dequeue_free(sc)) == NULL) { return (EBUSY); } @@ -2444,29 +2477,27 @@ abort->header.cmd = MFI_CMD_ABORT; abort->header.flags = 0; abort->header.scsi_status = 0; - abort->abort_context = cm_abort->cm_frame->header.context; - abort->abort_mfi_addr_lo = (uint32_t)cm_abort->cm_frame_busaddr; + abort->abort_context = (*cm_abort)->cm_frame->header.context; + abort->abort_mfi_addr_lo = (uint32_t)(*cm_abort)->cm_frame_busaddr; abort->abort_mfi_addr_hi = - (uint32_t)((uint64_t)cm_abort->cm_frame_busaddr >> 32); + (uint32_t)((uint64_t)(*cm_abort)->cm_frame_busaddr >> 32); cm->cm_data = NULL; cm->cm_flags = MFI_CMD_POLLED; - if (sc->mfi_aen_cm) - sc->cm_aen_abort = 1; - if (sc->mfi_map_sync_cm) - sc->cm_map_abort = 1; mfi_mapcmd(sc, cm); mfi_release_command(cm); - while (i < 5 && sc->mfi_aen_cm != NULL) { - msleep(&sc->mfi_aen_cm, &sc->mfi_io_lock, 0, "mfiabort", + mtx_unlock(&sc->mfi_io_lock); + while (i < 5 && *cm_abort != NULL) { + tsleep(cm_abort, 0, "mfiabort", 5 * hz); i++; } - while (i < 5 && sc->mfi_map_sync_cm != NULL) { - msleep(&sc->mfi_map_sync_cm, &sc->mfi_io_lock, 0, "mfiabort", - 5 * hz); - i++; + if (*cm_abort != NULL) { + /* Force a complete if command didn't abort */ + mtx_lock(&sc->mfi_io_lock); + (*cm_abort)->cm_complete(*cm_abort); + mtx_unlock(&sc->mfi_io_lock); } return (0); @@ -2522,7 +2553,7 @@ { struct mfi_command *cm; struct mfi_pass_frame *pass; - int error; + int error, readop, cdb_len; uint32_t blkcount; if ((cm = mfi_dequeue_free(sc)) == NULL) @@ -2531,21 +2562,24 @@ pass = &cm->cm_frame->pass; bzero(pass->cdb, 16); pass->header.cmd = MFI_CMD_PD_SCSI_IO; + + readop = 0; blkcount = (len + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; + cdb_len = mfi_build_cdb(readop, 0, lba, blkcount, pass->cdb); pass->header.target_id = id; pass->header.timeout = 0; pass->header.flags = 0; pass->header.scsi_status = 0; pass->header.sense_len = MFI_SENSE_LEN; pass->header.data_len = len; - pass->header.cdb_len = mfi_build_syspd_cdb(pass, blkcount, lba, 0, 0); + pass->header.cdb_len = cdb_len; pass->sense_addr_lo = (uint32_t)cm->cm_sense_busaddr; pass->sense_addr_hi = (uint32_t)((uint64_t)cm->cm_sense_busaddr >> 32); cm->cm_data = virt; cm->cm_len = len; cm->cm_sg = &pass->sgl; cm->cm_total_frame_size = MFI_PASS_FRAME_SIZE; - cm->cm_flags = MFI_CMD_POLLED | MFI_CMD_DATAOUT; + cm->cm_flags = MFI_CMD_POLLED | MFI_CMD_DATAOUT | MFI_CMD_SCSI; error = mfi_mapcmd(sc, cm); bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap, @@ -2745,16 +2779,24 @@ } } -static int mfi_check_for_sscd(struct mfi_softc *sc, struct mfi_command *cm) +static int +mfi_check_for_sscd(struct mfi_softc *sc, struct mfi_command *cm) { - struct mfi_config_data *conf_data=(struct mfi_config_data *)cm->cm_data; + struct mfi_config_data *conf_data; struct mfi_command *ld_cm = NULL; struct mfi_ld_info *ld_info = NULL; + struct mfi_ld_config *ld; + char *p; int error = 0; - if ((cm->cm_frame->dcmd.opcode == MFI_DCMD_CFG_ADD) && - (conf_data->ld[0].params.isSSCD == 1)) { - error = 1; + conf_data = (struct mfi_config_data *)cm->cm_data; + + if (cm->cm_frame->dcmd.opcode == MFI_DCMD_CFG_ADD) { + p = (char *)conf_data->array; + p += conf_data->array_size * conf_data->array_count; + ld = (struct mfi_ld_config *)p; + if (ld->params.isSSCD == 1) + error = 1; } else if (cm->cm_frame->dcmd.opcode == MFI_DCMD_LD_DELETE) { error = mfi_dcmd_command (sc, &ld_cm, MFI_DCMD_LD_GET_INFO, (void **)&ld_info, sizeof(*ld_info)); Index: mfi_cam.c =================================================================== --- mfi_cam.c (revision 242617) +++ mfi_cam.c (working copy) @@ -79,6 +79,11 @@ static struct mfi_command * mfip_start(void *); static void mfip_done(struct mfi_command *cm); +static int mfi_allow_disks = 0; +TUNABLE_INT("hw.mfi.allow_cam_disk_passthrough", &mfi_allow_disks); +SYSCTL_INT(_hw_mfi, OID_AUTO, allow_cam_disk_passthrough, CTLFLAG_RD, + &mfi_allow_disks, 0, "event message locale"); + static devclass_t mfip_devclass; static device_method_t mfip_methods[] = { DEVMETHOD(device_probe, mfip_probe), @@ -349,7 +354,8 @@ command = csio->cdb_io.cdb_bytes[0]; if (command == INQUIRY) { device = csio->data_ptr[0] & 0x1f; - if ((device == T_DIRECT) || (device == T_PROCESSOR)) + if ((!mfi_allow_disks && device == T_DIRECT) || + (device == T_PROCESSOR)) csio->data_ptr[0] = (csio->data_ptr[0] & 0xe0) | T_NODEVICE; } Index: mfi_syspd.c =================================================================== --- mfi_syspd.c (revision 242617) +++ mfi_syspd.c (working copy) @@ -89,7 +89,6 @@ static int mfi_syspd_probe(device_t dev) { - return (0); } @@ -98,12 +97,12 @@ { struct mfi_system_pd *sc; struct mfi_pd_info *pd_info; + struct mfi_system_pending *syspd_pend; uint64_t sectors; uint32_t secsize; sc = device_get_softc(dev); pd_info = device_get_ivars(dev); - sc->pd_dev = dev; sc->pd_id = pd_info->ref.v.device_id; sc->pd_unit = device_get_unit(dev); @@ -115,6 +114,13 @@ secsize = MFI_SECTOR_LEN; mtx_lock(&sc->pd_controller->mfi_io_lock); TAILQ_INSERT_TAIL(&sc->pd_controller->mfi_syspd_tqh, sc, pd_link); + TAILQ_FOREACH(syspd_pend, &sc->pd_controller->mfi_syspd_pend_tqh, + pd_link) { + TAILQ_REMOVE(&sc->pd_controller->mfi_syspd_pend_tqh, + syspd_pend, pd_link); + free(syspd_pend, M_MFIBUF); + break; + } mtx_unlock(&sc->pd_controller->mfi_io_lock); device_printf(dev, "%juMB (%ju sectors) SYSPD volume\n", sectors / (1024 * 1024 / secsize), sectors); @@ -139,6 +145,7 @@ disk_create(sc->pd_disk, DISK_VERSION); device_printf(dev, " SYSPD volume attached\n"); + return (0); } Thanks, Doug A. --kXdP64Ggrk/fb43R Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mfi.patch" Index: mfi_tbolt.c =================================================================== --- mfi_tbolt.c (revision 242617) +++ mfi_tbolt.c (working copy) @@ -69,13 +69,10 @@ mfi_build_mpt_pass_thru(struct mfi_softc *sc, struct mfi_command *mfi_cmd); union mfi_mpi2_request_descriptor *mfi_build_and_issue_cmd(struct mfi_softc *sc, struct mfi_command *mfi_cmd); -int mfi_tbolt_is_ldio(struct mfi_command *mfi_cmd); void mfi_tbolt_build_ldio(struct mfi_softc *sc, struct mfi_command *mfi_cmd, struct mfi_cmd_tbolt *cmd); static int mfi_tbolt_make_sgl(struct mfi_softc *sc, struct mfi_command *mfi_cmd, pMpi25IeeeSgeChain64_t sgl_ptr, struct mfi_cmd_tbolt *cmd); -static int mfi_tbolt_build_cdb(struct mfi_softc *sc, struct mfi_command - *mfi_cmd, uint8_t *cdb); void map_tbolt_cmd_status(struct mfi_command *mfi_cmd, uint8_t status, uint8_t ext_status); @@ -502,6 +499,7 @@ + i * MEGASAS_MAX_SZ_CHAIN_FRAME); cmd->sg_frame_phys_addr = sc->sg_frame_busaddr + i * MEGASAS_MAX_SZ_CHAIN_FRAME; + cmd->sync_cmd_idx = sc->mfi_max_fw_cmds; TAILQ_INSERT_TAIL(&(sc->mfi_cmd_tbolt_tqh), cmd, next); } @@ -608,6 +606,8 @@ } } +int outstanding = 0; + /* * mfi_tbolt_return_cmd - Return a cmd to free command pool * @instance: Adapter soft state @@ -618,7 +618,9 @@ { mtx_assert(&sc->mfi_io_lock, MA_OWNED); + cmd->sync_cmd_idx = sc->mfi_max_fw_cmds; TAILQ_INSERT_TAIL(&sc->mfi_cmd_tbolt_tqh, cmd, next); + outstanding--; } void @@ -667,16 +669,27 @@ extStatus = cmd_mfi->cm_frame->dcmd.header.scsi_status; map_tbolt_cmd_status(cmd_mfi, status, extStatus); - /* remove command from busy queue if not polled */ - TAILQ_FOREACH(cmd_mfi_check, &sc->mfi_busy, cm_link) { - if (cmd_mfi_check == cmd_mfi) { - mfi_remove_busy(cmd_mfi); - break; + if (cmd_mfi->cm_flags & MFI_CMD_SCSI && + (cmd_mfi->cm_flags & MFI_CMD_POLLED) != 0) { + /* polled LD/SYSPD IO command */ + cmd_mfi->cm_error = 0; + cmd_mfi->cm_frame->header.cmd_status = 0; + mfi_tbolt_return_cmd(sc, cmd_tbolt); + } else { + + /* remove command from busy queue if not polled */ + TAILQ_FOREACH(cmd_mfi_check, &sc->mfi_busy, cm_link) { + if (cmd_mfi_check == cmd_mfi) { + mfi_remove_busy(cmd_mfi); + break; + } } + + /* complete the command */ + cmd_mfi->cm_error = 0; + mfi_complete(sc, cmd_mfi); + mfi_tbolt_return_cmd(sc, cmd_tbolt); } - cmd_mfi->cm_error = 0; - mfi_complete(sc, cmd_mfi); - mfi_tbolt_return_cmd(sc, cmd_tbolt); sc->last_reply_idx++; if (sc->last_reply_idx >= sc->mfi_max_fw_cmds) { @@ -746,6 +759,7 @@ p = sc->request_desc_pool + sizeof(union mfi_mpi2_request_descriptor) * index; memset(p, 0, sizeof(union mfi_mpi2_request_descriptor)); + outstanding++; return (union mfi_mpi2_request_descriptor *)p; } @@ -811,13 +825,13 @@ MFI_FRAME_DIR_READ) io_info.isRead = 1; - io_request->RaidContext.timeoutValue - = MFI_FUSION_FP_DEFAULT_TIMEOUT; - io_request->Function = MPI2_FUNCTION_LD_IO_REQUEST; - io_request->DevHandle = device_id; - cmd->request_desc->header.RequestFlags - = (MFI_REQ_DESCRIPT_FLAGS_LD_IO - << MFI_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); + io_request->RaidContext.timeoutValue + = MFI_FUSION_FP_DEFAULT_TIMEOUT; + io_request->Function = MPI2_FUNCTION_LD_IO_REQUEST; + io_request->DevHandle = device_id; + cmd->request_desc->header.RequestFlags + = (MFI_REQ_DESCRIPT_FLAGS_LD_IO + << MFI_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); if ((io_request->IoFlags == 6) && (io_info.numBlocks == 0)) io_request->RaidContext.RegLockLength = 0x100; io_request->DataLength = mfi_cmd->cm_frame->io.header.data_len @@ -825,41 +839,37 @@ } int -mfi_tbolt_is_ldio(struct mfi_command *mfi_cmd) -{ - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_READ - || mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - return 1; - else - return 0; -} - -int mfi_tbolt_build_io(struct mfi_softc *sc, struct mfi_command *mfi_cmd, struct mfi_cmd_tbolt *cmd) { - uint32_t device_id; + struct mfi_mpi2_request_raid_scsi_io *io_request; uint32_t sge_count; - uint8_t cdb[32], cdb_len; + uint8_t cdb_len; + int readop; + u_int64_t lba; - memset(cdb, 0, 32); - struct mfi_mpi2_request_raid_scsi_io *io_request = cmd->io_request; - - device_id = mfi_cmd->cm_frame->header.target_id; - - /* Have to build CDB here for TB as BSD don't have a scsi layer */ - if ((cdb_len = mfi_tbolt_build_cdb(sc, mfi_cmd, cdb)) == 1) + io_request = cmd->io_request; + if (!(mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_READ + || mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE)) return 1; - /* Just the CDB length,rest of the Flags are zero */ - io_request->IoFlags = cdb_len; - memcpy(io_request->CDB.CDB32, cdb, 32); + mfi_tbolt_build_ldio(sc, mfi_cmd, cmd); - if (mfi_tbolt_is_ldio(mfi_cmd)) - mfi_tbolt_build_ldio(sc, mfi_cmd , cmd); + /* Convert to SCSI command CDB */ + bzero(io_request->CDB.CDB32, sizeof(io_request->CDB.CDB32)); + if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) + readop = 0; else - return 1; + readop = 1; + lba = mfi_cmd->cm_frame->io.lba_hi; + lba = (lba << 32) + mfi_cmd->cm_frame->io.lba_lo; + cdb_len = mfi_build_cdb(readop, 0, lba, + mfi_cmd->cm_frame->io.header.data_len, io_request->CDB.CDB32); + + /* Just the CDB length, rest of the Flags are zero */ + io_request->IoFlags = cdb_len; + /* * Construct SGL */ @@ -883,85 +893,13 @@ io_request->SenseBufferLowAddress = mfi_cmd->cm_sense_busaddr; io_request->SenseBufferLength = MFI_SENSE_LEN; + io_request->RaidContext.Status = MFI_STAT_INVALID_STATUS; + io_request->RaidContext.exStatus = MFI_STAT_INVALID_STATUS; + return 0; } -static int -mfi_tbolt_build_cdb(struct mfi_softc *sc, struct mfi_command *mfi_cmd, - uint8_t *cdb) -{ - uint32_t lba_lo, lba_hi, num_lba; - uint8_t cdb_len; - if (mfi_cmd == NULL || cdb == NULL) - return 1; - num_lba = mfi_cmd->cm_frame->io.header.data_len; - lba_lo = mfi_cmd->cm_frame->io.lba_lo; - lba_hi = mfi_cmd->cm_frame->io.lba_hi; - - if (lba_hi == 0 && (num_lba <= 0xFF) && (lba_lo <= 0x1FFFFF)) { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - /* Read 6 or Write 6 */ - cdb[0] = (uint8_t) (0x0A); - else - cdb[0] = (uint8_t) (0x08); - - cdb[4] = (uint8_t) num_lba; - cdb[3] = (uint8_t) (lba_lo & 0xFF); - cdb[2] = (uint8_t) (lba_lo >> 8); - cdb[1] = (uint8_t) ((lba_lo >> 16) & 0x1F); - cdb_len = 6; - } - else if (lba_hi == 0 && (num_lba <= 0xFFFF) && (lba_lo <= 0xFFFFFFFF)) { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - /* Read 10 or Write 10 */ - cdb[0] = (uint8_t) (0x2A); - else - cdb[0] = (uint8_t) (0x28); - cdb[8] = (uint8_t) (num_lba & 0xFF); - cdb[7] = (uint8_t) (num_lba >> 8); - cdb[5] = (uint8_t) (lba_lo & 0xFF); - cdb[4] = (uint8_t) (lba_lo >> 8); - cdb[3] = (uint8_t) (lba_lo >> 16); - cdb[2] = (uint8_t) (lba_lo >> 24); - cdb_len = 10; - } else if ((num_lba > 0xFFFF) && (lba_hi == 0)) { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - /* Read 12 or Write 12 */ - cdb[0] = (uint8_t) (0xAA); - else - cdb[0] = (uint8_t) (0xA8); - cdb[9] = (uint8_t) (num_lba & 0xFF); - cdb[8] = (uint8_t) (num_lba >> 8); - cdb[7] = (uint8_t) (num_lba >> 16); - cdb[6] = (uint8_t) (num_lba >> 24); - cdb[5] = (uint8_t) (lba_lo & 0xFF); - cdb[4] = (uint8_t) (lba_lo >> 8); - cdb[3] = (uint8_t) (lba_lo >> 16); - cdb[2] = (uint8_t) (lba_lo >> 24); - cdb_len = 12; - } else { - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) - cdb[0] = (uint8_t) (0x8A); - else - cdb[0] = (uint8_t) (0x88); - cdb[13] = (uint8_t) (num_lba & 0xFF); - cdb[12] = (uint8_t) (num_lba >> 8); - cdb[11] = (uint8_t) (num_lba >> 16); - cdb[10] = (uint8_t) (num_lba >> 24); - cdb[9] = (uint8_t) (lba_lo & 0xFF); - cdb[8] = (uint8_t) (lba_lo >> 8); - cdb[7] = (uint8_t) (lba_lo >> 16); - cdb[6] = (uint8_t) (lba_lo >> 24); - cdb[5] = (uint8_t) (lba_hi & 0xFF); - cdb[4] = (uint8_t) (lba_hi >> 8); - cdb[3] = (uint8_t) (lba_hi >> 16); - cdb[2] = (uint8_t) (lba_hi >> 24); - cdb_len = 16; - } - return cdb_len; -} - static int mfi_tbolt_make_sgl(struct mfi_softc *sc, struct mfi_command *mfi_cmd, pMpi25IeeeSgeChain64_t sgl_ptr, struct mfi_cmd_tbolt *cmd) @@ -1100,8 +1038,7 @@ if ((cm->cm_flags & MFI_CMD_POLLED) == 0) { cm->cm_timestamp = time_uptime; mfi_enqueue_busy(cm); - } - else { /* still get interrupts for it */ + } else { /* still get interrupts for it */ hdr->cmd_status = MFI_STAT_INVALID_STATUS; hdr->flags |= MFI_FRAME_DONT_POST_IN_REPLY_QUEUE; } @@ -1118,31 +1055,49 @@ } else device_printf(sc->mfi_dev, "DJA NA XXX SYSPDIO\n"); - } - else if (hdr->cmd == MFI_CMD_LD_SCSI_IO || + } else if (hdr->cmd == MFI_CMD_LD_SCSI_IO || hdr->cmd == MFI_CMD_LD_READ || hdr->cmd == MFI_CMD_LD_WRITE) { + cm->cm_flags |= MFI_CMD_SCSI; if ((req_desc = mfi_build_and_issue_cmd(sc, cm)) == NULL) { device_printf(sc->mfi_dev, "LDIO Failed \n"); return 1; } - } else - if ((req_desc = mfi_tbolt_build_mpt_cmd(sc, cm)) == NULL) { + } else if ((req_desc = mfi_tbolt_build_mpt_cmd(sc, cm)) == NULL) { device_printf(sc->mfi_dev, "Mapping from MFI to MPT " "Failed\n"); return 1; - } + } + + if (cm->cm_flags & MFI_CMD_SCSI) { + /* + * LD IO needs to be posted since it doesn't get + * acknowledged via a status update so have the + * controller reply via mfi_tbolt_complete_cmd. + */ + hdr->flags &= ~MFI_FRAME_DONT_POST_IN_REPLY_QUEUE; + } + MFI_WRITE4(sc, MFI_ILQP, (req_desc->words & 0xFFFFFFFF)); MFI_WRITE4(sc, MFI_IHQP, (req_desc->words >>0x20)); if ((cm->cm_flags & MFI_CMD_POLLED) == 0) return 0; + if (cm->cm_flags & MFI_CMD_SCSI) { + /* check reply queue */ + mfi_tbolt_complete_cmd(sc); + } + /* This is a polled command, so busy-wait for it to complete. */ while (hdr->cmd_status == MFI_STAT_INVALID_STATUS) { DELAY(1000); tm -= 1; if (tm <= 0) - break; + break; + if (cm->cm_flags & MFI_CMD_SCSI) { + /* check reply queue */ + mfi_tbolt_complete_cmd(sc); + } } if (hdr->cmd_status == MFI_STAT_INVALID_STATUS) { @@ -1375,7 +1330,7 @@ free(ld_sync, M_MFIBUF); goto out; } - + context = cmd->cm_frame->header.context; bzero(cmd->cm_frame, sizeof(union mfi_frame)); cmd->cm_frame->header.context = context; Index: mfi_disk.c =================================================================== --- mfi_disk.c (revision 242617) +++ mfi_disk.c (working copy) @@ -93,6 +93,7 @@ { struct mfi_disk *sc; struct mfi_ld_info *ld_info; + struct mfi_disk_pending *ld_pend; uint64_t sectors; uint32_t secsize; char *state; @@ -111,6 +112,13 @@ secsize = MFI_SECTOR_LEN; mtx_lock(&sc->ld_controller->mfi_io_lock); TAILQ_INSERT_TAIL(&sc->ld_controller->mfi_ld_tqh, sc, ld_link); + TAILQ_FOREACH(ld_pend, &sc->ld_controller->mfi_ld_pend_tqh, + ld_link) { + TAILQ_REMOVE(&sc->ld_controller->mfi_ld_pend_tqh, + ld_pend, ld_link); + free(ld_pend, M_MFIBUF); + break; + } mtx_unlock(&sc->ld_controller->mfi_io_lock); switch (ld_info->ld_config.params.state) { @@ -131,16 +139,16 @@ break; } - if ( strlen(ld_info->ld_config.properties.name) == 0 ) { - device_printf(dev, - "%juMB (%ju sectors) RAID volume (no label) is %s\n", - sectors / (1024 * 1024 / secsize), sectors, state); - } else { - device_printf(dev, - "%juMB (%ju sectors) RAID volume '%s' is %s\n", - sectors / (1024 * 1024 / secsize), sectors, - ld_info->ld_config.properties.name, state); - } + if ( strlen(ld_info->ld_config.properties.name) == 0 ) { + device_printf(dev, + "%juMB (%ju sectors) RAID volume (no label) is %s\n", + sectors / (1024 * 1024 / secsize), sectors, state); + } else { + device_printf(dev, + "%juMB (%ju sectors) RAID volume '%s' is %s\n", + sectors / (1024 * 1024 / secsize), sectors, + ld_info->ld_config.properties.name, state); + } sc->ld_disk = disk_alloc(); sc->ld_disk->d_drv1 = sc; Index: mfivar.h =================================================================== --- mfivar.h (revision 242617) +++ mfivar.h (working copy) @@ -106,6 +106,7 @@ #define MFI_ON_MFIQ_READY (1<<6) #define MFI_ON_MFIQ_BUSY (1<<7) #define MFI_ON_MFIQ_MASK ((1<<5)|(1<<6)|(1<<7)) +#define MFI_CMD_SCSI (1<<8) uint8_t retry_for_fw_reset; void (* cm_complete)(struct mfi_command *cm); void *cm_private; @@ -126,6 +127,11 @@ #define MFI_DISK_FLAGS_DISABLED 0x02 }; +struct mfi_disk_pending { + TAILQ_ENTRY(mfi_disk_pending) ld_link; + int ld_id; +}; + struct mfi_system_pd { TAILQ_ENTRY(mfi_system_pd) pd_link; device_t pd_dev; @@ -137,6 +143,11 @@ int pd_flags; }; +struct mfi_system_pending { + TAILQ_ENTRY(mfi_system_pending) pd_link; + int pd_id; +}; + struct mfi_evt_queue_elm { TAILQ_ENTRY(mfi_evt_queue_elm) link; struct mfi_evt_detail detail; @@ -285,6 +296,8 @@ TAILQ_HEAD(,mfi_disk) mfi_ld_tqh; TAILQ_HEAD(,mfi_system_pd) mfi_syspd_tqh; + TAILQ_HEAD(,mfi_disk_pending) mfi_ld_pend_tqh; + TAILQ_HEAD(,mfi_system_pending) mfi_syspd_pend_tqh; eventhandler_tag mfi_eh; struct cdev *mfi_cdev; @@ -421,7 +434,8 @@ extern void mfi_tbolt_sync_map_info(struct mfi_softc *sc); extern void mfi_handle_map_sync(void *context, int pending); extern int mfi_dcmd_command(struct mfi_softc *, struct mfi_command **, - uint32_t, void **, size_t); + uint32_t, void **, size_t); +extern int mfi_build_cdb(int, uint8_t, u_int64_t, u_int32_t, uint8_t *); #define MFIQ_ADD(sc, qname) \ do { \ Index: mfi.c =================================================================== --- mfi.c (revision 242617) +++ mfi.c (working copy) @@ -106,11 +106,9 @@ static struct mfi_command * mfi_bio_command(struct mfi_softc *); static void mfi_bio_complete(struct mfi_command *); static struct mfi_command *mfi_build_ldio(struct mfi_softc *,struct bio*); -static int mfi_build_syspd_cdb(struct mfi_pass_frame *pass, uint32_t block_count, - uint64_t lba, uint8_t byte2, int readop); static struct mfi_command *mfi_build_syspdio(struct mfi_softc *,struct bio*); static int mfi_send_frame(struct mfi_softc *, struct mfi_command *); -static int mfi_abort(struct mfi_softc *, struct mfi_command *); +static int mfi_abort(struct mfi_softc *, struct mfi_command **); static int mfi_linux_ioctl_int(struct cdev *, u_long, caddr_t, int, struct thread *); static void mfi_timeout(void *); static int mfi_user_command(struct mfi_softc *, @@ -376,6 +374,8 @@ sx_init(&sc->mfi_config_lock, "MFI config"); TAILQ_INIT(&sc->mfi_ld_tqh); TAILQ_INIT(&sc->mfi_syspd_tqh); + TAILQ_INIT(&sc->mfi_ld_pend_tqh); + TAILQ_INIT(&sc->mfi_syspd_pend_tqh); TAILQ_INIT(&sc->mfi_evt_queue); TASK_INIT(&sc->mfi_evt_task, 0, mfi_handle_evt, sc); TASK_INIT(&sc->mfi_map_sync_task, 0, mfi_handle_map_sync, sc); @@ -1281,6 +1281,17 @@ struct mfi_command *cm; int error; + + if (sc->mfi_aen_cm) + sc->cm_aen_abort = 1; + if (sc->mfi_aen_cm != NULL) + mfi_abort(sc, &sc->mfi_aen_cm); + + if (sc->mfi_map_sync_cm) + sc->cm_map_abort = 1; + if (sc->mfi_map_sync_cm != NULL) + mfi_abort(sc, &sc->mfi_map_sync_cm); + mtx_lock(&sc->mfi_io_lock); error = mfi_dcmd_command(sc, &cm, MFI_DCMD_CTRL_SHUTDOWN, NULL, 0); if (error) { @@ -1288,12 +1299,6 @@ return (error); } - if (sc->mfi_aen_cm != NULL) - mfi_abort(sc, sc->mfi_aen_cm); - - if (sc->mfi_map_sync_cm != NULL) - mfi_abort(sc, sc->mfi_map_sync_cm); - dcmd = &cm->cm_frame->dcmd; dcmd->header.flags = MFI_FRAME_DIR_NONE; cm->cm_flags = MFI_CMD_POLLED; @@ -1315,6 +1320,7 @@ struct mfi_command *cm = NULL; struct mfi_pd_list *pdlist = NULL; struct mfi_system_pd *syspd, *tmp; + struct mfi_system_pending *syspd_pend; int error, i, found; sx_assert(&sc->mfi_config_lock, SA_XLOCKED); @@ -1355,6 +1361,10 @@ if (syspd->pd_id == pdlist->addr[i].device_id) found = 1; } + TAILQ_FOREACH(syspd_pend, &sc->mfi_syspd_pend_tqh, pd_link) { + if (syspd_pend->pd_id == pdlist->addr[i].device_id) + found = 1; + } if (found == 0) mfi_add_sys_pd(sc, pdlist->addr[i].device_id); } @@ -1390,6 +1400,7 @@ struct mfi_command *cm = NULL; struct mfi_ld_list *list = NULL; struct mfi_disk *ld; + struct mfi_disk_pending *ld_pend; int error, i; sx_assert(&sc->mfi_config_lock, SA_XLOCKED); @@ -1418,6 +1429,10 @@ if (ld->ld_id == list->ld_list[i].ld.v.target_id) goto skip_add; } + TAILQ_FOREACH(ld_pend, &sc->mfi_ld_pend_tqh, ld_link) { + if (ld_pend->ld_id == list->ld_list[i].ld.v.target_id) + goto skip_add; + } mfi_add_ld(sc, list->ld_list[i].ld.v.target_id); skip_add:; } @@ -1620,9 +1635,7 @@ < current_aen.members.evt_class) current_aen.members.evt_class = prior_aen.members.evt_class; - mtx_lock(&sc->mfi_io_lock); - mfi_abort(sc, sc->mfi_aen_cm); - mtx_unlock(&sc->mfi_io_lock); + mfi_abort(sc, &sc->mfi_aen_cm); } } @@ -1814,10 +1827,17 @@ struct mfi_command *cm; struct mfi_dcmd_frame *dcmd = NULL; struct mfi_ld_info *ld_info = NULL; + struct mfi_disk_pending *ld_pend; int error; mtx_assert(&sc->mfi_io_lock, MA_OWNED); + ld_pend = malloc(sizeof(*ld_pend), M_MFIBUF, M_NOWAIT | M_ZERO); + if (ld_pend != NULL) { + ld_pend->ld_id = id; + TAILQ_INSERT_TAIL(&sc->mfi_ld_pend_tqh, ld_pend, ld_link); + } + error = mfi_dcmd_command(sc, &cm, MFI_DCMD_LD_GET_INFO, (void **)&ld_info, sizeof(*ld_info)); if (error) { @@ -1858,11 +1878,13 @@ hdr = &cm->cm_frame->header; ld_info = cm->cm_private; - if (hdr->cmd_status != MFI_STAT_OK) { + if (sc->cm_map_abort || hdr->cmd_status != MFI_STAT_OK) { free(ld_info, M_MFIBUF); + wakeup(&sc->mfi_map_sync_cm); mfi_release_command(cm); return; } + wakeup(&sc->mfi_map_sync_cm); mfi_release_command(cm); mtx_unlock(&sc->mfi_io_lock); @@ -1887,10 +1909,17 @@ struct mfi_command *cm; struct mfi_dcmd_frame *dcmd = NULL; struct mfi_pd_info *pd_info = NULL; + struct mfi_system_pending *syspd_pend; int error; mtx_assert(&sc->mfi_io_lock, MA_OWNED); + syspd_pend = malloc(sizeof(*syspd_pend), M_MFIBUF, M_NOWAIT | M_ZERO); + if (syspd_pend != NULL) { + syspd_pend->pd_id = id; + TAILQ_INSERT_TAIL(&sc->mfi_syspd_pend_tqh, syspd_pend, pd_link); + } + error = mfi_dcmd_command(sc, &cm, MFI_DCMD_PD_GET_INFO, (void **)&pd_info, sizeof(*pd_info)); if (error) { @@ -1985,9 +2014,12 @@ return cm; } -static int -mfi_build_syspd_cdb(struct mfi_pass_frame *pass, uint32_t block_count, - uint64_t lba, uint8_t byte2, int readop) +/* + * mostly copied from cam/scsi/scsi_all.c:scsi_read_write + */ + +int +mfi_build_cdb(int readop, uint8_t byte2, u_int64_t lba, u_int32_t block_count, uint8_t *cdb) { int cdb_len; @@ -1997,7 +2029,7 @@ /* We can fit in a 6 byte cdb */ struct scsi_rw_6 *scsi_cmd; - scsi_cmd = (struct scsi_rw_6 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_6 *)cdb; scsi_cmd->opcode = readop ? READ_6 : WRITE_6; scsi_ulto3b(lba, scsi_cmd->addr); scsi_cmd->length = block_count & 0xff; @@ -2007,7 +2039,7 @@ /* Need a 10 byte CDB */ struct scsi_rw_10 *scsi_cmd; - scsi_cmd = (struct scsi_rw_10 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_10 *)cdb; scsi_cmd->opcode = readop ? READ_10 : WRITE_10; scsi_cmd->byte2 = byte2; scsi_ulto4b(lba, scsi_cmd->addr); @@ -2020,7 +2052,7 @@ /* Block count is too big for 10 byte CDB use a 12 byte CDB */ struct scsi_rw_12 *scsi_cmd; - scsi_cmd = (struct scsi_rw_12 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_12 *)cdb; scsi_cmd->opcode = readop ? READ_12 : WRITE_12; scsi_cmd->byte2 = byte2; scsi_ulto4b(lba, scsi_cmd->addr); @@ -2035,7 +2067,7 @@ */ struct scsi_rw_16 *scsi_cmd; - scsi_cmd = (struct scsi_rw_16 *)&pass->cdb; + scsi_cmd = (struct scsi_rw_16 *)cdb; scsi_cmd->opcode = readop ? READ_16 : WRITE_16; scsi_cmd->byte2 = byte2; scsi_u64to8b(lba, scsi_cmd->addr); @@ -2053,15 +2085,15 @@ { struct mfi_command *cm; struct mfi_pass_frame *pass; - int flags = 0; + uint32_t context = 0; + int flags = 0, blkcount = 0, readop; uint8_t cdb_len; - uint32_t block_count, context = 0; if ((cm = mfi_dequeue_free(sc)) == NULL) return (NULL); /* Zero out the MFI frame */ - context = cm->cm_frame->header.context; + context = cm->cm_frame->header.context; bzero(cm->cm_frame, sizeof(union mfi_frame)); cm->cm_frame->header.context = context; pass = &cm->cm_frame->pass; @@ -2070,22 +2102,24 @@ switch (bio->bio_cmd & 0x03) { case BIO_READ: flags = MFI_CMD_DATAIN; + readop = 1; break; case BIO_WRITE: flags = MFI_CMD_DATAOUT; + readop = 0; break; default: /* TODO: what about BIO_DELETE??? */ - panic("Unsupported bio command"); + panic("Unsupported bio command %x\n", bio->bio_cmd); } /* Cheat with the sector length to avoid a non-constant division */ - block_count = (bio->bio_bcount + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; + blkcount = (bio->bio_bcount + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; /* Fill the LBA and Transfer length in CDB */ - cdb_len = mfi_build_syspd_cdb(pass, block_count, bio->bio_pblkno, 0, - flags == MFI_CMD_DATAIN); - + cdb_len = mfi_build_cdb(readop, 0, bio->bio_pblkno, blkcount, + pass->cdb); pass->header.target_id = (uintptr_t)bio->bio_driver1; + pass->header.lun_id = 0; pass->header.timeout = 0; pass->header.flags = 0; pass->header.scsi_status = 0; @@ -2132,7 +2166,7 @@ break; default: /* TODO: what about BIO_DELETE??? */ - panic("Unsupported bio command"); + panic("Unsupported bio command %x\n", bio->bio_cmd); } /* Cheat with the sector length to avoid a non-constant division */ @@ -2422,15 +2456,14 @@ } static int -mfi_abort(struct mfi_softc *sc, struct mfi_command *cm_abort) +mfi_abort(struct mfi_softc *sc, struct mfi_command **cm_abort) { struct mfi_command *cm; struct mfi_abort_frame *abort; int i = 0; uint32_t context = 0; - mtx_assert(&sc->mfi_io_lock, MA_OWNED); - + mtx_lock(&sc->mfi_io_lock); if ((cm = mfi_dequeue_free(sc)) == NULL) { return (EBUSY); } @@ -2444,29 +2477,27 @@ abort->header.cmd = MFI_CMD_ABORT; abort->header.flags = 0; abort->header.scsi_status = 0; - abort->abort_context = cm_abort->cm_frame->header.context; - abort->abort_mfi_addr_lo = (uint32_t)cm_abort->cm_frame_busaddr; + abort->abort_context = (*cm_abort)->cm_frame->header.context; + abort->abort_mfi_addr_lo = (uint32_t)(*cm_abort)->cm_frame_busaddr; abort->abort_mfi_addr_hi = - (uint32_t)((uint64_t)cm_abort->cm_frame_busaddr >> 32); + (uint32_t)((uint64_t)(*cm_abort)->cm_frame_busaddr >> 32); cm->cm_data = NULL; cm->cm_flags = MFI_CMD_POLLED; - if (sc->mfi_aen_cm) - sc->cm_aen_abort = 1; - if (sc->mfi_map_sync_cm) - sc->cm_map_abort = 1; mfi_mapcmd(sc, cm); mfi_release_command(cm); - while (i < 5 && sc->mfi_aen_cm != NULL) { - msleep(&sc->mfi_aen_cm, &sc->mfi_io_lock, 0, "mfiabort", + mtx_unlock(&sc->mfi_io_lock); + while (i < 5 && *cm_abort != NULL) { + tsleep(cm_abort, 0, "mfiabort", 5 * hz); i++; } - while (i < 5 && sc->mfi_map_sync_cm != NULL) { - msleep(&sc->mfi_map_sync_cm, &sc->mfi_io_lock, 0, "mfiabort", - 5 * hz); - i++; + if (*cm_abort != NULL) { + /* Force a complete if command didn't abort */ + mtx_lock(&sc->mfi_io_lock); + (*cm_abort)->cm_complete(*cm_abort); + mtx_unlock(&sc->mfi_io_lock); } return (0); @@ -2522,7 +2553,7 @@ { struct mfi_command *cm; struct mfi_pass_frame *pass; - int error; + int error, readop, cdb_len; uint32_t blkcount; if ((cm = mfi_dequeue_free(sc)) == NULL) @@ -2531,21 +2562,24 @@ pass = &cm->cm_frame->pass; bzero(pass->cdb, 16); pass->header.cmd = MFI_CMD_PD_SCSI_IO; + + readop = 0; blkcount = (len + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; + cdb_len = mfi_build_cdb(readop, 0, lba, blkcount, pass->cdb); pass->header.target_id = id; pass->header.timeout = 0; pass->header.flags = 0; pass->header.scsi_status = 0; pass->header.sense_len = MFI_SENSE_LEN; pass->header.data_len = len; - pass->header.cdb_len = mfi_build_syspd_cdb(pass, blkcount, lba, 0, 0); + pass->header.cdb_len = cdb_len; pass->sense_addr_lo = (uint32_t)cm->cm_sense_busaddr; pass->sense_addr_hi = (uint32_t)((uint64_t)cm->cm_sense_busaddr >> 32); cm->cm_data = virt; cm->cm_len = len; cm->cm_sg = &pass->sgl; cm->cm_total_frame_size = MFI_PASS_FRAME_SIZE; - cm->cm_flags = MFI_CMD_POLLED | MFI_CMD_DATAOUT; + cm->cm_flags = MFI_CMD_POLLED | MFI_CMD_DATAOUT | MFI_CMD_SCSI; error = mfi_mapcmd(sc, cm); bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap, @@ -2745,16 +2779,24 @@ } } -static int mfi_check_for_sscd(struct mfi_softc *sc, struct mfi_command *cm) +static int +mfi_check_for_sscd(struct mfi_softc *sc, struct mfi_command *cm) { - struct mfi_config_data *conf_data=(struct mfi_config_data *)cm->cm_data; + struct mfi_config_data *conf_data; struct mfi_command *ld_cm = NULL; struct mfi_ld_info *ld_info = NULL; + struct mfi_ld_config *ld; + char *p; int error = 0; - if ((cm->cm_frame->dcmd.opcode == MFI_DCMD_CFG_ADD) && - (conf_data->ld[0].params.isSSCD == 1)) { - error = 1; + conf_data = (struct mfi_config_data *)cm->cm_data; + + if (cm->cm_frame->dcmd.opcode == MFI_DCMD_CFG_ADD) { + p = (char *)conf_data->array; + p += conf_data->array_size * conf_data->array_count; + ld = (struct mfi_ld_config *)p; + if (ld->params.isSSCD == 1) + error = 1; } else if (cm->cm_frame->dcmd.opcode == MFI_DCMD_LD_DELETE) { error = mfi_dcmd_command (sc, &ld_cm, MFI_DCMD_LD_GET_INFO, (void **)&ld_info, sizeof(*ld_info)); Index: mfi_cam.c =================================================================== --- mfi_cam.c (revision 242617) +++ mfi_cam.c (working copy) @@ -79,6 +79,11 @@ static struct mfi_command * mfip_start(void *); static void mfip_done(struct mfi_command *cm); +static int mfi_allow_disks = 0; +TUNABLE_INT("hw.mfi.allow_cam_disk_passthrough", &mfi_allow_disks); +SYSCTL_INT(_hw_mfi, OID_AUTO, allow_cam_disk_passthrough, CTLFLAG_RD, + &mfi_allow_disks, 0, "event message locale"); + static devclass_t mfip_devclass; static device_method_t mfip_methods[] = { DEVMETHOD(device_probe, mfip_probe), @@ -349,7 +354,8 @@ command = csio->cdb_io.cdb_bytes[0]; if (command == INQUIRY) { device = csio->data_ptr[0] & 0x1f; - if ((device == T_DIRECT) || (device == T_PROCESSOR)) + if ((!mfi_allow_disks && device == T_DIRECT) || + (device == T_PROCESSOR)) csio->data_ptr[0] = (csio->data_ptr[0] & 0xe0) | T_NODEVICE; } Index: mfi_syspd.c =================================================================== --- mfi_syspd.c (revision 242617) +++ mfi_syspd.c (working copy) @@ -89,7 +89,6 @@ static int mfi_syspd_probe(device_t dev) { - return (0); } @@ -98,12 +97,12 @@ { struct mfi_system_pd *sc; struct mfi_pd_info *pd_info; + struct mfi_system_pending *syspd_pend; uint64_t sectors; uint32_t secsize; sc = device_get_softc(dev); pd_info = device_get_ivars(dev); - sc->pd_dev = dev; sc->pd_id = pd_info->ref.v.device_id; sc->pd_unit = device_get_unit(dev); @@ -115,6 +114,13 @@ secsize = MFI_SECTOR_LEN; mtx_lock(&sc->pd_controller->mfi_io_lock); TAILQ_INSERT_TAIL(&sc->pd_controller->mfi_syspd_tqh, sc, pd_link); + TAILQ_FOREACH(syspd_pend, &sc->pd_controller->mfi_syspd_pend_tqh, + pd_link) { + TAILQ_REMOVE(&sc->pd_controller->mfi_syspd_pend_tqh, + syspd_pend, pd_link); + free(syspd_pend, M_MFIBUF); + break; + } mtx_unlock(&sc->pd_controller->mfi_io_lock); device_printf(dev, "%juMB (%ju sectors) SYSPD volume\n", sectors / (1024 * 1024 / secsize), sectors); @@ -139,6 +145,7 @@ disk_create(sc->pd_disk, DISK_VERSION); device_printf(dev, " SYSPD volume attached\n"); + return (0); } --kXdP64Ggrk/fb43R-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 00:09:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46AF19B8; Tue, 6 Nov 2012 00:09:49 +0000 (UTC) (envelope-from prvs=1657173cfa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D86F48FC15; Tue, 6 Nov 2012 00:09:47 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000965135.msg; Tue, 06 Nov 2012 00:09:46 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 06 Nov 2012 00:09:46 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1657173cfa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <27169C7FE704495087A093752D15E7B6@multiplay.co.uk> From: "Steven Hartland" To: "Doug Ambrisko" References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> <20121105212911.GA17904@ambrisko.com> Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Date: Tue, 6 Nov 2012 00:09:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:09:49 -0000 Thanks Doug, actually just finished another test run with some more debugging in and I believe I've found the reason for the non-recusive lock and at least some of the queuing issues. The non-recursive lock is due to the mfi_tbolt_reset calling mfi_process_fw_state_chg_isr with mfi_io_lock held which in turn calls mfi_tbolt_init_MFI_queue which tries to acquire mfi_io_lock hence the problem. mfi-lock.txt attached I believe fixes this as well as what appears to be an invalid call to mtx_unlock(&sc->mfi_io_lock) in mfi_attach which never acquires the lock as far as can see, possibly a cut and paste error. The invalid queue problems seem to stem from the error cases of the calls to mfi_mapcmd, some of which call mfi_release_command which blindly sets cm_flags = 0 and then enqueues it on the free queue. Now depending on the flow of mfi_mapcmd and where the error occurs the command may or may not have been put on the busy queue which is going to cause problems. Going to investigate this further but that's what my current theory is. Your patch seems quite extensive, so if could you give me brief run down on the changes that would be most appreciated. FYI, I'm aware that the cause of my underlying issues are some hardware issues (likely cable or backplane related) but it does mean I'm in the position to test these usually rare error cases, so wanting the make the most of it before we get the hardware swapped out. Regards Steve ----- Original Message ----- From: "Doug Ambrisko" To: "Steven Hartland" Cc: ; Sent: Monday, November 05, 2012 9:29 PM Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock > On Mon, Nov 05, 2012 at 04:55:11PM -0000, Steven Hartland wrote: > | I've managed to get the machine to reproduce this fairly regularly > | now. > | > | Without a debug kernel it still results in a panic, just at a later > | stage or so I believe, the none debug panic messages is "command not > | in queue". > | > | In each none debug panic I've seen the cm_flags indicates the > | command being dequeued is on the busy queue and not on the expected > | free or ready queue which is being processed at the time. > | > | The triggering issue seems to be the adapter reset code run from > | mfi_timeout. > | > | I've had a good look but can't see how a cm could be in a queue yet > | have its cm_flags set to that of a different queue as all manipulation > | seems to be being done via the "mfi_ ## name" macros which > | all correctly maintain the queue / cm_flags relationship. > | > | At this point I believe it could be a thread being interrupted by > | a timeout part way the processing of a queue request hence queue > | and cm_flags being out of sync. > | > | Any pointers on how to debug this issue further / fix it would be most > | appreciated. > | > | Regards > | Steve > | > | ----- Original Message ----- > | From: "Steven Hartland" > | >Testing a new machine which is based on 8.3-RELEASE with the mfi > | >driver from 8-STABLE and just got a panic. > | > > | > > | >The below is translation of the hand copied from console:- > | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > | >mfisyspd5: hard error cmd=write 90827650-90827905 > | >mfi0: I/O error, status= 46 scsi_status= 240 > | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > | >mfisyspd5: hard error cmd=write 90827394-90827649 > | >mfi0: I/O error, status= 46 scsi_status= 240 > | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > | >mfisyspd5: hard error cmd=write 90827138-90827393 > | >mfi0: I/O error, status= 46 scsi_status= 240 > | >mfi0: sense error 0, sense_key 0, asc 0, ascq 0 > | >mfisyspd5: hard error cmd=write 90826882-90827137 > | >mfi0: I/O error, status= 2 scsi_status= 2 > | >mfi0: sense error 112, sense_key 6, asc 41, ascq 0 > | >mfisyspd4: hard error cmd=write 90830466-90830721 > | >mfi0: I/O error, status= 2 scsi_status= 2 > | >mfi0: sense error 112, sense_key 6, asc 41, ascq 0 > | >mfisyspd5: hard error cmd=write 90830722-90830977 > | >mfi0: Adapter RESET condition detected > | >mfi0: First state FW reset initiated... > | >mfi0: ADP_RESET_TBOLT: HostDiag=a0 > | >mfi0: first state of reset complete, second state initiated... > | >mfi0: Second state FW reset initiated... > | >panic: _mtx_lock_sleep: recursed on non-recusive mutex MFI I/O lock @ > | >/usr/src/sys/dev/mfi/mfi_tbolt:346 > | > > | >cpuid = 6 > | >KDB: stack backtrace: > | >db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > | >kdb_backtrace() at kdb_backtrace+0x37 > | >panic() at panic+0x178 > | >_mtx_lock_sleep() at _mtx_lock_sleep+0x152 > | >_mtx_lock_flags() at _mtx_lock_flags+0x80 > | >mfi_tbolt_init_MFI_queue() at mfi_tbolt_init_MFI_queue+0x72 > | >mfi_timeout() at mfi_timeout+0x27 > | >softclock() at softclock+0x2aa > | >intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > | >ithread_loop() at ithread_loop+0xb2 > | >fork_exit() at fork_exit+0x135 > | >fork_trampoline() at fork_trampoline+0xe > | >--- trap 0, rip = 0, rsp = 0xffffff80005ccd00, rbp = 0 --- > | >KDB: enter panic > | >[thread pid 12 tid 100020 ] > | >Stopperd at kdb_enter+0x3b: movq $0,0x51cb32(%rip) > | >db> > | > > | >So questions:- > | >1. What are the "hard error" errors? The machine was testing IO > | >with dd but due to the panic I cant tell if that was the cause. > | >2. Looking at the code this seems like the reset was tripped by > | >firmware bug, is that the case? > | >3. Is the fix the panic a simple one we cat test? > > As soon as I get caught up on email, I'll be checking in some updates > that fix a bunch of issues. I don't know if it will fix this but > it could help. At any case it would get us to a common base line to > look at debugging this. The patch is attached and follows. It is > relative to -head. It should be easy to head and this to stable. > > Index: mfi_tbolt.c > =================================================================== > --- mfi_tbolt.c (revision 242617) > +++ mfi_tbolt.c (working copy) > @@ -69,13 +69,10 @@ > mfi_build_mpt_pass_thru(struct mfi_softc *sc, struct mfi_command *mfi_cmd); > union mfi_mpi2_request_descriptor *mfi_build_and_issue_cmd(struct mfi_softc > *sc, struct mfi_command *mfi_cmd); > -int mfi_tbolt_is_ldio(struct mfi_command *mfi_cmd); > void mfi_tbolt_build_ldio(struct mfi_softc *sc, struct mfi_command *mfi_cmd, > struct mfi_cmd_tbolt *cmd); > static int mfi_tbolt_make_sgl(struct mfi_softc *sc, struct mfi_command > *mfi_cmd, pMpi25IeeeSgeChain64_t sgl_ptr, struct mfi_cmd_tbolt *cmd); > -static int mfi_tbolt_build_cdb(struct mfi_softc *sc, struct mfi_command > - *mfi_cmd, uint8_t *cdb); > void > map_tbolt_cmd_status(struct mfi_command *mfi_cmd, uint8_t status, > uint8_t ext_status); > @@ -502,6 +499,7 @@ > + i * MEGASAS_MAX_SZ_CHAIN_FRAME); > cmd->sg_frame_phys_addr = sc->sg_frame_busaddr + i > * MEGASAS_MAX_SZ_CHAIN_FRAME; > + cmd->sync_cmd_idx = sc->mfi_max_fw_cmds; > > TAILQ_INSERT_TAIL(&(sc->mfi_cmd_tbolt_tqh), cmd, next); > } > @@ -608,6 +606,8 @@ > } > } > > +int outstanding = 0; > + > /* > * mfi_tbolt_return_cmd - Return a cmd to free command pool > * @instance: Adapter soft state > @@ -618,7 +618,9 @@ > { > mtx_assert(&sc->mfi_io_lock, MA_OWNED); > > + cmd->sync_cmd_idx = sc->mfi_max_fw_cmds; > TAILQ_INSERT_TAIL(&sc->mfi_cmd_tbolt_tqh, cmd, next); > + outstanding--; > } > > void > @@ -667,16 +669,27 @@ > extStatus = cmd_mfi->cm_frame->dcmd.header.scsi_status; > map_tbolt_cmd_status(cmd_mfi, status, extStatus); > > - /* remove command from busy queue if not polled */ > - TAILQ_FOREACH(cmd_mfi_check, &sc->mfi_busy, cm_link) { > - if (cmd_mfi_check == cmd_mfi) { > - mfi_remove_busy(cmd_mfi); > - break; > + if (cmd_mfi->cm_flags & MFI_CMD_SCSI && > + (cmd_mfi->cm_flags & MFI_CMD_POLLED) != 0) { > + /* polled LD/SYSPD IO command */ > + cmd_mfi->cm_error = 0; > + cmd_mfi->cm_frame->header.cmd_status = 0; > + mfi_tbolt_return_cmd(sc, cmd_tbolt); > + } else { > + > + /* remove command from busy queue if not polled */ > + TAILQ_FOREACH(cmd_mfi_check, &sc->mfi_busy, cm_link) { > + if (cmd_mfi_check == cmd_mfi) { > + mfi_remove_busy(cmd_mfi); > + break; > + } > } > + > + /* complete the command */ > + cmd_mfi->cm_error = 0; > + mfi_complete(sc, cmd_mfi); > + mfi_tbolt_return_cmd(sc, cmd_tbolt); > } > - cmd_mfi->cm_error = 0; > - mfi_complete(sc, cmd_mfi); > - mfi_tbolt_return_cmd(sc, cmd_tbolt); > > sc->last_reply_idx++; > if (sc->last_reply_idx >= sc->mfi_max_fw_cmds) { > @@ -746,6 +759,7 @@ > p = sc->request_desc_pool + sizeof(union mfi_mpi2_request_descriptor) > * index; > memset(p, 0, sizeof(union mfi_mpi2_request_descriptor)); > + outstanding++; > return (union mfi_mpi2_request_descriptor *)p; > } > > @@ -811,13 +825,13 @@ > MFI_FRAME_DIR_READ) > io_info.isRead = 1; > > - io_request->RaidContext.timeoutValue > - = MFI_FUSION_FP_DEFAULT_TIMEOUT; > - io_request->Function = MPI2_FUNCTION_LD_IO_REQUEST; > - io_request->DevHandle = device_id; > - cmd->request_desc->header.RequestFlags > - = (MFI_REQ_DESCRIPT_FLAGS_LD_IO > - << MFI_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); > + io_request->RaidContext.timeoutValue > + = MFI_FUSION_FP_DEFAULT_TIMEOUT; > + io_request->Function = MPI2_FUNCTION_LD_IO_REQUEST; > + io_request->DevHandle = device_id; > + cmd->request_desc->header.RequestFlags > + = (MFI_REQ_DESCRIPT_FLAGS_LD_IO > + << MFI_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); > if ((io_request->IoFlags == 6) && (io_info.numBlocks == 0)) > io_request->RaidContext.RegLockLength = 0x100; > io_request->DataLength = mfi_cmd->cm_frame->io.header.data_len > @@ -825,41 +839,37 @@ > } > > int > -mfi_tbolt_is_ldio(struct mfi_command *mfi_cmd) > -{ > - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_READ > - || mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) > - return 1; > - else > - return 0; > -} > - > -int > mfi_tbolt_build_io(struct mfi_softc *sc, struct mfi_command *mfi_cmd, > struct mfi_cmd_tbolt *cmd) > { > - uint32_t device_id; > + struct mfi_mpi2_request_raid_scsi_io *io_request; > uint32_t sge_count; > - uint8_t cdb[32], cdb_len; > + uint8_t cdb_len; > + int readop; > + u_int64_t lba; > > - memset(cdb, 0, 32); > - struct mfi_mpi2_request_raid_scsi_io *io_request = cmd->io_request; > - > - device_id = mfi_cmd->cm_frame->header.target_id; > - > - /* Have to build CDB here for TB as BSD don't have a scsi layer */ > - if ((cdb_len = mfi_tbolt_build_cdb(sc, mfi_cmd, cdb)) == 1) > + io_request = cmd->io_request; > + if (!(mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_READ > + || mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE)) > return 1; > > - /* Just the CDB length,rest of the Flags are zero */ > - io_request->IoFlags = cdb_len; > - memcpy(io_request->CDB.CDB32, cdb, 32); > + mfi_tbolt_build_ldio(sc, mfi_cmd, cmd); > > - if (mfi_tbolt_is_ldio(mfi_cmd)) > - mfi_tbolt_build_ldio(sc, mfi_cmd , cmd); > + /* Convert to SCSI command CDB */ > + bzero(io_request->CDB.CDB32, sizeof(io_request->CDB.CDB32)); > + if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) > + readop = 0; > else > - return 1; > + readop = 1; > > + lba = mfi_cmd->cm_frame->io.lba_hi; > + lba = (lba << 32) + mfi_cmd->cm_frame->io.lba_lo; > + cdb_len = mfi_build_cdb(readop, 0, lba, > + mfi_cmd->cm_frame->io.header.data_len, io_request->CDB.CDB32); > + > + /* Just the CDB length, rest of the Flags are zero */ > + io_request->IoFlags = cdb_len; > + > /* > * Construct SGL > */ > @@ -883,85 +893,13 @@ > > io_request->SenseBufferLowAddress = mfi_cmd->cm_sense_busaddr; > io_request->SenseBufferLength = MFI_SENSE_LEN; > + io_request->RaidContext.Status = MFI_STAT_INVALID_STATUS; > + io_request->RaidContext.exStatus = MFI_STAT_INVALID_STATUS; > + > return 0; > } > > -static int > -mfi_tbolt_build_cdb(struct mfi_softc *sc, struct mfi_command *mfi_cmd, > - uint8_t *cdb) > -{ > - uint32_t lba_lo, lba_hi, num_lba; > - uint8_t cdb_len; > > - if (mfi_cmd == NULL || cdb == NULL) > - return 1; > - num_lba = mfi_cmd->cm_frame->io.header.data_len; > - lba_lo = mfi_cmd->cm_frame->io.lba_lo; > - lba_hi = mfi_cmd->cm_frame->io.lba_hi; > - > - if (lba_hi == 0 && (num_lba <= 0xFF) && (lba_lo <= 0x1FFFFF)) { > - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) > - /* Read 6 or Write 6 */ > - cdb[0] = (uint8_t) (0x0A); > - else > - cdb[0] = (uint8_t) (0x08); > - > - cdb[4] = (uint8_t) num_lba; > - cdb[3] = (uint8_t) (lba_lo & 0xFF); > - cdb[2] = (uint8_t) (lba_lo >> 8); > - cdb[1] = (uint8_t) ((lba_lo >> 16) & 0x1F); > - cdb_len = 6; > - } > - else if (lba_hi == 0 && (num_lba <= 0xFFFF) && (lba_lo <= 0xFFFFFFFF)) { > - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) > - /* Read 10 or Write 10 */ > - cdb[0] = (uint8_t) (0x2A); > - else > - cdb[0] = (uint8_t) (0x28); > - cdb[8] = (uint8_t) (num_lba & 0xFF); > - cdb[7] = (uint8_t) (num_lba >> 8); > - cdb[5] = (uint8_t) (lba_lo & 0xFF); > - cdb[4] = (uint8_t) (lba_lo >> 8); > - cdb[3] = (uint8_t) (lba_lo >> 16); > - cdb[2] = (uint8_t) (lba_lo >> 24); > - cdb_len = 10; > - } else if ((num_lba > 0xFFFF) && (lba_hi == 0)) { > - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) > - /* Read 12 or Write 12 */ > - cdb[0] = (uint8_t) (0xAA); > - else > - cdb[0] = (uint8_t) (0xA8); > - cdb[9] = (uint8_t) (num_lba & 0xFF); > - cdb[8] = (uint8_t) (num_lba >> 8); > - cdb[7] = (uint8_t) (num_lba >> 16); > - cdb[6] = (uint8_t) (num_lba >> 24); > - cdb[5] = (uint8_t) (lba_lo & 0xFF); > - cdb[4] = (uint8_t) (lba_lo >> 8); > - cdb[3] = (uint8_t) (lba_lo >> 16); > - cdb[2] = (uint8_t) (lba_lo >> 24); > - cdb_len = 12; > - } else { > - if (mfi_cmd->cm_frame->header.cmd == MFI_CMD_LD_WRITE) > - cdb[0] = (uint8_t) (0x8A); > - else > - cdb[0] = (uint8_t) (0x88); > - cdb[13] = (uint8_t) (num_lba & 0xFF); > - cdb[12] = (uint8_t) (num_lba >> 8); > - cdb[11] = (uint8_t) (num_lba >> 16); > - cdb[10] = (uint8_t) (num_lba >> 24); > - cdb[9] = (uint8_t) (lba_lo & 0xFF); > - cdb[8] = (uint8_t) (lba_lo >> 8); > - cdb[7] = (uint8_t) (lba_lo >> 16); > - cdb[6] = (uint8_t) (lba_lo >> 24); > - cdb[5] = (uint8_t) (lba_hi & 0xFF); > - cdb[4] = (uint8_t) (lba_hi >> 8); > - cdb[3] = (uint8_t) (lba_hi >> 16); > - cdb[2] = (uint8_t) (lba_hi >> 24); > - cdb_len = 16; > - } > - return cdb_len; > -} > - > static int > mfi_tbolt_make_sgl(struct mfi_softc *sc, struct mfi_command *mfi_cmd, > pMpi25IeeeSgeChain64_t sgl_ptr, struct mfi_cmd_tbolt *cmd) > @@ -1100,8 +1038,7 @@ > if ((cm->cm_flags & MFI_CMD_POLLED) == 0) { > cm->cm_timestamp = time_uptime; > mfi_enqueue_busy(cm); > - } > - else { /* still get interrupts for it */ > + } else { /* still get interrupts for it */ > hdr->cmd_status = MFI_STAT_INVALID_STATUS; > hdr->flags |= MFI_FRAME_DONT_POST_IN_REPLY_QUEUE; > } > @@ -1118,31 +1055,49 @@ > } > else > device_printf(sc->mfi_dev, "DJA NA XXX SYSPDIO\n"); > - } > - else if (hdr->cmd == MFI_CMD_LD_SCSI_IO || > + } else if (hdr->cmd == MFI_CMD_LD_SCSI_IO || > hdr->cmd == MFI_CMD_LD_READ || hdr->cmd == MFI_CMD_LD_WRITE) { > + cm->cm_flags |= MFI_CMD_SCSI; > if ((req_desc = mfi_build_and_issue_cmd(sc, cm)) == NULL) { > device_printf(sc->mfi_dev, "LDIO Failed \n"); > return 1; > } > - } else > - if ((req_desc = mfi_tbolt_build_mpt_cmd(sc, cm)) == NULL) { > + } else if ((req_desc = mfi_tbolt_build_mpt_cmd(sc, cm)) == NULL) { > device_printf(sc->mfi_dev, "Mapping from MFI to MPT " > "Failed\n"); > return 1; > - } > + } > + > + if (cm->cm_flags & MFI_CMD_SCSI) { > + /* > + * LD IO needs to be posted since it doesn't get > + * acknowledged via a status update so have the > + * controller reply via mfi_tbolt_complete_cmd. > + */ > + hdr->flags &= ~MFI_FRAME_DONT_POST_IN_REPLY_QUEUE; > + } > + > MFI_WRITE4(sc, MFI_ILQP, (req_desc->words & 0xFFFFFFFF)); > MFI_WRITE4(sc, MFI_IHQP, (req_desc->words >>0x20)); > > if ((cm->cm_flags & MFI_CMD_POLLED) == 0) > return 0; > > + if (cm->cm_flags & MFI_CMD_SCSI) { > + /* check reply queue */ > + mfi_tbolt_complete_cmd(sc); > + } > + > /* This is a polled command, so busy-wait for it to complete. */ > while (hdr->cmd_status == MFI_STAT_INVALID_STATUS) { > DELAY(1000); > tm -= 1; > if (tm <= 0) > - break; > + break; > + if (cm->cm_flags & MFI_CMD_SCSI) { > + /* check reply queue */ > + mfi_tbolt_complete_cmd(sc); > + } > } > > if (hdr->cmd_status == MFI_STAT_INVALID_STATUS) { > @@ -1375,7 +1330,7 @@ > free(ld_sync, M_MFIBUF); > goto out; > } > - > + > context = cmd->cm_frame->header.context; > bzero(cmd->cm_frame, sizeof(union mfi_frame)); > cmd->cm_frame->header.context = context; > Index: mfi_disk.c > =================================================================== > --- mfi_disk.c (revision 242617) > +++ mfi_disk.c (working copy) > @@ -93,6 +93,7 @@ > { > struct mfi_disk *sc; > struct mfi_ld_info *ld_info; > + struct mfi_disk_pending *ld_pend; > uint64_t sectors; > uint32_t secsize; > char *state; > @@ -111,6 +112,13 @@ > secsize = MFI_SECTOR_LEN; > mtx_lock(&sc->ld_controller->mfi_io_lock); > TAILQ_INSERT_TAIL(&sc->ld_controller->mfi_ld_tqh, sc, ld_link); > + TAILQ_FOREACH(ld_pend, &sc->ld_controller->mfi_ld_pend_tqh, > + ld_link) { > + TAILQ_REMOVE(&sc->ld_controller->mfi_ld_pend_tqh, > + ld_pend, ld_link); > + free(ld_pend, M_MFIBUF); > + break; > + } > mtx_unlock(&sc->ld_controller->mfi_io_lock); > > switch (ld_info->ld_config.params.state) { > @@ -131,16 +139,16 @@ > break; > } > > - if ( strlen(ld_info->ld_config.properties.name) == 0 ) { > - device_printf(dev, > - "%juMB (%ju sectors) RAID volume (no label) is %s\n", > - sectors / (1024 * 1024 / secsize), sectors, state); > - } else { > - device_printf(dev, > - "%juMB (%ju sectors) RAID volume '%s' is %s\n", > - sectors / (1024 * 1024 / secsize), sectors, > - ld_info->ld_config.properties.name, state); > - } > + if ( strlen(ld_info->ld_config.properties.name) == 0 ) { > + device_printf(dev, > + "%juMB (%ju sectors) RAID volume (no label) is %s\n", > + sectors / (1024 * 1024 / secsize), sectors, state); > + } else { > + device_printf(dev, > + "%juMB (%ju sectors) RAID volume '%s' is %s\n", > + sectors / (1024 * 1024 / secsize), sectors, > + ld_info->ld_config.properties.name, state); > + } > > sc->ld_disk = disk_alloc(); > sc->ld_disk->d_drv1 = sc; > Index: mfivar.h > =================================================================== > --- mfivar.h (revision 242617) > +++ mfivar.h (working copy) > @@ -106,6 +106,7 @@ > #define MFI_ON_MFIQ_READY (1<<6) > #define MFI_ON_MFIQ_BUSY (1<<7) > #define MFI_ON_MFIQ_MASK ((1<<5)|(1<<6)|(1<<7)) > +#define MFI_CMD_SCSI (1<<8) > uint8_t retry_for_fw_reset; > void (* cm_complete)(struct mfi_command *cm); > void *cm_private; > @@ -126,6 +127,11 @@ > #define MFI_DISK_FLAGS_DISABLED 0x02 > }; > > +struct mfi_disk_pending { > + TAILQ_ENTRY(mfi_disk_pending) ld_link; > + int ld_id; > +}; > + > struct mfi_system_pd { > TAILQ_ENTRY(mfi_system_pd) pd_link; > device_t pd_dev; > @@ -137,6 +143,11 @@ > int pd_flags; > }; > > +struct mfi_system_pending { > + TAILQ_ENTRY(mfi_system_pending) pd_link; > + int pd_id; > +}; > + > struct mfi_evt_queue_elm { > TAILQ_ENTRY(mfi_evt_queue_elm) link; > struct mfi_evt_detail detail; > @@ -285,6 +296,8 @@ > > TAILQ_HEAD(,mfi_disk) mfi_ld_tqh; > TAILQ_HEAD(,mfi_system_pd) mfi_syspd_tqh; > + TAILQ_HEAD(,mfi_disk_pending) mfi_ld_pend_tqh; > + TAILQ_HEAD(,mfi_system_pending) mfi_syspd_pend_tqh; > eventhandler_tag mfi_eh; > struct cdev *mfi_cdev; > > @@ -421,7 +434,8 @@ > extern void mfi_tbolt_sync_map_info(struct mfi_softc *sc); > extern void mfi_handle_map_sync(void *context, int pending); > extern int mfi_dcmd_command(struct mfi_softc *, struct mfi_command **, > - uint32_t, void **, size_t); > + uint32_t, void **, size_t); > +extern int mfi_build_cdb(int, uint8_t, u_int64_t, u_int32_t, uint8_t *); > > #define MFIQ_ADD(sc, qname) \ > do { \ > Index: mfi.c > =================================================================== > --- mfi.c (revision 242617) > +++ mfi.c (working copy) > @@ -106,11 +106,9 @@ > static struct mfi_command * mfi_bio_command(struct mfi_softc *); > static void mfi_bio_complete(struct mfi_command *); > static struct mfi_command *mfi_build_ldio(struct mfi_softc *,struct bio*); > -static int mfi_build_syspd_cdb(struct mfi_pass_frame *pass, uint32_t block_count, > - uint64_t lba, uint8_t byte2, int readop); > static struct mfi_command *mfi_build_syspdio(struct mfi_softc *,struct bio*); > static int mfi_send_frame(struct mfi_softc *, struct mfi_command *); > -static int mfi_abort(struct mfi_softc *, struct mfi_command *); > +static int mfi_abort(struct mfi_softc *, struct mfi_command **); > static int mfi_linux_ioctl_int(struct cdev *, u_long, caddr_t, int, struct thread *); > static void mfi_timeout(void *); > static int mfi_user_command(struct mfi_softc *, > @@ -376,6 +374,8 @@ > sx_init(&sc->mfi_config_lock, "MFI config"); > TAILQ_INIT(&sc->mfi_ld_tqh); > TAILQ_INIT(&sc->mfi_syspd_tqh); > + TAILQ_INIT(&sc->mfi_ld_pend_tqh); > + TAILQ_INIT(&sc->mfi_syspd_pend_tqh); > TAILQ_INIT(&sc->mfi_evt_queue); > TASK_INIT(&sc->mfi_evt_task, 0, mfi_handle_evt, sc); > TASK_INIT(&sc->mfi_map_sync_task, 0, mfi_handle_map_sync, sc); > @@ -1281,6 +1281,17 @@ > struct mfi_command *cm; > int error; > > + > + if (sc->mfi_aen_cm) > + sc->cm_aen_abort = 1; > + if (sc->mfi_aen_cm != NULL) > + mfi_abort(sc, &sc->mfi_aen_cm); > + > + if (sc->mfi_map_sync_cm) > + sc->cm_map_abort = 1; > + if (sc->mfi_map_sync_cm != NULL) > + mfi_abort(sc, &sc->mfi_map_sync_cm); > + > mtx_lock(&sc->mfi_io_lock); > error = mfi_dcmd_command(sc, &cm, MFI_DCMD_CTRL_SHUTDOWN, NULL, 0); > if (error) { > @@ -1288,12 +1299,6 @@ > return (error); > } > > - if (sc->mfi_aen_cm != NULL) > - mfi_abort(sc, sc->mfi_aen_cm); > - > - if (sc->mfi_map_sync_cm != NULL) > - mfi_abort(sc, sc->mfi_map_sync_cm); > - > dcmd = &cm->cm_frame->dcmd; > dcmd->header.flags = MFI_FRAME_DIR_NONE; > cm->cm_flags = MFI_CMD_POLLED; > @@ -1315,6 +1320,7 @@ > struct mfi_command *cm = NULL; > struct mfi_pd_list *pdlist = NULL; > struct mfi_system_pd *syspd, *tmp; > + struct mfi_system_pending *syspd_pend; > int error, i, found; > > sx_assert(&sc->mfi_config_lock, SA_XLOCKED); > @@ -1355,6 +1361,10 @@ > if (syspd->pd_id == pdlist->addr[i].device_id) > found = 1; > } > + TAILQ_FOREACH(syspd_pend, &sc->mfi_syspd_pend_tqh, pd_link) { > + if (syspd_pend->pd_id == pdlist->addr[i].device_id) > + found = 1; > + } > if (found == 0) > mfi_add_sys_pd(sc, pdlist->addr[i].device_id); > } > @@ -1390,6 +1400,7 @@ > struct mfi_command *cm = NULL; > struct mfi_ld_list *list = NULL; > struct mfi_disk *ld; > + struct mfi_disk_pending *ld_pend; > int error, i; > > sx_assert(&sc->mfi_config_lock, SA_XLOCKED); > @@ -1418,6 +1429,10 @@ > if (ld->ld_id == list->ld_list[i].ld.v.target_id) > goto skip_add; > } > + TAILQ_FOREACH(ld_pend, &sc->mfi_ld_pend_tqh, ld_link) { > + if (ld_pend->ld_id == list->ld_list[i].ld.v.target_id) > + goto skip_add; > + } > mfi_add_ld(sc, list->ld_list[i].ld.v.target_id); > skip_add:; > } > @@ -1620,9 +1635,7 @@ > < current_aen.members.evt_class) > current_aen.members.evt_class = > prior_aen.members.evt_class; > - mtx_lock(&sc->mfi_io_lock); > - mfi_abort(sc, sc->mfi_aen_cm); > - mtx_unlock(&sc->mfi_io_lock); > + mfi_abort(sc, &sc->mfi_aen_cm); > } > } > > @@ -1814,10 +1827,17 @@ > struct mfi_command *cm; > struct mfi_dcmd_frame *dcmd = NULL; > struct mfi_ld_info *ld_info = NULL; > + struct mfi_disk_pending *ld_pend; > int error; > > mtx_assert(&sc->mfi_io_lock, MA_OWNED); > > + ld_pend = malloc(sizeof(*ld_pend), M_MFIBUF, M_NOWAIT | M_ZERO); > + if (ld_pend != NULL) { > + ld_pend->ld_id = id; > + TAILQ_INSERT_TAIL(&sc->mfi_ld_pend_tqh, ld_pend, ld_link); > + } > + > error = mfi_dcmd_command(sc, &cm, MFI_DCMD_LD_GET_INFO, > (void **)&ld_info, sizeof(*ld_info)); > if (error) { > @@ -1858,11 +1878,13 @@ > hdr = &cm->cm_frame->header; > ld_info = cm->cm_private; > > - if (hdr->cmd_status != MFI_STAT_OK) { > + if (sc->cm_map_abort || hdr->cmd_status != MFI_STAT_OK) { > free(ld_info, M_MFIBUF); > + wakeup(&sc->mfi_map_sync_cm); > mfi_release_command(cm); > return; > } > + wakeup(&sc->mfi_map_sync_cm); > mfi_release_command(cm); > > mtx_unlock(&sc->mfi_io_lock); > @@ -1887,10 +1909,17 @@ > struct mfi_command *cm; > struct mfi_dcmd_frame *dcmd = NULL; > struct mfi_pd_info *pd_info = NULL; > + struct mfi_system_pending *syspd_pend; > int error; > > mtx_assert(&sc->mfi_io_lock, MA_OWNED); > > + syspd_pend = malloc(sizeof(*syspd_pend), M_MFIBUF, M_NOWAIT | M_ZERO); > + if (syspd_pend != NULL) { > + syspd_pend->pd_id = id; > + TAILQ_INSERT_TAIL(&sc->mfi_syspd_pend_tqh, syspd_pend, pd_link); > + } > + > error = mfi_dcmd_command(sc, &cm, MFI_DCMD_PD_GET_INFO, > (void **)&pd_info, sizeof(*pd_info)); > if (error) { > @@ -1985,9 +2014,12 @@ > return cm; > } > > -static int > -mfi_build_syspd_cdb(struct mfi_pass_frame *pass, uint32_t block_count, > - uint64_t lba, uint8_t byte2, int readop) > +/* > + * mostly copied from cam/scsi/scsi_all.c:scsi_read_write > + */ > + > +int > +mfi_build_cdb(int readop, uint8_t byte2, u_int64_t lba, u_int32_t block_count, uint8_t *cdb) > { > int cdb_len; > > @@ -1997,7 +2029,7 @@ > /* We can fit in a 6 byte cdb */ > struct scsi_rw_6 *scsi_cmd; > > - scsi_cmd = (struct scsi_rw_6 *)&pass->cdb; > + scsi_cmd = (struct scsi_rw_6 *)cdb; > scsi_cmd->opcode = readop ? READ_6 : WRITE_6; > scsi_ulto3b(lba, scsi_cmd->addr); > scsi_cmd->length = block_count & 0xff; > @@ -2007,7 +2039,7 @@ > /* Need a 10 byte CDB */ > struct scsi_rw_10 *scsi_cmd; > > - scsi_cmd = (struct scsi_rw_10 *)&pass->cdb; > + scsi_cmd = (struct scsi_rw_10 *)cdb; > scsi_cmd->opcode = readop ? READ_10 : WRITE_10; > scsi_cmd->byte2 = byte2; > scsi_ulto4b(lba, scsi_cmd->addr); > @@ -2020,7 +2052,7 @@ > /* Block count is too big for 10 byte CDB use a 12 byte CDB */ > struct scsi_rw_12 *scsi_cmd; > > - scsi_cmd = (struct scsi_rw_12 *)&pass->cdb; > + scsi_cmd = (struct scsi_rw_12 *)cdb; > scsi_cmd->opcode = readop ? READ_12 : WRITE_12; > scsi_cmd->byte2 = byte2; > scsi_ulto4b(lba, scsi_cmd->addr); > @@ -2035,7 +2067,7 @@ > */ > struct scsi_rw_16 *scsi_cmd; > > - scsi_cmd = (struct scsi_rw_16 *)&pass->cdb; > + scsi_cmd = (struct scsi_rw_16 *)cdb; > scsi_cmd->opcode = readop ? READ_16 : WRITE_16; > scsi_cmd->byte2 = byte2; > scsi_u64to8b(lba, scsi_cmd->addr); > @@ -2053,15 +2085,15 @@ > { > struct mfi_command *cm; > struct mfi_pass_frame *pass; > - int flags = 0; > + uint32_t context = 0; > + int flags = 0, blkcount = 0, readop; > uint8_t cdb_len; > - uint32_t block_count, context = 0; > > if ((cm = mfi_dequeue_free(sc)) == NULL) > return (NULL); > > /* Zero out the MFI frame */ > - context = cm->cm_frame->header.context; > + context = cm->cm_frame->header.context; > bzero(cm->cm_frame, sizeof(union mfi_frame)); > cm->cm_frame->header.context = context; > pass = &cm->cm_frame->pass; > @@ -2070,22 +2102,24 @@ > switch (bio->bio_cmd & 0x03) { > case BIO_READ: > flags = MFI_CMD_DATAIN; > + readop = 1; > break; > case BIO_WRITE: > flags = MFI_CMD_DATAOUT; > + readop = 0; > break; > default: > /* TODO: what about BIO_DELETE??? */ > - panic("Unsupported bio command"); > + panic("Unsupported bio command %x\n", bio->bio_cmd); > } > > /* Cheat with the sector length to avoid a non-constant division */ > - block_count = (bio->bio_bcount + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; > + blkcount = (bio->bio_bcount + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; > /* Fill the LBA and Transfer length in CDB */ > - cdb_len = mfi_build_syspd_cdb(pass, block_count, bio->bio_pblkno, 0, > - flags == MFI_CMD_DATAIN); > - > + cdb_len = mfi_build_cdb(readop, 0, bio->bio_pblkno, blkcount, > + pass->cdb); > pass->header.target_id = (uintptr_t)bio->bio_driver1; > + pass->header.lun_id = 0; > pass->header.timeout = 0; > pass->header.flags = 0; > pass->header.scsi_status = 0; > @@ -2132,7 +2166,7 @@ > break; > default: > /* TODO: what about BIO_DELETE??? */ > - panic("Unsupported bio command"); > + panic("Unsupported bio command %x\n", bio->bio_cmd); > } > > /* Cheat with the sector length to avoid a non-constant division */ > @@ -2422,15 +2456,14 @@ > } > > static int > -mfi_abort(struct mfi_softc *sc, struct mfi_command *cm_abort) > +mfi_abort(struct mfi_softc *sc, struct mfi_command **cm_abort) > { > struct mfi_command *cm; > struct mfi_abort_frame *abort; > int i = 0; > uint32_t context = 0; > > - mtx_assert(&sc->mfi_io_lock, MA_OWNED); > - > + mtx_lock(&sc->mfi_io_lock); > if ((cm = mfi_dequeue_free(sc)) == NULL) { > return (EBUSY); > } > @@ -2444,29 +2477,27 @@ > abort->header.cmd = MFI_CMD_ABORT; > abort->header.flags = 0; > abort->header.scsi_status = 0; > - abort->abort_context = cm_abort->cm_frame->header.context; > - abort->abort_mfi_addr_lo = (uint32_t)cm_abort->cm_frame_busaddr; > + abort->abort_context = (*cm_abort)->cm_frame->header.context; > + abort->abort_mfi_addr_lo = (uint32_t)(*cm_abort)->cm_frame_busaddr; > abort->abort_mfi_addr_hi = > - (uint32_t)((uint64_t)cm_abort->cm_frame_busaddr >> 32); > + (uint32_t)((uint64_t)(*cm_abort)->cm_frame_busaddr >> 32); > cm->cm_data = NULL; > cm->cm_flags = MFI_CMD_POLLED; > > - if (sc->mfi_aen_cm) > - sc->cm_aen_abort = 1; > - if (sc->mfi_map_sync_cm) > - sc->cm_map_abort = 1; > mfi_mapcmd(sc, cm); > mfi_release_command(cm); > > - while (i < 5 && sc->mfi_aen_cm != NULL) { > - msleep(&sc->mfi_aen_cm, &sc->mfi_io_lock, 0, "mfiabort", > + mtx_unlock(&sc->mfi_io_lock); > + while (i < 5 && *cm_abort != NULL) { > + tsleep(cm_abort, 0, "mfiabort", > 5 * hz); > i++; > } > - while (i < 5 && sc->mfi_map_sync_cm != NULL) { > - msleep(&sc->mfi_map_sync_cm, &sc->mfi_io_lock, 0, "mfiabort", > - 5 * hz); > - i++; > + if (*cm_abort != NULL) { > + /* Force a complete if command didn't abort */ > + mtx_lock(&sc->mfi_io_lock); > + (*cm_abort)->cm_complete(*cm_abort); > + mtx_unlock(&sc->mfi_io_lock); > } > > return (0); > @@ -2522,7 +2553,7 @@ > { > struct mfi_command *cm; > struct mfi_pass_frame *pass; > - int error; > + int error, readop, cdb_len; > uint32_t blkcount; > > if ((cm = mfi_dequeue_free(sc)) == NULL) > @@ -2531,21 +2562,24 @@ > pass = &cm->cm_frame->pass; > bzero(pass->cdb, 16); > pass->header.cmd = MFI_CMD_PD_SCSI_IO; > + > + readop = 0; > blkcount = (len + MFI_SECTOR_LEN - 1) / MFI_SECTOR_LEN; > + cdb_len = mfi_build_cdb(readop, 0, lba, blkcount, pass->cdb); > pass->header.target_id = id; > pass->header.timeout = 0; > pass->header.flags = 0; > pass->header.scsi_status = 0; > pass->header.sense_len = MFI_SENSE_LEN; > pass->header.data_len = len; > - pass->header.cdb_len = mfi_build_syspd_cdb(pass, blkcount, lba, 0, 0); > + pass->header.cdb_len = cdb_len; > pass->sense_addr_lo = (uint32_t)cm->cm_sense_busaddr; > pass->sense_addr_hi = (uint32_t)((uint64_t)cm->cm_sense_busaddr >> 32); > cm->cm_data = virt; > cm->cm_len = len; > cm->cm_sg = &pass->sgl; > cm->cm_total_frame_size = MFI_PASS_FRAME_SIZE; > - cm->cm_flags = MFI_CMD_POLLED | MFI_CMD_DATAOUT; > + cm->cm_flags = MFI_CMD_POLLED | MFI_CMD_DATAOUT | MFI_CMD_SCSI; > > error = mfi_mapcmd(sc, cm); > bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap, > @@ -2745,16 +2779,24 @@ > } > } > > -static int mfi_check_for_sscd(struct mfi_softc *sc, struct mfi_command *cm) > +static int > +mfi_check_for_sscd(struct mfi_softc *sc, struct mfi_command *cm) > { > - struct mfi_config_data *conf_data=(struct mfi_config_data *)cm->cm_data; > + struct mfi_config_data *conf_data; > struct mfi_command *ld_cm = NULL; > struct mfi_ld_info *ld_info = NULL; > + struct mfi_ld_config *ld; > + char *p; > int error = 0; > > - if ((cm->cm_frame->dcmd.opcode == MFI_DCMD_CFG_ADD) && > - (conf_data->ld[0].params.isSSCD == 1)) { > - error = 1; > + conf_data = (struct mfi_config_data *)cm->cm_data; > + > + if (cm->cm_frame->dcmd.opcode == MFI_DCMD_CFG_ADD) { > + p = (char *)conf_data->array; > + p += conf_data->array_size * conf_data->array_count; > + ld = (struct mfi_ld_config *)p; > + if (ld->params.isSSCD == 1) > + error = 1; > } else if (cm->cm_frame->dcmd.opcode == MFI_DCMD_LD_DELETE) { > error = mfi_dcmd_command (sc, &ld_cm, MFI_DCMD_LD_GET_INFO, > (void **)&ld_info, sizeof(*ld_info)); > Index: mfi_cam.c > =================================================================== > --- mfi_cam.c (revision 242617) > +++ mfi_cam.c (working copy) > @@ -79,6 +79,11 @@ > static struct mfi_command * mfip_start(void *); > static void mfip_done(struct mfi_command *cm); > > +static int mfi_allow_disks = 0; > +TUNABLE_INT("hw.mfi.allow_cam_disk_passthrough", &mfi_allow_disks); > +SYSCTL_INT(_hw_mfi, OID_AUTO, allow_cam_disk_passthrough, CTLFLAG_RD, > + &mfi_allow_disks, 0, "event message locale"); > + > static devclass_t mfip_devclass; > static device_method_t mfip_methods[] = { > DEVMETHOD(device_probe, mfip_probe), > @@ -349,7 +354,8 @@ > command = csio->cdb_io.cdb_bytes[0]; > if (command == INQUIRY) { > device = csio->data_ptr[0] & 0x1f; > - if ((device == T_DIRECT) || (device == T_PROCESSOR)) > + if ((!mfi_allow_disks && device == T_DIRECT) || > + (device == T_PROCESSOR)) > csio->data_ptr[0] = > (csio->data_ptr[0] & 0xe0) | T_NODEVICE; > } > Index: mfi_syspd.c > =================================================================== > --- mfi_syspd.c (revision 242617) > +++ mfi_syspd.c (working copy) > @@ -89,7 +89,6 @@ > static int > mfi_syspd_probe(device_t dev) > { > - > return (0); > } > > @@ -98,12 +97,12 @@ > { > struct mfi_system_pd *sc; > struct mfi_pd_info *pd_info; > + struct mfi_system_pending *syspd_pend; > uint64_t sectors; > uint32_t secsize; > > sc = device_get_softc(dev); > pd_info = device_get_ivars(dev); > - > sc->pd_dev = dev; > sc->pd_id = pd_info->ref.v.device_id; > sc->pd_unit = device_get_unit(dev); > @@ -115,6 +114,13 @@ > secsize = MFI_SECTOR_LEN; > mtx_lock(&sc->pd_controller->mfi_io_lock); > TAILQ_INSERT_TAIL(&sc->pd_controller->mfi_syspd_tqh, sc, pd_link); > + TAILQ_FOREACH(syspd_pend, &sc->pd_controller->mfi_syspd_pend_tqh, > + pd_link) { > + TAILQ_REMOVE(&sc->pd_controller->mfi_syspd_pend_tqh, > + syspd_pend, pd_link); > + free(syspd_pend, M_MFIBUF); > + break; > + } > mtx_unlock(&sc->pd_controller->mfi_io_lock); > device_printf(dev, "%juMB (%ju sectors) SYSPD volume\n", > sectors / (1024 * 1024 / secsize), sectors); > @@ -139,6 +145,7 @@ > disk_create(sc->pd_disk, DISK_VERSION); > > device_printf(dev, " SYSPD volume attached\n"); > + > return (0); > } > > > Thanks, > > Doug A. > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 08:21:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 051A237E for ; Tue, 6 Nov 2012 08:21:25 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 59EC48FC12 for ; Tue, 6 Nov 2012 08:21:23 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id qA68LKAq032659; Tue, 6 Nov 2012 15:21:20 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5098C87A.9000302@rdtc.ru> Date: Tue, 06 Nov 2012 15:21:14 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bas Smeelen Subject: Re: freebsd-update and sources of 9.1-RC3 References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> <50961FF1.9010605@ose.nl> <509649B3.70700@ose.nl> In-Reply-To: <509649B3.70700@ose.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 08:21:25 -0000 04.11.2012 17:55, Bas Smeelen wrote: > To get the sources you can always use csup and set > default release=cvs tag=RELENG_9_1 > or use subversion csup will gone in 3 or 4 month, not a long-term solution I need. subversion still misses lightweight binary package like cvsup-nox11 was some time ago. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 08:28:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A14D2752 for ; Tue, 6 Nov 2012 08:28:20 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE6F8FC0A for ; Tue, 6 Nov 2012 08:28:19 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Tue, 6 Nov 2012 09:28:11 +0100 Message-ID: <5098C9E5.6040101@ose.nl> Date: Tue, 06 Nov 2012 09:27:17 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eugene Grosbein Subject: Re: freebsd-update and sources of 9.1-RC3 References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> <50961FF1.9010605@ose.nl> <509649B3.70700@ose.nl> <5098C87A.9000302@rdtc.ru> In-Reply-To: <5098C87A.9000302@rdtc.ru> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 08:28:20 -0000 On 11/06/2012 09=3A21 AM=2C Eugene Grosbein wrote=3A =3E 04=2E11=2E2012 17=3A55=2C Bas Smeelen wrote=3A =3E =3E=3E To get the sources you can always use csup and set =3E=3E default release=3Dcvs tag=3DRELENG=5F9=5F1 =3E=3E or use subversion =3E csup will gone in 3 or 4 month=2C not a long-term solution I need=2E You=27re right=2E For now you can still use it to get the source and then keep it updated wit= h=20 freebsd-update =3E subversion still misses lightweight binary package like cvsup-nox11 was= some time ago=2E Me too=2E With subversion you get about 14 extra dependencies and it is not= =20 really lightweight like csup=2E csup will be available for the STABLE branches in the future but for how lo= ng=3F This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 08:50:50 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79809AEF; Tue, 6 Nov 2012 08:50:50 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by mx1.freebsd.org (Postfix) with ESMTP id BB85A8FC08; Tue, 6 Nov 2012 08:50:48 +0000 (UTC) Received: from mail118-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 6 Nov 2012 08:50:47 +0000 Received: from mail118-am1 (localhost [127.0.0.1]) by mail118-am1-R.bigfish.com (Postfix) with ESMTP id 89D6F460257; Tue, 6 Nov 2012 08:50:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:212.214.215.133; KIP:(null); UIP:(null); IPV:NLI; H:semtaout01.proact.se; RD:semtaout01.proact.se; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zzbb2dI542M1432Izz1de0h1d18h1202h1d1ah1d2ahzz8275bh8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail118-am1 (localhost.localdomain [127.0.0.1]) by mail118-am1 (MessageSwitch) id 1352191844493342_22348; Tue, 6 Nov 2012 08:50:44 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.246]) by mail118-am1.bigfish.com (Postfix) with ESMTP id 5793D4A005F; Tue, 6 Nov 2012 08:50:44 +0000 (UTC) Received: from semtaout01.proact.se (212.214.215.133) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server id 14.1.225.23; Tue, 6 Nov 2012 08:50:40 +0000 Received: from Semail04.proact.local (unknown [10.7.1.58]) by semtaout01.proact.se (Postfix) with ESMTP id 4E87A5727C; Tue, 6 Nov 2012 09:50:40 +0100 (CET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 09:50:39 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqAAF8a9gAAYYgXwAAYhBQAAk9ux8P///B6A//+/I1CAAHlQgP//5ozAgABIH4D//unQQA== Date: Tue, 6 Nov 2012 08:50:39 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> In-Reply-To: <5097F24D.7040206@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" , "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 08:50:50 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 5. november 2012 18:08 > To: Tom Lislegaard > Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 05/11/2012 16:52 Tom Lislegaard said the following: > > > > > >> -----Original Message----- > >> From: Andriy Gapon [mailto:avg@FreeBSD.org] > >> Sent: 5. november 2012 15:21 > >> To: Tom Lislegaard > >> Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find > >> resource > >> > >> on 05/11/2012 15:54 Tom Lislegaard said the following: > >>> Here's the distribution from running devd over 40 minutes > >>> > >>> 589 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU0 notify=3D0x81' > >>> 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU1 notify=3D0x81' > >>> 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU2 notify=3D0x81' > >>> 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU3 notify=3D0x81' > >>> 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU4 notify=3D0x81' > >>> 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU5 notify=3D0x81' > >>> 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU6 notify=3D0x81' > >>> 590 Processing event '!system=3DACPI subsystem=3DPROCESSOR type=3D\= \_PR_.CPU7 notify=3D0x81' > >>> 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREAT= E cdev=3Ddsp4.1' > >>> 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREAT= E cdev=3Dpts/2' > >>> 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DCREAT= E cdev=3Dvboxdrv0' > >>> 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTR= OY cdev=3Ddsp4.1' > >>> 1 Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTR= OY cdev=3Dvboxdrv0' > >>> > >>> Any use in running it over a longer period of time? > >> > >> Very interesting. > >> So the processors get _CST change notifications rather frequently, > >> but there is no obvious source/cause for them... > >> > >> Could you please send to me acpidump -dt output or upload it somewhere= and post a link? > > > > Here you go > > > > https://dl.dropbox.com/u/13263820/acpidump.txt >=20 > So, ACPI platform on your machine sends 0x81 notification for processors = objects each time "_PSR" > method of AC Adapter / Power Source device is queried. > There could be a number of reason to invoke the method - either AC line s= tatus queries from userland > (some battery / line monitoring program/applet) or internal ACPI notifica= tions. >=20 > Are you willing to go as far as recompiling your kernel with 'options AC= PI_DEBUG' > to get to the bottom of this issue? > If yes, then please do that and also add the following lines to loader.co= nf: > debug.acpi.layer=3D"ACPI_EVENTS ACPI_AC_ADAPTER" > debug.acpi.level=3D"ACPI_LV_INFO" > I would be interested in all periodically occurring ACPI debug messages (= after boot is finished). >=20 No problem, I'm happy to assist in debugging this. Enabling the acpi debugging quickly fills the kernel message buffer, but it= seems to be the same set of messages=20 repeating again and again so I think this is representative https://dl.dropbox.com/u/13263820/debug_dmesg.txt And, btw, thanks for your efforts. -tom > I suspect that the ACPI platform and/or embedded controller send too many= notifications when they are > not strictly necessary. > Maybe there is a BIOS update for your machine? >=20 > In any case, I am starting to work on a patch that should fix this proble= m without resorting to any > special configuration. > -- > Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 10:26:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 061615C7 for ; Tue, 6 Nov 2012 10:26:53 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id A3D4C8FC14 for ; Tue, 6 Nov 2012 10:26:51 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TVgMw-0003jS-Tp for freebsd-stable@freebsd.org; Tue, 06 Nov 2012 11:26:59 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Nov 2012 11:26:54 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Nov 2012 11:26:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: freebsd-update and sources of 9.1-RC3 Date: Tue, 6 Nov 2012 10:26:35 +0000 (UTC) Lines: 59 Message-ID: References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> <50961FF1.9010605@ose.nl> <509649B3.70700@ose.nl> <50965035.8030508@ose.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:26:53 -0000 Bas Smeelen ose.nl> writes: > ... > >> Since freebsd-update is meant to update the system I don't really see a > >> point to make it install sources (or others things) if they are not > >> present on the system being updated. > ... > > But, you brought up that "StrictComponents yes" option and we have to figure > > out what it means ... > > From looking at the freebsd-update script (it's in /usr/sbin) I > understand when StrictComponents is set to yes it skips the step, > inspecting system.... and uses the list provided in freebsd-update.conf, > so this option might save some time and disk activity. But then, after I removed /usr/src dir, it re-created it for itself just to create in there that ../release sub-dir with some documents, which looked useless to me, not to mention the fact that it attempted to install there some 20 or so other docs, but could not and failed with errors (see my test run output in earlier post). So, to me that is already a reason to ask the maintainer to look at it as it is an important utility. > I don't fully understand what the impact might be when running a custom > kernel. When I had src present (by my download) prior to freebsd-update upgrade, without custom kernel, without that "override" option ("StrictComponents no"), I got src updated in various places, in particular the file /usr/src/sys/conf/newvers.sh, which is OK. If you had a custom kernel and src present, then src would get updated as above, and your custom kernel would be gone, but you would be asked to rebuild your kernel manually. So, it would be convinient for you to have src ready, by manual download or "override" option ("StrictComponents yes"). > ... > > # When upgrading between releases, should the list of Components be > > # read strictly (StrictComponents yes) or merely as a list of components > > # which *might* be installed of which FreeBSD Update should figure out > > # which actually are installed and upgrade those (StrictComponents no)? > > # StrictComponents no > > > > The components are: > > Components src world kernel > > > > Then what gives ? Does it not apply to src component ? When I looked at this "override" option, which is per default disabled, which is perfectly OK for most users, I understood it as not only saving some time on verification of current system state, but a real option to request full update of my system for components specified. This would make e.g. src download needed first time, but if that is what I wanted, it would be configurable and make sense for me and other people like the OP who actually expected it. It would make this utility fully functional, not half-baked like it is right now. jb From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 13:46:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 881B4DEA for ; Tue, 6 Nov 2012 13:46:52 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB8A18FC08 for ; Tue, 6 Nov 2012 13:46:51 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so525529lbd.13 for ; Tue, 06 Nov 2012 05:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yUk+4JDz4WwcH4V6mY6UgdU5pZshw3sNZJH0T+n7gYw=; b=bNYJKhgmOaAiwqyf+XtlWFExP6rlApv5oHcNQa4yNdnOUmk9tFpuyxKkjt5YIDhhUQ 6c3z31YVdBjVoMc3wQ4MUOJnwraLHqpaZiv4oQblJrN0fHemnQthvzI14jnAY92jtEwm UgB/uyNj3MBN2B4xJHEUIFL+L/704huvONHmC8zzT9n8EVteu+nsjWl56f3f6QN/jLyf wt3ulEqSqCZUvGYkLbiRiE1ovQMtt4UrQ+PLsqnfNIq3Ask7Kq0bnOs3sjBk8LKLSR0z LuhZ+8/szqFBVyZxHKarIJcd7Hg/RW1Pm+MAqW0dtuHw930hPNHUtykApdXCb3xoC1m6 mOKg== MIME-Version: 1.0 Received: by 10.112.102.132 with SMTP id fo4mr529156lbb.111.1352209610531; Tue, 06 Nov 2012 05:46:50 -0800 (PST) Sender: vrwmiller@gmail.com Received: by 10.112.4.97 with HTTP; Tue, 6 Nov 2012 05:46:50 -0800 (PST) In-Reply-To: References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> Date: Tue, 6 Nov 2012 08:46:50 -0500 X-Google-Sender-Auth: S_JMQ2EVmrSzYGB9w6ZKX0MzgfU Message-ID: Subject: Re: FreeBSD 9.1 stability/robustness? From: Rick Miller To: Rainer Duffner Content-Type: text/plain; charset=ISO-8859-1 Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 13:46:52 -0000 Someone asked about getting The DL360 G8 to boot to their intel branded pci NIC, but I cannot find that email :( At any rate, we removed the Broadcom daughterboard from the system and insured that the intel PCI NIC (i350) was bootable in the BIOS. On Sat, Nov 3, 2012 at 9:56 PM, Rick Miller wrote: > I have a blog post at > http://blog.hostileadmin.com/2012/06/14/freebsd-on-hp-proliant-dl360p-g8-servers/ > which touches on this. I heard as recently as today that the fixes > for the BCM5719 and 5720 were recently committed to -CURRENT. It's > too late for them to be rolled into 9.1. Not sure if they'll be > committed to to stable/8 or not, but if so they could make it into > 8.4-R. -- Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 15:08:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDB9D36A for ; Tue, 6 Nov 2012 15:08:33 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA5B8FC0C for ; Tue, 6 Nov 2012 15:08:33 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so963527iea.13 for ; Tue, 06 Nov 2012 07:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=3uKwZ9UzEAD5m/yvKF5BaF/CUA8DjSgc09abJZ31jhI=; b=uIPcyHA76m7jXpyl5USVGKwDfl1HfVIq5+YQCh2LRRtl9EtNgAyBghd3PpJSyycAw/ 7ze0NBC3QqGXdzxZcQISMf6kbmX76PgujKCE9JJ5YggS2X1ZNzsxxurkKfT1Srw72W5b a7u575zR30/Ji6CkKHFhUUz3grFFVFBSlIdKi4c1JPvWj67r9V7bbEqQ99auGi/LyQox 4h9d+4h/sGwLje4LU0OjkJiIEnryAp0mXsZouG//8jQoo76J/zxt0CfAcu7ngVomobCL JdFZcMkvLyRgLTWzH4kQ1tIQuHjZt2n8pizx2m65b2aYgOmrtUcdOgbEgYHzq6K5mLQ0 xoIQ== Received: by 10.50.140.97 with SMTP id rf1mr13118163igb.70.1352214507595; Tue, 06 Nov 2012 07:08:27 -0800 (PST) Received: from al-mb-mws0001.localnet ([184.239.224.79]) by mx.google.com with ESMTPS id ex10sm8860983igc.15.2012.11.06.07.08.24 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 07:08:26 -0800 (PST) From: Chuck Burns To: freebsd-stable@freebsd.org Subject: Re: freebsd-update and sources of 9.1-RC3 Date: Tue, 06 Nov 2012 09:08:06 -0600 Message-ID: <3070430.ud3WnE2R24@al-mb-mws0001> User-Agent: KMail/4.8.0 (Windows/6.1; KDE/4.8.0; i686; ; ) In-Reply-To: <5098C9E5.6040101@ose.nl> References: <50952210.7060000@grosbein.net> <5098C87A.9000302@rdtc.ru> <5098C9E5.6040101@ose.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 15:08:33 -0000 On Tuesday, November 06, 2012 09:27:17 AM Bas Smeelen wrote: > Me too. With subversion you get about 14 extra dependencies and it is not > really lightweight like csup. > csup will be available for the STABLE branches in the future but for how > long? > I'd wager that it won't be long before someone codes an extremely lightweight anon-only svnup binary that can read from an SVN server, similar to how CVSup and then csup was spawned from CVS. -- Chuck Burns From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 15:18:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E4F770B for ; Tue, 6 Nov 2012 15:18:10 +0000 (UTC) (envelope-from Corti@informatik.uni-stuttgart.de) Received: from mx1.informatik.uni-stuttgart.de (mailgw.informatik.uni-stuttgart.de [129.69.211.41]) by mx1.freebsd.org (Postfix) with ESMTP id 087028FC0C for ; Tue, 6 Nov 2012 15:18:07 +0000 (UTC) Received: from azu.informatik.uni-stuttgart.de (azu.informatik.uni-stuttgart.de [129.69.218.66]) by mx1.informatik.uni-stuttgart.de (Postfix) with ESMTP id C653D69F8 for ; Tue, 6 Nov 2012 16:09:44 +0100 (CET) Received: by azu.informatik.uni-stuttgart.de (Postfix, from userid 19691) id 0DAC14008; Tue, 6 Nov 2012 16:09:36 +0100 (MET) Date: Tue, 6 Nov 2012 16:09:35 +0100 (MET) From: Christian Corti To: freebsd-stable@freebsd.org Subject: Questions about amd automounter Message-ID: User-Agent: Alpine 2.02 (SUN 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 15:18:10 -0000 Hi, I am running FreeBSD 9.0-RELEASE-p4 on an AMD64 box. I am playing with the amd automounter and am looking for a solution of the following problem: I would like to have a /home map similar to autofs that has both local and NIS entries. With autofs (Solaris, Linux etc.) I can say in /etc/auto.home: testuser server:/export/home/testuser +auto_home How can I accomplish somethink similar with amd? Note that I can't put the testuser in the NIS map. Next, while testing different configurations I created a map with SUN syntax (described in the am-utils manual), but apparently the FreeBSD version of amd doesn't support it (there's clearly a lack of documentation and examples of _real-world_ scenarios): Here's the section of amd.conf: [ /xx ] sun_map_syntax = yes map_type = file map_name = /etc/amd.xx But that doesn't work: # /usr/sbin/amd -p -F /etc/amd.conf conf: unknown regular key "sun_map_syntax" for section "/xx" AMDCONF: syntax error on line 30 (section /xx) Am I doing something wrong? This is from the am-utils doc: "To enable Sun-style maps in Amd, set "sun_map_syntax = yes" in your amd.conf file. When this flag is set in [global], all maps read by Amd are assumed to be Sun style maps. You can set this on a per map basis, thus mixing Sun-style and Amd-style maps. For more information about amd.conf please see the Amd documentation." Christian From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 16:39:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FF50DFD for ; Tue, 6 Nov 2012 16:39:44 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp9.sbb.rs (smtp9.sbb.rs [89.216.2.41]) by mx1.freebsd.org (Postfix) with ESMTP id 76FA08FC0A for ; Tue, 6 Nov 2012 16:39:42 +0000 (UTC) Received: from mycenae (cable-178-148-109-45.dynamic.sbb.rs [178.148.109.45]) by smtp9.sbb.rs (8.14.0/8.14.0) with ESMTP id qA6GdTOY027905 for ; Tue, 6 Nov 2012 17:39:34 +0100 Received: by mycenae (Postfix, from userid 1001) id B84F25C2F; Tue, 6 Nov 2012 17:39:23 +0100 (CET) Date: Tue, 6 Nov 2012 17:39:23 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: agp in kernel Message-ID: <20121106163923.GA1152@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -2.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:39:44 -0000 > I am using latest nvidia-driver, and GENERIC 9.1-RC3, which has agp in the > kernel, and have no issues.. After a bit more posts reading , I found that people used one driver even for intel graphics: xf86-video-intel. Is it nece- ssary in case of 9.1 for hd3000? Do I have to change make.conf as a way to run kms? On 8 it was "intel" in xorg.conf. Should I change to "i915kms" now? Zoran From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 18:01:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8550D753; Tue, 6 Nov 2012 18:01:54 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 559B48FC0C; Tue, 6 Nov 2012 18:01:53 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 06 Nov 2012 10:03:11 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id qA6I1rHx042710; Tue, 6 Nov 2012 10:01:53 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id qA6I1qaB042708; Tue, 6 Nov 2012 10:01:52 -0800 (PST) (envelope-from ambrisko) Date: Tue, 6 Nov 2012 10:01:52 -0800 From: Doug Ambrisko To: Steven Hartland Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Message-ID: <20121106180152.GA40422@ambrisko.com> References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> <20121105212911.GA17904@ambrisko.com> <27169C7FE704495087A093752D15E7B6@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27169C7FE704495087A093752D15E7B6@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:01:54 -0000 On Tue, Nov 06, 2012 at 12:09:42AM -0000, Steven Hartland wrote: | Thanks Doug, actually just finished another test run with some more | debugging in and I believe I've found the reason for the non-recusive | lock and at least some of the queuing issues. | | The non-recursive lock is due to the mfi_tbolt_reset calling | mfi_process_fw_state_chg_isr with mfi_io_lock held which in turn calls | mfi_tbolt_init_MFI_queue which tries to acquire mfi_io_lock hence | the problem. | | mfi-lock.txt attached I believe fixes this as well as what appears | to be an invalid call to mtx_unlock(&sc->mfi_io_lock) in mfi_attach | which never acquires the lock as far as can see, possibly a cut and | paste error. I don't seem to see the attachment. | The invalid queue problems seem to stem from the error cases of | the calls to mfi_mapcmd, some of which call mfi_release_command which | blindly sets cm_flags = 0 and then enqueues it on the free queue. Now | depending on the flow of mfi_mapcmd and where the error occurs the | command may or may not have been put on the busy queue which is going | to cause problems. | | Going to investigate this further but that's what my current theory is. | | Your patch seems quite extensive, so if could you give me brief run | down on the changes that would be most appreciated. I'll being doing that in the commit message which should happen today. | FYI, I'm aware that the cause of my underlying issues are some | hardware issues (likely cable or backplane related) but it does mean | I'm in the position to test these usually rare error cases, so wanting | the make the most of it before we get the hardware swapped out. That would be good. It makes it easier to debug things when it shows the problem. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 18:26:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EF7BB5C; Tue, 6 Nov 2012 18:26:19 +0000 (UTC) (envelope-from prvs=1657173cfa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC478FC08; Tue, 6 Nov 2012 18:26:18 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000972147.msg; Tue, 06 Nov 2012 18:26:11 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 06 Nov 2012 18:26:11 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1657173cfa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <6B5B65F4FC854EB8BBC701500096602E@multiplay.co.uk> From: "Steven Hartland" To: "Doug Ambrisko" References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> <20121105212911.GA17904@ambrisko.com> <27169C7FE704495087A093752D15E7B6@multiplay.co.uk> <20121106180152.GA40422@ambrisko.com> Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Date: Tue, 6 Nov 2012 18:26:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:26:19 -0000 ----- Original Message ----- From: "Doug Ambrisko" > On Tue, Nov 06, 2012 at 12:09:42AM -0000, Steven Hartland wrote: > | Thanks Doug, actually just finished another test run with some more > | debugging in and I believe I've found the reason for the non-recusive > | lock and at least some of the queuing issues. > | > | The non-recursive lock is due to the mfi_tbolt_reset calling > | mfi_process_fw_state_chg_isr with mfi_io_lock held which in turn calls > | mfi_tbolt_init_MFI_queue which tries to acquire mfi_io_lock hence > | the problem. > | > | mfi-lock.txt attached I believe fixes this as well as what appears > | to be an invalid call to mtx_unlock(&sc->mfi_io_lock) in mfi_attach > | which never acquires the lock as far as can see, possibly a cut and > | paste error. > > I don't seem to see the attachment. Yer seems like some mail fail by me there, but I've had some more locking panics during todays tests anyway, requiring additional fixes. Will update and post when I'm happy with it. > | The invalid queue problems seem to stem from the error cases of > | the calls to mfi_mapcmd, some of which call mfi_release_command which > | blindly sets cm_flags = 0 and then enqueues it on the free queue. Now > | depending on the flow of mfi_mapcmd and where the error occurs the > | command may or may not have been put on the busy queue which is going > | to cause problems. > | > | Going to investigate this further but that's what my current theory is. I think I've pretty much nailed the queuing issues, there's quite a few it seems caused by inconsitent handling of calls to mfi_mapcmd as suspected. My current outstanding issue is that after adapter reset, commands are left in the queue causing constant timeouts. Hopefully this should be relatively easy to track down and fix too. > | Your patch seems quite extensive, so if could you give me brief run > | down on the changes that would be most appreciated. > > I'll being doing that in the commit message which should happen today. Cool look forward to it :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 18:53:09 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 271EC412; Tue, 6 Nov 2012 18:53:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4FB8FC16; Tue, 6 Nov 2012 18:53:07 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA24459; Tue, 06 Nov 2012 20:53:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50995C8F.3040309@FreeBSD.org> Date: Tue, 06 Nov 2012 20:53:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:53:09 -0000 on 06/11/2012 10:50 Tom Lislegaard said the following: > No problem, I'm happy to assist in debugging this. > > Enabling the acpi debugging quickly fills the kernel message buffer, but it seems to be the same set of messages > repeating again and again so I think this is representative > > https://dl.dropbox.com/u/13263820/debug_dmesg.txt This didn't clarify things as much as I hoped, but I am inclined to think that it is polling from userland that triggers all the processor notifications. In any case, here is a patch to try: http://people.freebsd.org/~avg/acpi_cpu-stable.diff Please disable all the tunings added to loader.conf during debugging when testing this patch. The patch is a combination of two changes: 1. Do not needlessly use ever-increasing resource IDs. Rather use the IDs that are tied to Cx level IDs. Also, release previous resources upon _CST change. 2. Bind a thread that processes a processor _CST change notification to the target processor and perform _CST processing in a critical section. These should ensure the following: - the CPU doesn't enter an idle state and doesn't try to use Cx level parameters while they are being changed - Cx level parameters are never concurrently modified when multiple notifications fire in a rapid succession and multiple ACPI task threads are configured sched_bind is a heavy-weight operation, but it is OK in this context because processor notifications should not occur too often > And, btw, thanks for your efforts. Thank you for all the excellent debugging and testing! P.S. I still believe that BIOS/ACPI on the machine behaves sub-optimally. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 22:53:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0FEA9B5 for ; Tue, 6 Nov 2012 22:53:29 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA3B8FC15 for ; Tue, 6 Nov 2012 22:53:28 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TVs1K-0002uX-Aw for freebsd-stable@freebsd.org; Tue, 06 Nov 2012 14:53:22 -0800 Date: Tue, 6 Nov 2012 14:53:22 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1352242402318-5758722.post@n5.nabble.com> In-Reply-To: <20121106163923.GA1152@mycenae.sbb.rs> References: <20121105150057.GA1151@mycenae.sbb.rs> <20121106163923.GA1152@mycenae.sbb.rs> Subject: Re: agp in kernel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:53:29 -0000 No, it's still intel in xorg.conf, you just need WITH_KMS= WITH_NEW_XORG= set in ports. -- View this message in context: http://freebsd.1045724.n5.nabble.com/agp-in-kernel-tp5758326p5758722.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 23:00:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89B01EC3 for ; Tue, 6 Nov 2012 23:00:05 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 54B7D8FC14 for ; Tue, 6 Nov 2012 23:00:04 +0000 (UTC) Received: from [172.16.10.200] (unknown [172.16.10.200]) by mail.intertainservices.com (Postfix) with ESMTPSA id A649356E84 for ; Tue, 6 Nov 2012 17:59:57 -0500 (EST) Message-ID: <1352242797.4156.3.camel@mjakubik.localdomain> Subject: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang From: Mike Jakubik To: freebsd-stable@freebsd.org Date: Tue, 06 Nov 2012 17:59:57 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: A649356E84.AF59E X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:00:05 -0000 Hello, I've ran in to this issue on two different machines, both have recent stable code. The problem appears to be with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. Thanks. --- ===> gnu/usr.bin/texinfo/install-info (all) clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c gzip -cn /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/doc/install-info.1 > install-info.1.gz /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1179:3: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:54:47: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ ~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1180:3: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:53:34: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ ~~~~~~~~~~~~ 2 warnings generated. clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o install-info install-info.o /usr/obj/usr/src/gnu/usr.bin/texinfo/install-info/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/texindex (all) clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c gzip -cn /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/doc/texindex.1 > texindex.1.gz /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:166:3: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:54:47: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ ~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:167:3: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:53:34: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ ~~~~~~~~~~~~ 2 warnings generated. clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o texindex texindex.o /usr/obj/usr/src/gnu/usr.bin/texinfo/texindex/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi gzip -cn info.info > info.info.gz makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info-stnd.info > info-stnd.info.gz gzip -cn texinfo.info > texinfo.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 23:30:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF1C2265 for ; Tue, 6 Nov 2012 23:30:12 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 89DFC8FC0C for ; Tue, 6 Nov 2012 23:30:12 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so1299087vcb.13 for ; Tue, 06 Nov 2012 15:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HBqHA2aPDmctKJFL3a+yJSxYjQ9c7masUMm6qkWGBJ0=; b=diHwFlggcVGl/mZcNQSYrT74AabvjcZyslFS3IHdELfiX/XoMxPCC9im1c/6I2O5WX YoiZZaW7lLVhBT9xY3KWPTSO4OItDOy9KLyr2JxZXky3/W7WZ1Kz5AXZbmOqDije6GxA wxWRk4OnpSCZUGNdcVeUxw4MJ46m+UYIf7yN4vERsndrJO/ORTkDxpmIVU+Wf1w17RsU ITLhBB+ex9OZz2aq4oeN84nbFcqmpRmZNwNrHzmOLlNDRj5lmuM6B7yZybNt2KqySYBY cy/uWZd8edj005SYWdhX+qaAUV4ScNS8B6NQIw2kE+xkKHhArJCYM1RHob25OlGbJGi1 qjNg== MIME-Version: 1.0 Received: by 10.52.37.43 with SMTP id v11mr2197108vdj.29.1352244611460; Tue, 06 Nov 2012 15:30:11 -0800 (PST) Received: by 10.58.209.163 with HTTP; Tue, 6 Nov 2012 15:30:11 -0800 (PST) In-Reply-To: <20121105150057.GA1151@mycenae.sbb.rs> References: <20121105150057.GA1151@mycenae.sbb.rs> Date: Wed, 7 Nov 2012 01:30:11 +0200 Message-ID: Subject: Re: agp in kernel From: Kimmo Paasiala To: Zoran Kolic Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:30:13 -0000 On Mon, Nov 5, 2012 at 5:00 PM, Zoran Kolic wrote: > After several years I replaced desktop and laptop and > wait for release to start fresh. On desktop I put nvidia > gt520. Forums say nvidia prop driver dislikes agp op- > tion in kernel and recommend removing it. Laptop is > sandy bridge with hd3000 integrated. Would I trigger > something if I delete agp from conf file in both cases? > > Another issue bothers me also. RC version of amdtemp > failed to read temperatures on 8120. What version will > be included in release? Some months ago there was a post > of people taking source from current and compiling mo- > dule. It worked on 8 core bulldozer. > > Best regards all > > Zoran > I don't see how the AGP driver could interfere in a system that does not have any AGP hardware. The driver does not have any matching hardware to attach to so it's just unused code in memory. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 6 23:47:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C58CCD for ; Tue, 6 Nov 2012 23:47:00 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 17FE48FC0A for ; Tue, 6 Nov 2012 23:46:59 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TVsrD-0006Gg-Gn for freebsd-stable@freebsd.org; Tue, 06 Nov 2012 15:46:59 -0800 Date: Tue, 6 Nov 2012 15:46:59 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1352245619512-5758733.post@n5.nabble.com> In-Reply-To: References: <20121105150057.GA1151@mycenae.sbb.rs> Subject: Re: agp in kernel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:47:00 -0000 I think it's historical cruft, nvidia driver had it's own agp module or something to this effect. -- View this message in context: http://freebsd.1045724.n5.nabble.com/agp-in-kernel-tp5758326p5758733.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 7 05:50:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEC28361 for ; Wed, 7 Nov 2012 05:50:10 +0000 (UTC) (envelope-from zoranfooboo@yahoo.com) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5731F8FC08 for ; Wed, 7 Nov 2012 05:50:09 +0000 (UTC) Received: from [98.139.212.152] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2012 05:50:03 -0000 Received: from [98.139.212.200] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2012 05:50:03 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 07 Nov 2012 05:50:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 50797.69525.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 16512 invoked by uid 60001); 7 Nov 2012 05:50:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352267402; bh=mWC1n1ydSaDWSNyD407T//v4gkYcSi550ELKNo/ntRM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=qaOLul80Nc6d868jzUYV7ORqFrXVJVGLy/fNqdEXXt7vRvohBHqeORrdCPqKvDlpRvdEW2Ml25CI5lIQBmnoZUTgCTYgensyh4dZTxUNcH4vaps0TJIrQt3zto5BZ7Y8VpOd3+sW/s1IW65VJmfel9firQrmqzHUjrmFo8Ln+K0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=FmE4NLCmaTCEU7ZTXL8Bjw4NI0keU8Cmmw48Ef90MP4ybfe9XOGk4/0oIFQP+8jtGxXnR8YovCEyuLIZPkrmejdb9lYQESSOj58gEa+PSdsF5AB6PAsolJF65aTGXOw6aMMRjFmlgXEGX3Kb0W8Xbo9k6JCq6cDZ3qm3/nuRm80=; X-YMail-OSG: Sf5hytcVM1muA2MBOH1WxJ0rs4ViuwjkTbafhrk0M1SEK6_ 5SG1WxcHMiILtKAwbVpSAqDC5LihBBbDSQ6KlhmIwjnHDsc0BzoExJDzkDd9 cKE2wJqjMKoHaPdAwpYnWDFvcg4PJNOWPNpw1W8yxIIt4zqbVQnh1l_WMcNg HLWFuc9OP.HMa1z28T6erWcZSp4_CplZii6RkgUJDw7_dfx.rQyXJgWBTSFv wrVn_AtcHGaox9Vjdmvdd315WXGe9vFSuJwHR00KPE9q7lpN1KojlM3D7je7 kCDa4BeFwcKsiFmsP2Selto10e.Jn_fcAuUkhpLEmLn52CAuIEHdA8ik93rh 3EYcfX.KourBShv0dHR_J.9MEd3QvV8R0fCxUc6Bf43mUk2rBXE6BKcLLAGg 5bo7qhtvGIKjZqn38r83UxwtGJU88NXF_9vC68bP4KuOcxQ_fq5paR6KwD.H SEMZzCnJNnt35tGVVVnIBAy.4bbpfMahMKVGqht6hzh0fdC4MNje8OqYekHN wXa0.V8cP6lmSfbIje.PsrT9JoC8mMKHUzcBdlCsB4KGe7qWltw.XSWN5mq6 MW3yMtdahmQmwe9tOEy3kzqWxndaZG_iTn0hk Received: from [178.254.152.14] by web162206.mail.bf1.yahoo.com via HTTP; Tue, 06 Nov 2012 21:50:02 PST X-Rocket-MIMEInfo: 001.001, PiBJIGRvbid0IHNlZSBob3cgdGhlIEFHUCBkcml2ZXIgY291bGQgaW50ZXJmZXJlIGluIGEgc3lzdGVtIHRoYXQgZG9lcwo.IG5vdCBoYXZlIGFueSBBR1AgaGFyZHdhcmUuICBUaGUgZHJpdmVyIGRvZXMgbm90IGhhdmUgYW55IG1hdGNoaW5nCj4gaGFyZHdhcmUgdG8gYXR0YWNoIHRvIHNvIGl0J3MganVzdCB1bnVzZWQgY29kZSBpbiBtZW1vcnkuCgpTb3VuZHMgbG9naWNhbCwgYnV0IHRha2UgYSBsb29rIGF0IHRoaXMgcG9zdDoKaHR0cDovL3d3dy5tYWlsLWFyY2hpdmUuY29tL2ZyZWVic2Qtc3RhYmxlQGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 Message-ID: <1352267402.15489.YahooMailNeo@web162206.mail.bf1.yahoo.com> Date: Tue, 6 Nov 2012 21:50:02 -0800 (PST) From: Zoran Fooboo Subject: Re: agp in kernel To: "freebsd-stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Zoran Fooboo List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 05:50:10 -0000 > I don't see how the AGP driver could interfere in a system that does=0A> = not have any AGP hardware. The driver does not have any matching=0A> hardw= are to attach to so it's just unused code in memory.=0A=0ASounds logical, b= ut take a look at this post:=0Ahttp://www.mail-archive.com/freebsd-stable@f= reebsd.org/msg121942.html=0A=0AIt is Kostik Belousov's reply. What next I h= ave on my mind is:=0Aif I install vanilla 9.1, install intel driver, if I m= ake=0Axorg.conf, would it work out of the box? Is it necessary to=0Acompile= from the source with KMS and NEW_XORG?=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Zoran From owner-freebsd-stable@FreeBSD.ORG Wed Nov 7 14:43:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4D0FDD4 for ; Wed, 7 Nov 2012 14:43:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 98F4A8FC08 for ; Wed, 7 Nov 2012 14:43:53 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:17e:8599:3fcc:63a7] (unknown [IPv6:2001:7b8:3a7:0:17e:8599:3fcc:63a7]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 00B195C59; Wed, 7 Nov 2012 15:43:51 +0100 (CET) Message-ID: <509A73A8.2050602@FreeBSD.org> Date: Wed, 07 Nov 2012 15:43:52 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mike Jakubik Subject: Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang References: <1352242797.4156.3.camel@mjakubik.localdomain> In-Reply-To: <1352242797.4156.3.camel@mjakubik.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:43:54 -0000 On 2012-11-06 23:59, Mike Jakubik wrote:> > I've ran in to this issue on two different machines, both have recent > stable code. The problem appears to be > with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. ... > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error The output you pasted looks like it was produced by a multi-threaded build, and the actual error was obscured. Can you please retry this with a single-threaded build? From owner-freebsd-stable@FreeBSD.ORG Wed Nov 7 15:49:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9955C206; Wed, 7 Nov 2012 15:49:25 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [72.12.201.234]) by mx1.freebsd.org (Postfix) with ESMTP id 4F09F8FC0A; Wed, 7 Nov 2012 15:49:24 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 7 Nov 2012 10:48:15 -0500 Message-ID: <509A82BB.7070108@wintek.com> Date: Wed, 7 Nov 2012 10:48:11 -0500 From: Richard Kuhns Organization: Wintek Corporation User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang References: <1352242797.4156.3.camel@mjakubik.localdomain> <509A73A8.2050602@FreeBSD.org> In-Reply-To: <509A73A8.2050602@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: mike.jakubik@intertainservices.com, dim@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: rjk@wintek.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:49:25 -0000 On 11/07/12 09:43, Dimitry Andric wrote: > On 2012-11-06 23:59, Mike Jakubik wrote:> >> I've ran in to this issue on two different machines, both have recent >> stable code. The problem appears to be >> with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. > ... >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error > > The output you pasted looks like it was produced by a multi-threaded > build, and the actual error was obscured. Can you please retry this > with a single-threaded build? > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I'm not the original poster, but I've seen the same problem on 2 different machines as well. I just finished a single-threaded buildworld; it dies building boot2. svn says I'm "At revision 242695." The relevant portion of make.conf: ======== CC=clang CXX=clang++ CPP=clang-cpp # build world without -Werror NO_WERROR= # CPUTYPE?=core2 WITH_OPTIMIZED_CFLAGS=yes ======== ===> sys/boot/i386/boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000021 secs (24403223 bytes/sec) clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mstack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -mllvm -simplifycfg-dup-ret -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -Qunused-arguments -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' In file included from /usr/src/sys/boot/i386/boot2/boot2.c:170: /usr/src/sys/boot/i386/boot2/../../common/ufsread.c:233:17: warning: cast from 'char *' to 'struct ufs1_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/boot/i386/boot2/../../common/ufsread.c:236:17: warning: cast from 'char *' to 'struct ufs2_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/boot/i386/boot2/boot2.c:222:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ /usr/src/sys/boot/i386/boot2/boot2.c:353:4: warning: cast from 'caddr_t' (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] *(Elf32_Word *)p = es[i].sh_size; ^~~~~~~~~~~~~~~ /usr/src/sys/boot/i386/boot2/boot2.c:619:8: warning: cast from 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] t1 = *(uint32_t *)PTOV(0x46c); ^~~~~~~~~~~~~~~~~~~~~~~ 5 warnings generated. sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp clang -m32 -c boot2.s clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mstack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -mllvm -simplifycfg-dup-ret -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -Qunused-arguments -m32 -c /usr/src/sys/boot/i386/boot2/sio.S clang: warning: the clang compiler does not support '-fno-unit-at-a-time' ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /misc/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /misc/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 -5 bytes available *** [boot2] Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** [all] Error code 1 Stop in /usr/src/sys/boot/i386. *** [all] Error code 1 Stop in /usr/src/sys/boot. *** [all] Error code 1 Stop in /usr/src/sys. *** [sys.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 7 18:45:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C396984; Wed, 7 Nov 2012 18:45:22 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB208FC08; Wed, 7 Nov 2012 18:45:21 +0000 (UTC) Received: from [172.16.10.200] (unknown [172.16.10.200]) by mail.intertainservices.com (Postfix) with ESMTPSA id 5CCF75645C; Wed, 7 Nov 2012 13:45:19 -0500 (EST) Message-ID: <1352313919.1820.1.camel@mjakubik.localdomain> Subject: Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang From: Mike Jakubik To: Dimitry Andric Date: Wed, 07 Nov 2012 13:45:19 -0500 In-Reply-To: <509A73A8.2050602@FreeBSD.org> References: <1352242797.4156.3.camel@mjakubik.localdomain> <509A73A8.2050602@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 5CCF75645C.AFD37 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:45:22 -0000 On Wed, 2012-11-07 at 15:43 +0100, Dimitry Andric wrote: > On 2012-11-06 23:59, Mike Jakubik wrote:> > > I've ran in to this issue on two different machines, both have recent > > stable code. The problem appears to be > > with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. > ... > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > The output you pasted looks like it was produced by a multi-threaded > build, and the actual error was obscured. Can you please retry this > with a single-threaded build? > I resumed the build without -j4 and with NOCLEAN=YES and it finished successfully. I will do a clean and try again. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 7 18:54:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E664B8B; Wed, 7 Nov 2012 18:54:12 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 1CBE68FC14; Wed, 7 Nov 2012 18:54:11 +0000 (UTC) Received: from [172.16.10.200] (unknown [172.16.10.200]) by mail.intertainservices.com (Postfix) with ESMTPSA id 827D65645C; Wed, 7 Nov 2012 13:54:08 -0500 (EST) Message-ID: <1352314448.1820.3.camel@mjakubik.localdomain> Subject: Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang From: Mike Jakubik To: Dimitry Andric Date: Wed, 07 Nov 2012 13:54:08 -0500 In-Reply-To: <1352313919.1820.1.camel@mjakubik.localdomain> References: <1352242797.4156.3.camel@mjakubik.localdomain> <509A73A8.2050602@FreeBSD.org> <1352313919.1820.1.camel@mjakubik.localdomain> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 827D65645C.AEC1B X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:54:12 -0000 On Wed, 2012-11-07 at 13:45 -0500, Mike Jakubik wrote: > On Wed, 2012-11-07 at 15:43 +0100, Dimitry Andric wrote: > > On 2012-11-06 23:59, Mike Jakubik wrote:> > > > I've ran in to this issue on two different machines, both have recent > > > stable code. The problem appears to be > > > with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. > > ... > > > 1 error > > > *** Error code 2 > > > 1 error > > > *** Error code 2 > > > 1 error > > > > The output you pasted looks like it was produced by a multi-threaded > > build, and the actual error was obscured. Can you please retry this > > with a single-threaded build? > > > > I resumed the build without -j4 and with NOCLEAN=YES and it finished > successfully. I will do a clean and try again. > Oops, i did this on the wrong server. On the right server it fails compiling boot2 just like Richard describes. Thanks. ===> sys/boot/i386/boot2 (all) -5 bytes available *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 7 19:04:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F67EEF3 for ; Wed, 7 Nov 2012 19:04:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3798FC08 for ; Wed, 7 Nov 2012 19:04:19 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:17e:8599:3fcc:63a7] (unknown [IPv6:2001:7b8:3a7:0:17e:8599:3fcc:63a7]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C2F915C59; Wed, 7 Nov 2012 20:04:18 +0100 (CET) Message-ID: <509AB0B3.6030304@FreeBSD.org> Date: Wed, 07 Nov 2012 20:04:19 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mike Jakubik Subject: Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang References: <1352242797.4156.3.camel@mjakubik.localdomain> <509A73A8.2050602@FreeBSD.org> <1352313919.1820.1.camel@mjakubik.localdomain> <1352314448.1820.3.camel@mjakubik.localdomain> In-Reply-To: <1352314448.1820.3.camel@mjakubik.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:04:20 -0000 On 2012-11-07 19:54, Mike Jakubik wrote: ... > Oops, i did this on the wrong server. On the right server it fails > compiling boot2 just like Richard describes. > > Thanks. > > > ===> sys/boot/i386/boot2 (all) > -5 bytes available > *** Error code 1 > > Stop in /usr/src/sys/boot/i386/boot2. > *** Error code 1 Ah yes, I got it. This is currently a problem on stable/9, for which I don't yet have an easy solution, except building boot2 with gcc for now. See the earlier thread on freebsd-stable here: http://lists.freebsd.org/pipermail/freebsd-stable/2012-November/070459.html From owner-freebsd-stable@FreeBSD.ORG Wed Nov 7 20:04:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CBC9486; Wed, 7 Nov 2012 20:04:01 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 482998FC12; Wed, 7 Nov 2012 20:04:00 +0000 (UTC) Received: from [172.16.10.200] (unknown [172.16.10.200]) by mail.intertainservices.com (Postfix) with ESMTPSA id 5F80B5649B; Wed, 7 Nov 2012 15:03:58 -0500 (EST) Message-ID: <1352318638.1820.5.camel@mjakubik.localdomain> Subject: Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang From: Mike Jakubik To: Dimitry Andric Date: Wed, 07 Nov 2012 15:03:58 -0500 In-Reply-To: <509AB0B3.6030304@FreeBSD.org> References: <1352242797.4156.3.camel@mjakubik.localdomain> <509A73A8.2050602@FreeBSD.org> <1352313919.1820.1.camel@mjakubik.localdomain> <1352314448.1820.3.camel@mjakubik.localdomain> <509AB0B3.6030304@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 5F80B5649B.AE051 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:04:01 -0000 On Wed, 2012-11-07 at 20:04 +0100, Dimitry Andric wrote: > Ah yes, I got it. This is currently a problem on stable/9, for which I > don't yet have an easy solution, except building boot2 with gcc for now. > > See the earlier thread on freebsd-stable here: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-November/070459.html Sounds like using gcc for boot2 is the current work around till Clang 3.2 makes it in to stable. Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 00:35:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B5ECCA3; Thu, 8 Nov 2012 00:35:20 +0000 (UTC) (envelope-from prvs=1659aa6059=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 770088FC12; Thu, 8 Nov 2012 00:35:18 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000985388.msg; Thu, 08 Nov 2012 00:35:17 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 08 Nov 2012 00:35:17 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1659aa6059=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <0B4E8AFF9DA04C6EBD2496A8B58F1D67@multiplay.co.uk> From: "Steven Hartland" To: "Doug Ambrisko" References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> <20121105212911.GA17904@ambrisko.com> <27169C7FE704495087A093752D15E7B6@multiplay.co.uk> <20121106180152.GA40422@ambrisko.com> <6B5B65F4FC854EB8BBC701500096602E@multiplay.co.uk> Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Date: Thu, 8 Nov 2012 00:35:22 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0112_01CDBD48.EFF94C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 00:35:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0112_01CDBD48.EFF94C40 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Steven Hartland" >> On Tue, Nov 06, 2012 at 12:09:42AM -0000, Steven Hartland wrote: >> | Thanks Doug, actually just finished another test run with some more >> | debugging in and I believe I've found the reason for the non-recusive >> | lock and at least some of the queuing issues. >> | >> | The non-recursive lock is due to the mfi_tbolt_reset calling >> | mfi_process_fw_state_chg_isr with mfi_io_lock held which in turn calls >> | mfi_tbolt_init_MFI_queue which tries to acquire mfi_io_lock hence >> | the problem. >> | >> | mfi-lock.txt attached I believe fixes this as well as what appears >> | to be an invalid call to mtx_unlock(&sc->mfi_io_lock) in mfi_attach >> | which never acquires the lock as far as can see, possibly a cut and >> | paste error. >> >> I don't seem to see the attachment. > > Yer seems like some mail fail by me there, but I've had some more locking > panics during todays tests anyway, requiring additional fixes. Will update > and post when I'm happy with it. OK two patches attached == zz-mfi-lock.patch == Fixes mfi panic on recused on non-recusive mutex MFI I/O lock Removes a mtx_unlock call for mfi_io_lock which is never aquired == zz-mfi-queue.patch == Fixes queuing issues where mfi_release_command blindly sets the cm_flags = 0 without first removing the command from the relavent queue. This was causing panics in the queue functions which check to ensure a command is not on another queue. Also fixed some cases where the error from mfi_mapcmd was lost and where the command was never released / dequeued in error cases. Ensure that all failures to mfi_mapcmd are logged Fixed possible null pointer exception in mfi_aen_setup if mfi_get_log_state failed. Fixed mfi_parse_entries & mfi_aen_setup not returning possible errors Corrected MFI_DUMP_CMDS calls with invalid vars SC vs sc Commands which have timed out now set cm_error to ETIMEDOUT and call mfi_complete which prevents them getting stuck in the busy queue forever. Fixed possible use of NULL pointer in mfi_tbolt_get_cmd Changed output formats to be more easily recognisable when debugging. A few style (9) fixes e.g. braced single line conditions and double blank lines ---------- I've just had another panic, trace below, but it doesn't seem to be related to my changes so I'd appreciate your feedback on them as they are for now. While the lock patch fixes the problems I've seen, its not clear to me why mfi_tbolt_reset is acquiring the lock and hence requiring mfi_process_fw_state_chg_isr to jump through hoops to ensure locking around queue manipulation is done correctly. Given what its doing (resetting the entire adapter) I wouldn't be surprised if it should really be acquiring the config lock. Other things I've noticed / questions * Should mfi_abort sleep even if its call to mfi_mapcmd fails? * Should mfi_get_controller_info really ignore the error from mfi_mapcmd? * Do these controllers not support none 512 byte requests? Currently all syspd requests are done assuming 512 byte sectors which the disk may not be. This will both reduce performance or potentially break totally if the firmware isn't translating it under the surface correctly. Anyway the new panic manually transcribed is:- panic: Bad linx elm 0xffffff0069b0fc0 next->prev != elm ... mfi_tbolt_get_cmd() mfi_build_mpt_pass_thru() mfi_tbolt_build_mpt_cmd() mfi_tbolt_send_frame() bus_dmamap_load() mfi_mapcmd() mfi_startio() mfi_syspd_strategy() g_disk_start() g_io_schedule_down() g_down_proc_body() fork_exit() fork_trampoline() Looks like mfi_cmd_tbolt_tqh has become corrupt some how, but as far as I can tell all manip is done using the TAILQ macros and under mfi_io_lock so its not obvious to me at this time why this is, any ideas? There was an obvious error in mfi_tbolt_get_cmd which is now fixed in the queue patch, where cmd can be used even if queue was empty and TAILQ_FIRST returned NULL, but I can't see this causing this panic. This is running with a debug kernel with:- options WITNESS options INVARIANTS options INVARIANT_SUPPORT options DDB options GDB options PRINTF_BUFR_SIZE=2048 options MFI_DEBUG Unfortunately I've only got this hardware till Friday unfortunately so any ideas would be most appreciated so I can get testing done before then. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_0112_01CDBD48.EFF94C40 Content-Type: application/octet-stream; name="zz-mfi-lock.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zz-mfi-lock.patch" Fixes mfi panic on recused on non-recusive mutex MFI I/O lock=0A= =0A= Removes a mtx_unlock call for mfi_io_lock which is never aquired=0A= --- sys/dev/mfi/mfi.c.orig 2012-11-07 14:40:33.960774577 +0000=0A= +++ sys/dev/mfi/mfi.c 2012-11-07 14:50:28.267789676 +0000=0A= @@ -728,10 +728,8 @@=0A= "hook\n");=0A= return (EINVAL);=0A= }=0A= - if ((error =3D mfi_aen_setup(sc, 0), 0) !=3D 0) {=0A= - mtx_unlock(&sc->mfi_io_lock);=0A= + if ((error =3D mfi_aen_setup(sc, 0), 0) !=3D 0)=0A= return (error);=0A= - }=0A= =0A= /*=0A= * Register a shutdown handler.=0A= --- sys/dev/mfi/mfi_tbolt.c.orig 2012-11-07 12:21:56.249116533 +0000=0A= +++ sys/dev/mfi/mfi_tbolt.c 2012-11-07 14:50:28.268789748 +0000=0A= @@ -1194,6 +1194,7 @@=0A= sc->hw_crit_error=3D 1;=0A= return ;=0A= }=0A= + mtx_unlock(&sc->mfi_io_lock);=0A= if ((error =3D mfi_tbolt_init_MFI_queue(sc)) !=3D 0)=0A= return;=0A= =0A= @@ -1225,7 +1226,9 @@=0A= /*=0A= * Initiate AEN (Asynchronous Event Notification)=0A= */=0A= + mtx_unlock(&sc->mfi_io_lock);=0A= mfi_aen_setup(sc, sc->last_seq_num);=0A= + mtx_lock(&sc->mfi_io_lock);=0A= sc->issuepend_done =3D 1;=0A= device_printf(sc->mfi_dev, "second stage of reset "=0A= "complete, FW is ready now.\n");=0A= @@ -1237,7 +1240,6 @@=0A= device_printf(sc->mfi_dev, "mfi_process_fw_state_chg_isr "=0A= "called with unhandled value:%d\n", sc->adpreset);=0A= }=0A= - mtx_unlock(&sc->mfi_io_lock);=0A= }=0A= =0A= /*=0A= ------=_NextPart_000_0112_01CDBD48.EFF94C40 Content-Type: application/octet-stream; name="zz-mfi-queue.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zz-mfi-queue.patch" Fixes queuing issues where mfi_release_command blindly sets the cm_flags = =3D 0=0A= without first removing the command from the relavent queue.=0A= =0A= This was causing panics in the queue functions which check to ensure a = command=0A= is not on another queue.=0A= =0A= Also fixed some cases where the error from mfi_mapcmd was lost and where = the=0A= command was never released / dequeued in error cases.=0A= =0A= Ensure that all failures to mfi_mapcmd are logged=0A= =0A= Fixed possible null pointer exception in mfi_aen_setup if = mfi_get_log_state=0A= failed.=0A= =0A= Fixed mfi_parse_entries & mfi_aen_setup not returning possible errors=0A= =0A= Corrected MFI_DUMP_CMDS calls with invalid vars SC vs sc=0A= =0A= Commands which have timed out now set cm_error to ETIMEDOUT and call=0A= mfi_complete which prevents them getting stuck in the busy queue forever.=0A= =0A= Fixed possible use of NULL pointer in mfi_tbolt_get_cmd=0A= =0A= Changed output formats to be more easily recognisable when debugging.=0A= =0A= A few style (9) fixes e.g. braced single line conditions and double = blank lines=0A= --- sys/dev/mfi/mfi.c.orig 2012-11-07 14:50:28.267789676 +0000=0A= +++ sys/dev/mfi/mfi.c 2012-11-07 14:55:16.768525352 +0000=0A= @@ -837,6 +837,23 @@=0A= cm->cm_sg->sg32[0].addr =3D 0;=0A= }=0A= =0A= + /*=0A= + * Command may be on other queues e.g. busy queue depending on the=0A= + * flow of a previous call to mfi_mapcmd, so ensure its dequeued=0A= + * properly=0A= + */=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_BUSY) !=3D 0)=0A= + mfi_remove_busy(cm);=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_READY) !=3D 0)=0A= + mfi_remove_ready(cm);=0A= +=0A= + /* We're not expecting it to be on any other queue but check */=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_MASK) !=3D 0) {=0A= + printf("command %p is still on another queue, flags =3D %#x\n",=0A= + cm, cm->cm_flags);=0A= + panic("command is still on a queue");=0A= + }=0A= +=0A= hdr_data =3D (uint32_t *)cm->cm_frame;=0A= hdr_data[0] =3D 0; /* cmd, sense_len, cmd_status, scsi_status */=0A= hdr_data[1] =3D 0; /* target_id, lun_id, cdb_len, sg_count */=0A= @@ -950,15 +967,12 @@=0A= cm->cm_data =3D NULL;=0A= cm->cm_flags =3D MFI_CMD_POLLED;=0A= =0A= - if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0) {=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= device_printf(sc->mfi_dev, "failed to send init command\n");=0A= - mtx_unlock(&sc->mfi_io_lock);=0A= - return (error);=0A= - }=0A= mfi_release_command(cm);=0A= mtx_unlock(&sc->mfi_io_lock);=0A= =0A= - return (0);=0A= + return (error);=0A= }=0A= =0A= static int=0A= @@ -1046,27 +1060,26 @@=0A= class_locale.members.evt_class =3D mfi_event_class;=0A= =0A= if (seq_start =3D=3D 0) {=0A= - error =3D mfi_get_log_state(sc, &log_state);=0A= + if((error =3D mfi_get_log_state(sc, &log_state)) !=3D 0)=0A= + goto out;=0A= sc->mfi_boot_seq_num =3D log_state->boot_seq_num;=0A= - if (error) {=0A= - if (log_state)=0A= - free(log_state, M_MFIBUF);=0A= - return (error);=0A= - }=0A= =0A= /*=0A= * Walk through any events that fired since the last=0A= * shutdown.=0A= */=0A= - mfi_parse_entries(sc, log_state->shutdown_seq_num,=0A= - log_state->newest_seq_num);=0A= + if((error =3D mfi_parse_entries(sc, log_state->shutdown_seq_num,=0A= + log_state->newest_seq_num)) !=3D 0)=0A= + goto out;=0A= seq =3D log_state->newest_seq_num;=0A= } else=0A= seq =3D seq_start;=0A= - mfi_aen_register(sc, seq, class_locale.word);=0A= - free(log_state, M_MFIBUF);=0A= + error =3D mfi_aen_register(sc, seq, class_locale.word);=0A= +out:=0A= + if (log_state)=0A= + free(log_state, M_MFIBUF);=0A= =0A= - return 0;=0A= + return (error);=0A= }=0A= =0A= int=0A= @@ -1076,7 +1089,6 @@=0A= mtx_assert(&sc->mfi_io_lock, MA_OWNED);=0A= cm->cm_complete =3D NULL;=0A= =0A= -=0A= /*=0A= * MegaCli can issue a DCMD of 0. In this case do nothing=0A= * and return 0 to it as status=0A= @@ -1310,9 +1322,8 @@=0A= cm->cm_flags =3D MFI_CMD_POLLED;=0A= cm->cm_data =3D NULL;=0A= =0A= - if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0) {=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= device_printf(sc->mfi_dev, "Failed to shutdown controller\n");=0A= - }=0A= =0A= mfi_release_command(cm);=0A= mtx_unlock(&sc->mfi_io_lock);=0A= @@ -1796,6 +1807,7 @@=0A= mtx_lock(&sc->mfi_io_lock);=0A= mfi_release_command(cm);=0A= mtx_unlock(&sc->mfi_io_lock);=0A= + error =3D EIO;=0A= break;=0A= }=0A= mtx_lock(&sc->mfi_io_lock);=0A= @@ -1824,7 +1836,7 @@=0A= }=0A= =0A= free(el, M_MFIBUF);=0A= - return (0);=0A= + return (error);=0A= }=0A= =0A= static int=0A= @@ -1941,11 +1953,12 @@=0A= dcmd->mbox[0]=3Did;=0A= dcmd->header.scsi_status =3D 0;=0A= dcmd->header.pad0 =3D 0;=0A= - if (mfi_mapcmd(sc, cm) !=3D 0) {=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0) {=0A= device_printf(sc->mfi_dev,=0A= "Failed to get physical drive info %d\n", id);=0A= free(pd_info, M_MFIBUF);=0A= - return (0);=0A= + mfi_release_command(cm);=0A= + return (error);=0A= }=0A= bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap,=0A= BUS_DMASYNC_POSTREAD);=0A= @@ -2211,11 +2224,14 @@=0A= if ((hdr->cmd_status !=3D MFI_STAT_OK) || (hdr->scsi_status !=3D 0)) {=0A= bio->bio_flags |=3D BIO_ERROR;=0A= bio->bio_error =3D EIO;=0A= - device_printf(sc->mfi_dev, "I/O error, status=3D %d "=0A= - "scsi_status=3D %d\n", hdr->cmd_status, hdr->scsi_status);=0A= + device_printf(sc->mfi_dev, "I/O error, status=3D%#x "=0A= + "scsi_status=3D%#x\n", hdr->cmd_status, hdr->scsi_status);=0A= mfi_print_sense(cm->cm_sc, cm->cm_sense);=0A= } else if (cm->cm_error !=3D 0) {=0A= bio->bio_flags |=3D BIO_ERROR;=0A= + bio->bio_error =3D cm->cm_error;=0A= + device_printf(sc->mfi_dev, "I/O error, error=3D%#x\n",=0A= + cm->cm_error);=0A= }=0A= =0A= mfi_release_command(cm);=0A= @@ -2251,6 +2267,9 @@=0A= =0A= /* Send the command to the controller */=0A= if (mfi_mapcmd(sc, cm) !=3D 0) {=0A= + device_printf(sc->mfi_dev, "Failed to startio\n");=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_BUSY) !=3D 0)=0A= + mfi_remove_busy(cm);=0A= mfi_requeue_ready(cm);=0A= break;=0A= }=0A= @@ -2374,7 +2393,7 @@=0A= cm->cm_extra_frames =3D (cm->cm_total_frame_size - 1) / MFI_FRAME_SIZE;=0A= =0A= if (sc->MFA_enabled)=0A= - mfi_tbolt_send_frame(sc, cm);=0A= + mfi_tbolt_send_frame(sc, cm);=0A= else=0A= mfi_send_frame(sc, cm);=0A= =0A= @@ -2466,7 +2485,7 @@=0A= {=0A= struct mfi_command *cm;=0A= struct mfi_abort_frame *abort;=0A= - int i =3D 0;=0A= + int i =3D 0, error;=0A= uint32_t context =3D 0;=0A= =0A= mtx_lock(&sc->mfi_io_lock);=0A= @@ -2490,7 +2509,8 @@=0A= cm->cm_data =3D NULL;=0A= cm->cm_flags =3D MFI_CMD_POLLED;=0A= =0A= - mfi_mapcmd(sc, cm);=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= + device_printf(sc->mfi_dev, "failed to abort command\n");=0A= mfi_release_command(cm);=0A= =0A= mtx_unlock(&sc->mfi_io_lock);=0A= @@ -2506,7 +2526,7 @@=0A= mtx_unlock(&sc->mfi_io_lock);=0A= }=0A= =0A= - return (0);=0A= + return (error);=0A= }=0A= =0A= int=0A= @@ -2544,7 +2564,8 @@=0A= cm->cm_total_frame_size =3D MFI_IO_FRAME_SIZE;=0A= cm->cm_flags =3D MFI_CMD_POLLED | MFI_CMD_DATAOUT;=0A= =0A= - error =3D mfi_mapcmd(sc, cm);=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= + device_printf(sc->mfi_dev, "failed dump blocks\n");=0A= bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap,=0A= BUS_DMASYNC_POSTWRITE);=0A= bus_dmamap_unload(sc->mfi_buffer_dmat, cm->cm_dmamap);=0A= @@ -2587,7 +2608,8 @@=0A= cm->cm_total_frame_size =3D MFI_PASS_FRAME_SIZE;=0A= cm->cm_flags =3D MFI_CMD_POLLED | MFI_CMD_DATAOUT | MFI_CMD_SCSI;=0A= =0A= - error =3D mfi_mapcmd(sc, cm);=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= + device_printf(sc->mfi_dev, "failed dump blocks\n");=0A= bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap,=0A= BUS_DMASYNC_POSTWRITE);=0A= bus_dmamap_unload(sc->mfi_buffer_dmat, cm->cm_dmamap);=0A= @@ -3643,7 +3665,7 @@=0A= =0A= #if 0=0A= if (timedout)=0A= - MFI_DUMP_CMDS(SC);=0A= + MFI_DUMP_CMDS(sc);=0A= #endif=0A= =0A= mtx_unlock(&sc->mfi_io_lock);=0A= @@ -3656,7 +3678,7 @@=0A= mfi_timeout(void *data)=0A= {=0A= struct mfi_softc *sc =3D (struct mfi_softc *)data;=0A= - struct mfi_command *cm;=0A= + struct mfi_command *cm, *tmp;=0A= time_t deadline;=0A= int timedout =3D 0;=0A= =0A= @@ -3669,7 +3691,7 @@=0A= }=0A= }=0A= mtx_lock(&sc->mfi_io_lock);=0A= - TAILQ_FOREACH(cm, &sc->mfi_busy, cm_link) {=0A= + TAILQ_FOREACH_SAFE(cm, &sc->mfi_busy, cm_link, tmp) {=0A= if (sc->mfi_aen_cm =3D=3D cm || sc->mfi_map_sync_cm =3D=3D cm)=0A= continue;=0A= if (cm->cm_timestamp < deadline) {=0A= @@ -3682,6 +3704,13 @@=0A= );=0A= MFI_PRINT_CMD(cm);=0A= MFI_VALIDATE_CMD(sc, cm);=0A= + /*=0A= + * Fail the command instead of leaving it on=0A= + * the queue where it could remain stuck forever=0A= + */=0A= + mfi_remove_busy(cm);=0A= + cm->cm_error =3D ETIMEDOUT;=0A= + mfi_complete(sc, cm);=0A= timedout++;=0A= }=0A= }=0A= @@ -3689,7 +3718,7 @@=0A= =0A= #if 0=0A= if (timedout)=0A= - MFI_DUMP_CMDS(SC);=0A= + MFI_DUMP_CMDS(sc);=0A= #endif=0A= =0A= mtx_unlock(&sc->mfi_io_lock);=0A= --- sys/dev/mfi/mfi_tbolt.c.orig 2012-11-07 23:00:24.542124476 +0000=0A= +++ sys/dev/mfi/mfi_tbolt.c 2012-11-07 23:01:46.848207655 +0000=0A= @@ -162,14 +162,14 @@=0A= while (!( HostDiag & DIAG_WRITE_ENABLE)) {=0A= for (i =3D 0; i < 1000; i++);=0A= HostDiag =3D (uint32_t)MFI_READ4(sc, MFI_HDR);=0A= - device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%x, "=0A= - "hostdiag=3D%x\n", retry, HostDiag);=0A= + device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%d, "=0A= + "hostdiag=3D%#x\n", retry, HostDiag);=0A= =0A= if (retry++ >=3D 100)=0A= return 1;=0A= }=0A= =0A= - device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: HostDiag=3D%x\n", = HostDiag);=0A= + device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: HostDiag=3D%#x\n", = HostDiag);=0A= =0A= MFI_WRITE4(sc, MFI_HDR, (HostDiag | DIAG_RESET_ADAPTER));=0A= =0A= @@ -181,8 +181,8 @@=0A= while (HostDiag & DIAG_RESET_ADAPTER) {=0A= for (i =3D 0; i < 1000; i++) ;=0A= HostDiag =3D (uint32_t)MFI_READ4(sc, MFI_RSR);=0A= - device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%x, "=0A= - "hostdiag=3D%x\n", retry, HostDiag);=0A= + device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%d, "=0A= + "hostdiag=3D%#x\n", retry, HostDiag);=0A= =0A= if (retry++ >=3D 1000)=0A= return 1;=0A= @@ -734,7 +734,8 @@=0A= =0A= mtx_assert(&sc->mfi_io_lock, MA_OWNED);=0A= =0A= - cmd =3D TAILQ_FIRST(&sc->mfi_cmd_tbolt_tqh);=0A= + if ((cmd =3D TAILQ_FIRST(&sc->mfi_cmd_tbolt_tqh)) =3D=3D NULL)=0A= + return NULL;=0A= TAILQ_REMOVE(&sc->mfi_cmd_tbolt_tqh, cmd, next);=0A= memset((uint8_t *)cmd->sg_frame, 0, MEGASAS_MAX_SZ_CHAIN_FRAME);=0A= memset((uint8_t *)cmd->io_request, 0,=0A= @@ -1119,9 +1120,9 @@=0A= * should be performed on the controller=0A= */=0A= if (cm->retry_for_fw_reset =3D=3D 3) {=0A= - device_printf(sc->mfi_dev, "megaraid_sas: command %d "=0A= - "was tried multiple times during adapter reset"=0A= - "Shutting down the HBA\n", cm->cm_index);=0A= + device_printf(sc->mfi_dev, "megaraid_sas: command %p "=0A= + "index=3D%d was tried multiple times during adapter "=0A= + "reset - Shutting down the HBA\n", cm, cm->cm_index);=0A= mfi_kill_hba(sc);=0A= sc->hw_crit_error =3D 1;=0A= return;=0A= @@ -1137,8 +1138,8 @@=0A= if (cm->cm_frame->dcmd.opcode !=3D=0A= MFI_DCMD_CTRL_EVENT_WAIT) {=0A= device_printf(sc->mfi_dev,=0A= - "APJ ****requeue command %d \n",=0A= - cm->cm_index);=0A= + "APJ ****requeue command %p "=0A= + "index=3D%d\n", cm, cm->cm_index);=0A= mfi_requeue_ready(cm);=0A= }=0A= }=0A= @@ -1357,6 +1358,8 @@=0A= device_printf(sc->mfi_dev, "failed to send map sync\n");=0A= free(ld_sync, M_MFIBUF);=0A= sc->mfi_map_sync_cm =3D NULL;=0A= + if ((cmd->cm_flags & MFI_ON_MFIQ_BUSY) !=3D 0)=0A= + mfi_remove_busy(cmd);=0A= mfi_requeue_ready(cmd);=0A= goto out;=0A= }=0A= ------=_NextPart_000_0112_01CDBD48.EFF94C40-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 02:13:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A393488 for ; Thu, 8 Nov 2012 02:13:40 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail3.transactionware.com [202.68.173.211]) by mx1.freebsd.org (Postfix) with SMTP id 55B588FC18 for ; Thu, 8 Nov 2012 02:13:38 +0000 (UTC) Received: (qmail 6346 invoked by uid 907); 8 Nov 2012 02:06:56 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (202.68.173.218) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Thu, 08 Nov 2012 13:06:56 +1100 From: Jan Mikkelsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: dc(1) fails with "big number failure" on 2^64 Message-Id: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> Date: Thu, 8 Nov 2012 13:06:55 +1100 To: FreeBSD Stable Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 02:13:40 -0000 Hi, I am seeing this in dc: janm@gray: dc $ dc 18446744073709551616 18446744073709551616 / ps dc: big number failure 306b06b: No such file or directory That number is 2^64. The error is coming from BN_check in bdiv(), which = is complaining about the number at the top of the stack being = uninitialised. Looking at the data, after the second pop in bdiv() in = bdata.c, b->number->d[b->number->top - 1] =3D=3D 0. After a while poking = around in a debugger, it looks like the first word of the second number = (a->number->d) is being allocated at the same location as the last word = of the second number, it gets zeroed, and then looks uninitialised. All of this seems to be happening in the BN_* routines in openssl. I am seeing this on my builds for 9.1-RC3 and 9.0-p3, as well as the = CDROM shell on the 9.1-RC3 ISO, so I'm pretty sure it isn't my build = process or compiler flags. I have checked an OpenBSD 5.2 installation, = and it works fine. Can anyone confirm this? Am I just seeing things? Is there an obvious = fix? Thanks, Jan Mikkelsen From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 09:22:02 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B6C4450; Thu, 8 Nov 2012 09:22:02 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by mx1.freebsd.org (Postfix) with ESMTP id D96C98FC15; Thu, 8 Nov 2012 09:22:00 +0000 (UTC) Received: from mail64-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 09:06:46 +0000 Received: from mail64-ch1 (localhost [127.0.0.1]) by mail64-ch1-R.bigfish.com (Postfix) with ESMTP id B40604201C9; Thu, 8 Nov 2012 09:06:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:212.214.215.133; KIP:(null); UIP:(null); IPV:NLI; H:semtaout01.proact.se; RD:semtaout01.proact.se; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI542M1452I1432Izz1de0h1d18h1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail64-ch1 (localhost.localdomain [127.0.0.1]) by mail64-ch1 (MessageSwitch) id 1352365604890328_23454; Thu, 8 Nov 2012 09:06:44 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail64-ch1.bigfish.com (Postfix) with ESMTP id D6D2B2001D; Thu, 8 Nov 2012 09:06:44 +0000 (UTC) Received: from semtaout01.proact.se (212.214.215.133) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 09:06:40 +0000 Received: from Semail04.proact.local (unknown [10.7.1.58]) by semtaout01.proact.se (Postfix) with ESMTP id 3EF105727C; Thu, 8 Nov 2012 10:06:40 +0100 (CET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 10:06:39 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqAAF8a9gAAYYgXwAAYhBQAAk9ux8P///B6A//+/I1CAAHlQgP//5ozAgABIH4D//unQQABYwRGA//1wI8A= Date: Thu, 8 Nov 2012 09:06:38 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> <50995C8F.3040309@FreeBSD.org> In-Reply-To: <50995C8F.3040309@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" , "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 09:22:02 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 6. november 2012 19:53 > To: Tom Lislegaard > Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 06/11/2012 10:50 Tom Lislegaard said the following: > > No problem, I'm happy to assist in debugging this. > > > > Enabling the acpi debugging quickly fills the kernel message buffer, > > but it seems to be the same set of messages repeating again and again > > so I think this is representative > > > > https://dl.dropbox.com/u/13263820/debug_dmesg.txt >=20 > This didn't clarify things as much as I hoped, but I am inclined to think= that it is polling from > userland that triggers all the processor notifications. >=20 > In any case, here is a patch to try: > http://people.freebsd.org/~avg/acpi_cpu-stable.diff >=20 > Please disable all the tunings added to loader.conf during debugging when= testing this patch. >=20 > The patch is a combination of two changes: >=20 > 1. > Do not needlessly use ever-increasing resource IDs. > Rather use the IDs that are tied to Cx level IDs. > Also, release previous resources upon _CST change. >=20 > 2. > Bind a thread that processes a processor _CST change notification to the = target processor and perform > _CST processing in a critical section. These should ensure the following= : > - the CPU doesn't enter an idle state and doesn't try to use Cx level par= ameters > while they are being changed > - Cx level parameters are never concurrently modified when multiple notif= ications > fire in a rapid succession and multiple ACPI task threads are configure= d sched_bind is a heavy- > weight operation, but it is OK in this context because processor notifica= tions should not occur too > often >=20 Thanks. I applied the patch yesterday, but found this morning the machine h= ad crashed during the night with a page fault (kgdb) bt #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:229 #1 0xffffffff804441f4 in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke= rn_shutdown.c:448 #2 0xffffffff804446dc in panic (fmt=3D0x1
) at = /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff806f234d in trap_fatal (frame=3D0xfffffe00089264a0, eva=3DVar= iable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:878 #4 0xffffffff806f2668 in trap_pfault (frame=3D0xffffff82450401b0, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:794 #5 0xffffffff806f29ec in trap (frame=3D0xffffff82450401b0) at /usr/src/sys= /amd64/amd64/trap.c:463 #6 0xffffffff806dc5ff in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:228 #7 0xffffffff802d1bdd in AcpiOsAcquireObject (Cache=3D0xfffffe00052bac60) = at /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 #8 0xffffffff802d6883 in AcpiUtAllocateObjectDescDbg (ModuleName=3D0xfffff= fff8074c3f0 "dsutils", LineNumber=3D703, ComponentId=3DVariable "ComponentI= d" is not available. ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 #9 0xffffffff802d6a1d in AcpiUtCreateInternalObjectDbg (ModuleName=3D0xfff= fffff8074c3f0 "dsutils", LineNumber=3D703, ComponentId=3D64, Type=3D1) at /= usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 #10 0xffffffff802a71e8 in AcpiDsCreateOperand (WalkState=3D0xfffffe0008a3bc= 00, Arg=3D0xfffffe0005366800, ArgIndex=3D0) at /usr/src/sys/contrib/dev/acp= ica/dispatcher/dsutils.c:703 #11 0xffffffff802a7587 in AcpiDsCreateOperands (WalkState=3D0xfffffe0008a3b= c00, FirstArg=3D0xfffffe0005366800) at /usr/src/sys/contrib/dev/acpica/disp= atcher/dsutils.c:798 #12 0xffffffff802a856e in AcpiDsExecEndOp (WalkState=3D0xfffffe0008a3bc00) = at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567 #13 0xffffffff802c9441 in AcpiPsParseLoop (WalkState=3D0xfffffe0008a3bc00) = at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 #14 0xffffffff802ca8dd in AcpiPsParseAml (WalkState=3D0xfffffe0008a3bc00) a= t /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 #15 0xffffffff802cb981 in AcpiPsExecuteMethod (Info=3D0xfffffe01a2143100) a= t /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 #16 0xffffffff802c2287 in AcpiNsEvaluate (Info=3D0xfffffe01a2143100) at /us= r/src/sys/contrib/dev/acpica/namespace/nseval.c:193 #17 0xffffffff802d3f56 in AcpiUtEvaluateObject (PrefixNode=3D0xfffffe00052f= 6540, Path=3D0xffffffff807538f6 "_STA", ExpectedReturnBtypes=3D1, ReturnDes= c=3D0xffffff8245040660) at /usr/src/sys/contrib/dev/acpica/utilities/uteval= .c:102 #18 0xffffffff802d428f in AcpiUtExecute_STA (DeviceNode=3D0xfffffe00052f654= 0, Flags=3D0xfffffe01cc0d1e18) at /usr/src/sys/contrib/dev/acpica/utilities= /uteval.c:276 #19 0xffffffff802c7e47 in AcpiGetObjectInfo (Handle=3DVariable "Handle" is = not available. ) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfname.c:423 #20 0xffffffff802e35ed in acpi_BatteryIsPresent (dev=3D0xfffffe0005378c00) = at /usr/src/sys/dev/acpica/acpi.c:2064 #21 0xffffffff802e66e1 in acpi_battery_get_battinfo (dev=3D0x0, battinfo=3D= 0xffffffff80a4ba70) at /usr/src/sys/dev/acpica/acpi_battery.c:176 #22 0xffffffff802e6a44 in acpi_battery_sysctl (oidp=3D0xfffffe0008785600, a= rg1=3DVariable "arg1" is not available. ) at /usr/src/sys/dev/acpica/acpi_battery.c:428 #23 0xffffffff8044e057 in sysctl_root (oidp=3DVariable "oidp" is not availa= ble. ) at /usr/src/sys/kern/kern_sysctl.c:1513 #24 0xffffffff8044e335 in userland_sysctl (td=3DVariable "td" is not availa= ble. ) at /usr/src/sys/kern/kern_sysctl.c:1623 #25 0xffffffff8044e84a in sys___sysctl (td=3D0xfffffe0008c6c920, uap=3D0xff= ffff8245040a70) at /usr/src/sys/kern/kern_sysctl.c:1549 #26 0xffffffff806f1c40 in amd64_syscall (td=3D0xfffffe0008c6c920, traced=3D= 0) at subr_syscall.c:135 #27 0xffffffff806dc8e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:387 #28 0x00000008026587ec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 -tom From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 10:53:16 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D384EFC5; Thu, 8 Nov 2012 10:53:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DF9F68FC0A; Thu, 8 Nov 2012 10:53:15 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA14815; Thu, 08 Nov 2012 12:53:10 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TWPjS-000LXF-Eh; Thu, 08 Nov 2012 12:53:10 +0200 Message-ID: <509B8F15.4030300@FreeBSD.org> Date: Thu, 08 Nov 2012 12:53:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> <50995C8F.3040309@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 10:53:16 -0000 on 08/11/2012 11:06 Tom Lislegaard said the following: > >> -----Original Message----- >> From: Andriy Gapon [mailto:avg@FreeBSD.org] >> Sent: 6. november 2012 19:53 >> To: Tom Lislegaard >> Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >> >> on 06/11/2012 10:50 Tom Lislegaard said the following: >>> No problem, I'm happy to assist in debugging this. >>> >>> Enabling the acpi debugging quickly fills the kernel message buffer, >>> but it seems to be the same set of messages repeating again and again >>> so I think this is representative >>> >>> https://dl.dropbox.com/u/13263820/debug_dmesg.txt >> >> This didn't clarify things as much as I hoped, but I am inclined to think that it is polling from >> userland that triggers all the processor notifications. >> >> In any case, here is a patch to try: >> http://people.freebsd.org/~avg/acpi_cpu-stable.diff >> >> Please disable all the tunings added to loader.conf during debugging when testing this patch. >> >> The patch is a combination of two changes: >> >> 1. >> Do not needlessly use ever-increasing resource IDs. >> Rather use the IDs that are tied to Cx level IDs. >> Also, release previous resources upon _CST change. >> >> 2. >> Bind a thread that processes a processor _CST change notification to the target processor and perform >> _CST processing in a critical section. These should ensure the following: >> - the CPU doesn't enter an idle state and doesn't try to use Cx level parameters >> while they are being changed >> - Cx level parameters are never concurrently modified when multiple notifications >> fire in a rapid succession and multiple ACPI task threads are configured sched_bind is a heavy- >> weight operation, but it is OK in this context because processor notifications should not occur too >> often >> > > Thanks. I applied the patch yesterday, but found this morning the machine had crashed during the night with a page fault This looks like an unrelated / new / different problem. Could you please poke around frame 7? BTW, what version of FreeBSD do you use? What ACPICA version is there (debug.acpi.acpi_ca_version) ? It seems like somewhat similar panics were reported in the past: http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032637.html http://lists.freebsd.org/pipermail/freebsd-acpi/2012-January/007406.html > (kgdb) bt > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:229 > #1 0xffffffff804441f4 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff804446dc in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xffffffff806f234d in trap_fatal (frame=0xfffffe00089264a0, eva=Variable "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:878 > #4 0xffffffff806f2668 in trap_pfault (frame=0xffffff82450401b0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:794 > #5 0xffffffff806f29ec in trap (frame=0xffffff82450401b0) at /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff806dc5ff in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 > #7 0xffffffff802d1bdd in AcpiOsAcquireObject (Cache=0xfffffe00052bac60) at /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 > #8 0xffffffff802d6883 in AcpiUtAllocateObjectDescDbg (ModuleName=0xffffffff8074c3f0 "dsutils", LineNumber=703, ComponentId=Variable "ComponentId" is not available. > ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 > #9 0xffffffff802d6a1d in AcpiUtCreateInternalObjectDbg (ModuleName=0xffffffff8074c3f0 "dsutils", LineNumber=703, ComponentId=64, Type=1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 > #10 0xffffffff802a71e8 in AcpiDsCreateOperand (WalkState=0xfffffe0008a3bc00, Arg=0xfffffe0005366800, ArgIndex=0) at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703 > #11 0xffffffff802a7587 in AcpiDsCreateOperands (WalkState=0xfffffe0008a3bc00, FirstArg=0xfffffe0005366800) at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798 > #12 0xffffffff802a856e in AcpiDsExecEndOp (WalkState=0xfffffe0008a3bc00) at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567 > #13 0xffffffff802c9441 in AcpiPsParseLoop (WalkState=0xfffffe0008a3bc00) at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 > #14 0xffffffff802ca8dd in AcpiPsParseAml (WalkState=0xfffffe0008a3bc00) at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 > #15 0xffffffff802cb981 in AcpiPsExecuteMethod (Info=0xfffffe01a2143100) at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 > #16 0xffffffff802c2287 in AcpiNsEvaluate (Info=0xfffffe01a2143100) at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 > #17 0xffffffff802d3f56 in AcpiUtEvaluateObject (PrefixNode=0xfffffe00052f6540, Path=0xffffffff807538f6 "_STA", ExpectedReturnBtypes=1, ReturnDesc=0xffffff8245040660) at /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:102 > #18 0xffffffff802d428f in AcpiUtExecute_STA (DeviceNode=0xfffffe00052f6540, Flags=0xfffffe01cc0d1e18) at /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:276 > #19 0xffffffff802c7e47 in AcpiGetObjectInfo (Handle=Variable "Handle" is not available. > ) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfname.c:423 > #20 0xffffffff802e35ed in acpi_BatteryIsPresent (dev=0xfffffe0005378c00) at /usr/src/sys/dev/acpica/acpi.c:2064 > #21 0xffffffff802e66e1 in acpi_battery_get_battinfo (dev=0x0, battinfo=0xffffffff80a4ba70) at /usr/src/sys/dev/acpica/acpi_battery.c:176 > #22 0xffffffff802e6a44 in acpi_battery_sysctl (oidp=0xfffffe0008785600, arg1=Variable "arg1" is not available. > ) at /usr/src/sys/dev/acpica/acpi_battery.c:428 > #23 0xffffffff8044e057 in sysctl_root (oidp=Variable "oidp" is not available. > ) at /usr/src/sys/kern/kern_sysctl.c:1513 > #24 0xffffffff8044e335 in userland_sysctl (td=Variable "td" is not available. > ) at /usr/src/sys/kern/kern_sysctl.c:1623 > #25 0xffffffff8044e84a in sys___sysctl (td=0xfffffe0008c6c920, uap=0xffffff8245040a70) at /usr/src/sys/kern/kern_sysctl.c:1549 > #26 0xffffffff806f1c40 in amd64_syscall (td=0xfffffe0008c6c920, traced=0) at subr_syscall.c:135 > #27 0xffffffff806dc8e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 > #28 0x00000008026587ec in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > -tom > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 16:25:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB39CA46 for ; Thu, 8 Nov 2012 16:25:38 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id A68588FC17 for ; Thu, 8 Nov 2012 16:25:38 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TWUvB-00039m-Q7 for freebsd-stable@freebsd.org; Thu, 08 Nov 2012 08:25:37 -0800 Date: Thu, 8 Nov 2012 08:25:37 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1352391937800-5759209.post@n5.nabble.com> In-Reply-To: <5097E944.1000405@gmail.com> References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> <5097DE5E.6020405@FreeBSD.org> <5097E0BD.50909@gmail.com> <5097E2AF.2010000@FreeBSD.org> <5097E944.1000405@gmail.com> Subject: Re: buildworld fails on recent stable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:25:38 -0000 I unfortunately confirm this problem. While not "true and only way", I had impression, that (at this point) 9-STABLE should be possible to build with clang at any time. After all, building with clang started with essentially still 8 code. With introduction of: WITH_CLANG_IS_CC=true WITHOUT_GCC=true one can have at this point gcc42-less system, and for quite some time. I understand that situation is complicated, but would be happy if it would be fixed before Dec 16. -- View this message in context: http://freebsd.1045724.n5.nabble.com/buildworld-fails-on-recent-stable-tp5758273p5759209.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 16:26:42 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4998B52; Thu, 8 Nov 2012 16:26:42 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1ECF08FC14; Thu, 8 Nov 2012 16:26:41 +0000 (UTC) Received: from mail114-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 16:11:31 +0000 Received: from mail114-am1 (localhost [127.0.0.1]) by mail114-am1-R.bigfish.com (Postfix) with ESMTP id 06D85480298; Thu, 8 Nov 2012 16:11:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:195.159.75.198; KIP:(null); UIP:(null); IPV:NLI; H:nomtaout01.proact.no; RD:nomtaout01.proact.no; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI542M1452I1432Izz1de0h1d18h1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail114-am1 (localhost.localdomain [127.0.0.1]) by mail114-am1 (MessageSwitch) id 1352391088260958_8804; Thu, 8 Nov 2012 16:11:28 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.233]) by mail114-am1.bigfish.com (Postfix) with ESMTP id 3362B44004A; Thu, 8 Nov 2012 16:11:28 +0000 (UTC) Received: from nomtaout01.proact.no (195.159.75.198) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 16:11:26 +0000 Received: from Semail04.proact.local (outside.proact.se [212.214.215.3]) by nomtaout01.proact.no (Postfix) with ESMTP id BB57F5DD81; Thu, 8 Nov 2012 17:11:26 +0100 (MET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 17:11:26 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqAAF8a9gAAYYgXwAAYhBQAAk9ux8P///B6A//+/I1CAAHlQgP//5ozAgABIH4D//unQQABYwRGA//1wI8D/+tGOgP/1OpgA Date: Thu, 8 Nov 2012 16:11:26 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> <50995C8F.3040309@FreeBSD.org> <509B8F15.4030300@FreeBSD.org> In-Reply-To: <509B8F15.4030300@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" , "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:26:42 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 8. november 2012 11:53 > To: Tom Lislegaard > Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 08/11/2012 11:06 Tom Lislegaard said the following: > > > >> -----Original Message----- > >> From: Andriy Gapon [mailto:avg@FreeBSD.org] > >> Sent: 6. november 2012 19:53 > >> To: Tom Lislegaard > >> Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find > >> resource > >> > >> on 06/11/2012 10:50 Tom Lislegaard said the following: > >>> No problem, I'm happy to assist in debugging this. > >>> > >>> Enabling the acpi debugging quickly fills the kernel message buffer, > >>> but it seems to be the same set of messages repeating again and > >>> again so I think this is representative > >>> > >>> https://dl.dropbox.com/u/13263820/debug_dmesg.txt > >> > >> This didn't clarify things as much as I hoped, but I am inclined to > >> think that it is polling from userland that triggers all the processor= notifications. > >> > >> In any case, here is a patch to try: > >> http://people.freebsd.org/~avg/acpi_cpu-stable.diff > >> > >> Please disable all the tunings added to loader.conf during debugging w= hen testing this patch. > >> > >> The patch is a combination of two changes: > >> > >> 1. > >> Do not needlessly use ever-increasing resource IDs. > >> Rather use the IDs that are tied to Cx level IDs. > >> Also, release previous resources upon _CST change. > >> > >> 2. > >> Bind a thread that processes a processor _CST change notification to > >> the target processor and perform _CST processing in a critical section= . These should ensure the > following: > >> - the CPU doesn't enter an idle state and doesn't try to use Cx level = parameters > >> while they are being changed > >> - Cx level parameters are never concurrently modified when multiple no= tifications > >> fire in a rapid succession and multiple ACPI task threads are > >> configured sched_bind is a heavy- weight operation, but it is OK in > >> this context because processor notifications should not occur too > >> often > >> > > > > Thanks. I applied the patch yesterday, but found this morning the > > machine had crashed during the night with a page fault >=20 > This looks like an unrelated / new / different problem. > Could you please poke around frame 7? I've put up some more info=20 https://dl.dropbox.com/u/13263820/vmcore_7.txt > BTW, what version of FreeBSD do you use? Version is RELENG_9 checked out ~3 days ago > What ACPICA version is there (debug.acpi.acpi_ca_version) ? debug.acpi.acpi_ca_version: 20110527 -tom >=20 > It seems like somewhat similar panics were reported in the past: > http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032637.html > http://lists.freebsd.org/pipermail/freebsd-acpi/2012-January/007406.html >=20 > > (kgdb) bt > > #0 doadump (textdump=3DVariable "textdump" is not available. > > ) at pcpu.h:229 > > #1 0xffffffff804441f4 in kern_reboot (howto=3D260) at > > /usr/src/sys/kern/kern_shutdown.c:448 > > #2 0xffffffff804446dc in panic (fmt=3D0x1
) > > at /usr/src/sys/kern/kern_shutdown.c:636 > > #3 0xffffffff806f234d in trap_fatal (frame=3D0xfffffe00089264a0, eva= =3DVariable "eva" is not available. > > ) at /usr/src/sys/amd64/amd64/trap.c:878 > > #4 0xffffffff806f2668 in trap_pfault (frame=3D0xffffff82450401b0, > > usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:794 > > #5 0xffffffff806f29ec in trap (frame=3D0xffffff82450401b0) at > > /usr/src/sys/amd64/amd64/trap.c:463 > > #6 0xffffffff806dc5ff in calltrap () at > > /usr/src/sys/amd64/amd64/exception.S:228 > > #7 0xffffffff802d1bdd in AcpiOsAcquireObject > > (Cache=3D0xfffffe00052bac60) at > > /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 > > #8 0xffffffff802d6883 in AcpiUtAllocateObjectDescDbg (ModuleName=3D0xf= fffffff8074c3f0 "dsutils", > LineNumber=3D703, ComponentId=3DVariable "ComponentId" is not available. > > ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 > > #9 0xffffffff802d6a1d in AcpiUtCreateInternalObjectDbg > > (ModuleName=3D0xffffffff8074c3f0 "dsutils", LineNumber=3D703, > > ComponentId=3D64, Type=3D1) at > > /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 > > #10 0xffffffff802a71e8 in AcpiDsCreateOperand > > (WalkState=3D0xfffffe0008a3bc00, Arg=3D0xfffffe0005366800, ArgIndex=3D0= ) at > > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703 > > #11 0xffffffff802a7587 in AcpiDsCreateOperands > > (WalkState=3D0xfffffe0008a3bc00, FirstArg=3D0xfffffe0005366800) at > > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798 > > #12 0xffffffff802a856e in AcpiDsExecEndOp > > (WalkState=3D0xfffffe0008a3bc00) at > > /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567 > > #13 0xffffffff802c9441 in AcpiPsParseLoop > > (WalkState=3D0xfffffe0008a3bc00) at > > /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 > > #14 0xffffffff802ca8dd in AcpiPsParseAml > > (WalkState=3D0xfffffe0008a3bc00) at > > /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 > > #15 0xffffffff802cb981 in AcpiPsExecuteMethod > > (Info=3D0xfffffe01a2143100) at > > /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 > > #16 0xffffffff802c2287 in AcpiNsEvaluate (Info=3D0xfffffe01a2143100) at > > /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 > > #17 0xffffffff802d3f56 in AcpiUtEvaluateObject > > (PrefixNode=3D0xfffffe00052f6540, Path=3D0xffffffff807538f6 "_STA", > > ExpectedReturnBtypes=3D1, ReturnDesc=3D0xffffff8245040660) at > > /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:102 > > #18 0xffffffff802d428f in AcpiUtExecute_STA > > (DeviceNode=3D0xfffffe00052f6540, Flags=3D0xfffffe01cc0d1e18) at > > /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:276 > > #19 0xffffffff802c7e47 in AcpiGetObjectInfo (Handle=3DVariable "Handle"= is not available. > > ) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfname.c:423 > > #20 0xffffffff802e35ed in acpi_BatteryIsPresent > > (dev=3D0xfffffe0005378c00) at /usr/src/sys/dev/acpica/acpi.c:2064 > > #21 0xffffffff802e66e1 in acpi_battery_get_battinfo (dev=3D0x0, > > battinfo=3D0xffffffff80a4ba70) at > > /usr/src/sys/dev/acpica/acpi_battery.c:176 > > #22 0xffffffff802e6a44 in acpi_battery_sysctl (oidp=3D0xfffffe000878560= 0, arg1=3DVariable "arg1" is not > available. > > ) at /usr/src/sys/dev/acpica/acpi_battery.c:428 > > #23 0xffffffff8044e057 in sysctl_root (oidp=3DVariable "oidp" is not av= ailable. > > ) at /usr/src/sys/kern/kern_sysctl.c:1513 > > #24 0xffffffff8044e335 in userland_sysctl (td=3DVariable "td" is not av= ailable. > > ) at /usr/src/sys/kern/kern_sysctl.c:1623 > > #25 0xffffffff8044e84a in sys___sysctl (td=3D0xfffffe0008c6c920, > > uap=3D0xffffff8245040a70) at /usr/src/sys/kern/kern_sysctl.c:1549 > > #26 0xffffffff806f1c40 in amd64_syscall (td=3D0xfffffe0008c6c920, > > traced=3D0) at subr_syscall.c:135 > > #27 0xffffffff806dc8e7 in Xfast_syscall () at > > /usr/src/sys/amd64/amd64/exception.S:387 > > #28 0x00000008026587ec in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > > > -tom > > >=20 >=20 > -- > Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 16:35:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F3BD11D for ; Thu, 8 Nov 2012 16:35:35 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id EF0858FC08 for ; Thu, 8 Nov 2012 16:35:34 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TWV4o-0004Lq-Lf for freebsd-stable@freebsd.org; Thu, 08 Nov 2012 08:35:34 -0800 Date: Thu, 8 Nov 2012 08:35:34 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1352392534654-5759215.post@n5.nabble.com> In-Reply-To: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> References: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> Subject: Re: dc(1) fails with "big number failure" on 2^64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:35:35 -0000 I can confirm something similar. $ dc 18446744073709551616 18446744073709551616 / ps dc: big number failure 306b06b: No error: 0 FreeBSD 9.1-PRERELEASE #0 r242513 amd64, clang -- View this message in context: http://freebsd.1045724.n5.nabble.com/dc-1-fails-with-big-number-failure-on-2-64-tp5759049p5759215.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 18:32:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88AD5F80 for ; Thu, 8 Nov 2012 18:32:40 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id 185C18FC0C for ; Thu, 8 Nov 2012 18:32:39 +0000 (UTC) Received: from charlemagne.boland.org (37-251-66-226.FTTH.ispfabriek.nl [37.251.66.226]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA8IW1Ja026960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 19:32:02 +0100 (CET) (envelope-from boland37@xs4all.nl) Message-ID: <509BFAA1.8000201@xs4all.nl> Date: Thu, 08 Nov 2012 19:32:01 +0100 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jan Mikkelsen Subject: Re: dc(1) fails with "big number failure" on 2^64 References: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> In-Reply-To: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:32:40 -0000 On 11/08/2012 03:06, Jan Mikkelsen wrote: > Hi, > > I am seeing this in dc: > > janm@gray: dc $ dc > 18446744073709551616 18446744073709551616 / ps > dc: big number failure 306b06b: No such file or directory > > That number is 2^64. The error is coming from BN_check in bdiv(), which is complaining about the number at the top of the stack being uninitialised. Looking at the data, after the second pop in bdiv() in bdata.c, b->number->d[b->number->top - 1] == 0. After a while poking around in a debugger, it looks like the first word of the second number (a->number->d) is being allocated at the same location as the last word of the second number, it gets zeroed, and then looks uninitialised. > > All of this seems to be happening in the BN_* routines in openssl. > > I am seeing this on my builds for 9.1-RC3 and 9.0-p3, as well as the CDROM shell on the 9.1-RC3 ISO, so I'm pretty sure it isn't my build process or compiler flags. I have checked an OpenBSD 5.2 installation, and it works fine. > > Can anyone confirm this? Am I just seeing things? Is there an obvious fix? No fix, but I see a problem in the BN_add_word function in /usr/src/crypto/openssl/crypto/bn/bn_word.c /* Only expand (and risk failing) if it's possibly necessary */ if (((BN_ULONG)(a->d[a->top - 1] + 1) == 0) && (bn_wexpand(a,a->top+1) == NULL)) return(0); This can't possibly work, since it never calls bn_wexpand if, for example, you add 6 to the number 18446744073709551610 Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 19:40:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE25BE51 for ; Thu, 8 Nov 2012 19:40:09 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id 81E4E8FC0A for ; Thu, 8 Nov 2012 19:40:08 +0000 (UTC) Received: from charlemagne.boland.org (37-251-66-226.FTTH.ispfabriek.nl [37.251.66.226]) (authenticated bits=0) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA8JdTwW090609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 20:39:31 +0100 (CET) (envelope-from michiel@boland.org) Message-ID: <509C0A71.1060309@boland.org> Date: Thu, 08 Nov 2012 20:39:29 +0100 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jan Mikkelsen Subject: Re: dc(1) fails with "big number failure" on 2^64 References: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> <509BFAA1.8000201@xs4all.nl> In-Reply-To: <509BFAA1.8000201@xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:40:10 -0000 On 11/08/2012 19:32, Michiel Boland wrote: [...] > No fix, but I see a problem in the BN_add_word function in > /usr/src/crypto/openssl/crypto/bn/bn_word.c Small test case:- #include #include int main() { BIGNUM *n; n = BN_new(); BN_set_word(n, ULONG_MAX - 1); BN_add_word(n, 2); BN_free(n); return 0; } $ gcc x.c -lcrypto $ valgrind ./a.out ==30682== Memcheck, a memory error detector ==30682== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==30682== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==30682== Command: ./a.out ==30682== ==30682== Invalid write of size 8 ==30682== at 0x1328EA8: BN_add_word (bn_word.c:158) ==30682== by 0x40076E: main (in /usr/home/boland/a.out) ==30682== Address 0x18fc0a8 is 0 bytes after a block of size 8 alloc'd ==30682== at 0x100410B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==30682== by 0x1331B82: CRYPTO_malloc (mem.c:328) ==30682== by 0x1330F76: ??? (bn_lib.c:317) ==30682== by 0x13310C7: bn_expand2 (bn_lib.c:432) ==30682== by 0x133121C: BN_set_word (bn_lib.c:570) ==30682== by 0x400760: main (in /usr/home/boland/a.out) From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 23:28:11 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 231A9D81; Thu, 8 Nov 2012 23:28:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) 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 CB5D08FC13; Thu, 8 Nov 2012 23:28:10 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1FDD55C59; Fri, 9 Nov 2012 00:28:10 +0100 (CET) Message-ID: <509C400B.5080405@FreeBSD.org> Date: Fri, 09 Nov 2012 00:28:11 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: buildworld fails on recent stable References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> <5097DE5E.6020405@FreeBSD.org> <5097E0BD.50909@gmail.com> <5097E2AF.2010000@FreeBSD.org> <5097E944.1000405@gmail.com> In-Reply-To: <5097E944.1000405@gmail.com> Content-Type: multipart/mixed; boundary="------------090503070007040309010107" Cc: stable@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:28:11 -0000 This is a multi-part message in MIME format. --------------090503070007040309010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-11-05 17:28, Volodymyr Kostyrko wrote: > 05.11.2012 18:00, Andriy Gapon wrote: >>> I bet on clang 3.2. >> >> Thank you for checking. >> >> So how do we proceed from here? >> I could just revert the MFC-es, but the functionality could be desirable to some >> users. Are there any alternatives? > > Dunno, clang 3.2 is still pending so I guess it wouldn't be MFC'ed until > December 16th? Being a minor issue it can make some people shrug from > using clang for testing stable... While clang 3.2 will be branched for release soon, and hopefully will be released on the date you mention, it will probably not appear instantly in head. We need to test it rather thoroughly, to see if there are no unexpected side effects. Even then, I would not merge it to stable/9 after at least a month of settling in head. I have also looked at merging the snapshot of 3.2 we now have in head to stable/9, but it is also quite some work, so I found a better solution: I managed to shrink boot2 by enough bytes to make it fit again. I committed the change to head in r242804, and I will MFC it in 3 days, if there are no regressions reported. Meanwhile, please apply the attached patch. -Dimitry --------------090503070007040309010107 Content-Type: text/x-diff; name="shrink-boot2-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="shrink-boot2-1.diff" Index: sys/boot/i386/boot2/sio.S =================================================================== --- sys/boot/i386/boot2/sio.S (revision 242667) +++ sys/boot/i386/boot2/sio.S (working copy) @@ -40,13 +40,11 @@ sio_init: pushl %eax movb $0x3,%al # Set RTS, outb %al,(%dx) # DTR incl %edx # Line status reg - call sio_flush - ret + # Fallthrough /* int sio_flush(void) */ -sio_flush: xorl %eax,%eax # Return value - xorl %ecx,%ecx # Timeout +sio_flush: xorl %ecx,%ecx # Timeout movb $0x80,%ch # counter sio_flush.1: call sio_ischar # Check for character jz sio_flush.2 # Till none --------------090503070007040309010107-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 05:10:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2360716C for ; Fri, 9 Nov 2012 05:10:42 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail3.transactionware.com [202.68.173.211]) by mx1.freebsd.org (Postfix) with SMTP id 4824F8FC08 for ; Fri, 9 Nov 2012 05:10:40 +0000 (UTC) Received: (qmail 35104 invoked by uid 907); 9 Nov 2012 05:10:32 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (202.68.173.218) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Fri, 09 Nov 2012 16:10:32 +1100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: dc(1) fails with "big number failure" on 2^64 From: Jan Mikkelsen In-Reply-To: <509C0A71.1060309@boland.org> Date: Fri, 9 Nov 2012 16:10:31 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3A09BDDE-70C3-4235-8B48-67EF10984B94@transactionware.com> References: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> <509BFAA1.8000201@xs4all.nl> <509C0A71.1060309@boland.org> To: Michiel Boland , FreeBSD Stable X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 05:10:42 -0000 Hi, Great, the test case is very useful. I have applied the following patch to crypto/bn/bn_word.c, which fixes = the problem for me. --- = //depot/vendor/freebsd/9.1-local/src/crypto/openssl/crypto/bn/bn_word.c = 2012-08-13 00:32:35.000000000 1000 +++ = /data/scratch/janm/p4/freebsd-image-std-2011.1/FreeBSD/src/crypto/openssl/= crypto/bn/bn_word.c 2012-08-13 00:32:35.000000000 1000 @@ -145,9 +145,11 @@ return(i); } /* Only expand (and risk failing) if it's possibly necessary */ - if (((BN_ULONG)(a->d[a->top - 1] + 1) =3D=3D 0) && - (bn_wexpand(a,a->top+1) =3D=3D NULL)) - return(0); + if ( + (((a->top =3D=3D 1) && (BN_MASK2 - w < a->d[0])) || + ((a->top > 1) && ((BN_ULONG)(a->d[a->top - 1] + 1) =3D=3D= 0))) && + (bn_wexpand(a,a->top+1) =3D=3D NULL)) + return(0); i=3D0; for (;;) { This is a heap overflow in BN_add_word. I don't know what other problems = this could cause beyond bc and dc returning crap ... Regards, Jan. On 09/11/2012, at 6:39 AM, Michiel Boland wrote: > On 11/08/2012 19:32, Michiel Boland wrote: > [...] >> No fix, but I see a problem in the BN_add_word function in >> /usr/src/crypto/openssl/crypto/bn/bn_word.c >=20 > Small test case:- >=20 > #include > #include >=20 > int main() > { > BIGNUM *n; >=20 > n =3D BN_new(); > BN_set_word(n, ULONG_MAX - 1); > BN_add_word(n, 2); > BN_free(n); > return 0; > } >=20 >=20 > $ gcc x.c -lcrypto > $ valgrind ./a.out > =3D=3D30682=3D=3D Memcheck, a memory error detector > =3D=3D30682=3D=3D Copyright (C) 2002-2011, and GNU GPL'd, by Julian = Seward et al. > =3D=3D30682=3D=3D Using Valgrind-3.7.0 and LibVEX; rerun with -h for = copyright info > =3D=3D30682=3D=3D Command: ./a.out > =3D=3D30682=3D=3D > =3D=3D30682=3D=3D Invalid write of size 8 > =3D=3D30682=3D=3D at 0x1328EA8: BN_add_word (bn_word.c:158) > =3D=3D30682=3D=3D by 0x40076E: main (in /usr/home/boland/a.out) > =3D=3D30682=3D=3D Address 0x18fc0a8 is 0 bytes after a block of size = 8 alloc'd > =3D=3D30682=3D=3D at 0x100410B: malloc (in = /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) > =3D=3D30682=3D=3D by 0x1331B82: CRYPTO_malloc (mem.c:328) > =3D=3D30682=3D=3D by 0x1330F76: ??? (bn_lib.c:317) > =3D=3D30682=3D=3D by 0x13310C7: bn_expand2 (bn_lib.c:432) > =3D=3D30682=3D=3D by 0x133121C: BN_set_word (bn_lib.c:570) > =3D=3D30682=3D=3D by 0x400760: main (in /usr/home/boland/a.out) >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 11:18:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 008D2122 for ; Fri, 9 Nov 2012 11:18:51 +0000 (UTC) (envelope-from hingow@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 732458FC0A for ; Fri, 9 Nov 2012 11:18:50 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jm19so511240bkc.13 for ; Fri, 09 Nov 2012 03:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=cl7Wu6y+T4QRIYwZ82n/ITQa0e5SutGQJ4keOA6IZ3A=; b=Ssm/qVbgOyWTmIdApUgQdot0ARdTwSe34Az2iMXqPKohlWPV/14NQvUiG/17V50bJ9 qRBpeWwYgje/5RpP9PCFljXP02chlXM9HILjOJhTOq614+adS1LOA5wA2N+GtT2Ce8qw PGC7L0ZGt5XeAOxsJ3sTU96dxh/Z1v+64QRmW4XGvpTMq66pwO1IeUKQ0JNNtIzFQzsW HVXK0135u31zAD+I+/75vLd+Wmj5Jk9l+N8PjdSBJLUpVmbm/Je0530EgrmfwsGmMMhL 1Ve/5+lIZsgPdgf2kNQ26YtSOoEhivk3P6JyLyUoMruYLvLJIb1uCKAEVUUSorVD36lc joFg== Received: by 10.204.152.75 with SMTP id f11mr1664924bkw.23.1352459929530; Fri, 09 Nov 2012 03:18:49 -0800 (PST) Received: from mickey ([2a01:1e8:e100:82ac::91]) by mx.google.com with ESMTPS id z22sm18760737bkw.2.2012.11.09.03.18.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 03:18:48 -0800 (PST) Received: from [2a01:1e8:e100:82ac::91] (helo=localhost) by mickey with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TWmbk-00075T-4q for stable@FreeBSD.org; Fri, 09 Nov 2012 11:18:44 +0000 Date: Fri, 9 Nov 2012 12:18:43 +0100 From: "H. Ingow" To: stable@FreeBSD.org Subject: smartctl question Message-ID: <20121109111843.GA25461@tunchi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:18:52 -0000 Hi all, one single disk in a zfs mirror failed permanently throwing errors like kernel: (ada5:ata10:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT ) and alike. The pool itself continued working degraded, smartctl showed a very high 199 UDMA_CRC_Error_Count value, which to my knowledge may indicate a broken cable, in this case indeed a cable replacement solved the problem, the pool resilvered and all is fine. Still smartctl -a displays a value of 199 UDMA_CRC_Error_Count I reckon to be way too high, though ( > 3900 ) . So is this value now including errors from previous broken cable ? In other words, when, if at all, is the cache smartmontools read from flushed and values are to be taken as of the status after fixing a hardware problem but not swapping the disk ? Can someone please share some insight ? thanks From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 11:47:17 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D105E7A6 for ; Fri, 9 Nov 2012 11:47:17 +0000 (UTC) (envelope-from lbc@bnrlabs.com) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12]) by mx1.freebsd.org (Postfix) with ESMTP id 11E798FC14 for ; Fri, 9 Nov 2012 11:47:15 +0000 (UTC) Received: from mail.bnrlabs.com (unknown [82.224.61.5]) by smtp3-g21.free.fr (Postfix) with ESMTP id 44844A61EE; Fri, 9 Nov 2012 12:47:08 +0100 (CET) Received: from [127.0.0.1] (unknown [172.20.96.112]) by mail.bnrlabs.com (Postfix) with ESMTP id 07D3A46475; Fri, 9 Nov 2012 12:47:06 +0100 (CET) Message-ID: <509CED3E.8090103@bnrlabs.com> Date: Fri, 09 Nov 2012 12:47:10 +0100 From: "Lucas B. Cohen" MIME-Version: 1.0 To: "H. Ingow" Subject: Re: smartctl question References: <20121109111843.GA25461@tunchi> In-Reply-To: <20121109111843.GA25461@tunchi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:47:18 -0000 Hi, On 2012.11.09 12:18, H. Ingow wrote: > > Hi all, > > one single disk in a zfs mirror failed permanently throwing errors like > kernel: (ada5:ata10:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 84 > (ICRC ABRT ) and alike. > > The pool itself continued working degraded, smartctl showed a very high > 199 UDMA_CRC_Error_Count value, which to my knowledge may indicate a > broken cable, in this case indeed a cable replacement solved the > problem, the pool resilvered and all is fine. > > Still smartctl -a displays a value of 199 UDMA_CRC_Error_Count I reckon > to be way too high, though ( > 3900 ) . > So is this value now including errors from previous broken cable ? I'm pretty sure it is. I don't think SMART attributes can vary in value both up and down ; they seem to me like they're counters that can only get incremented. > In other words, when, if at all, is the cache smartmontools read from > flushed and values are to be taken as of the status after fixing a > hardware problem but not swapping the disk ? So, in my opinion no. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 12:43:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB25E5F5 for ; Fri, 9 Nov 2012 12:43:49 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7B48FC0C for ; Fri, 9 Nov 2012 12:43:49 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TWnw4-0007Qz-QL for freebsd-stable@freebsd.org; Fri, 09 Nov 2012 04:43:48 -0800 Date: Fri, 9 Nov 2012 04:43:48 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1352465028810-5759526.post@n5.nabble.com> In-Reply-To: <509C400B.5080405@FreeBSD.org> References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> <5097DE5E.6020405@FreeBSD.org> <5097E0BD.50909@gmail.com> <5097E2AF.2010000@FreeBSD.org> <5097E944.1000405@gmail.com> <509C400B.5080405@FreeBSD.org> Subject: Re: buildworld fails on recent stable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:43:50 -0000 Thanks, looking forward to MFC! -- View this message in context: http://freebsd.1045724.n5.nabble.com/buildworld-fails-on-recent-stable-tp5758273p5759526.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 12:44:24 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E412D6FC; Fri, 9 Nov 2012 12:44:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 039C98FC15; Fri, 9 Nov 2012 12:44:22 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qA9CiKgc035206; Fri, 9 Nov 2012 04:44:20 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qA9CiK7X035205; Fri, 9 Nov 2012 04:44:20 -0800 (PST) (envelope-from david) Date: Fri, 9 Nov 2012 04:44:20 -0800 From: David Wolfskill To: Dimitry Andric Subject: Re: buildworld fails on recent stable Message-ID: <20121109124420.GS1755@albert.catwhisker.org> References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> <5097DE5E.6020405@FreeBSD.org> <5097E0BD.50909@gmail.com> <5097E2AF.2010000@FreeBSD.org> <5097E944.1000405@gmail.com> <509C400B.5080405@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iUdyFHenu1vPh/Ml" Content-Disposition: inline In-Reply-To: <509C400B.5080405@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:44:25 -0000 --iUdyFHenu1vPh/Ml Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 09, 2012 at 12:28:11AM +0100, Dimitry Andric wrote: > ... > I have also looked at merging the snapshot of 3.2 we now have in head to > stable/9, but it is also quite some work, so I found a better solution: > I managed to shrink boot2 by enough bytes to make it fit again. >=20 > I committed the change to head in r242804, and I will MFC it in 3 days, > if there are no regressions reported. Meanwhile, please apply the > attached patch. > .... Works for me -- I'm now running: FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #292 24= 2822M: Fri Nov 9 04:26:20 PST 2012 root@g1-227.catwhisker.org:/usr/obj= /usr/src/sys/CANARY i386 built with clang. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --iUdyFHenu1vPh/Ml Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCc+qMACgkQmprOCmdXAD3n6wCcD1s5xL1w6RkuYCdAvPHb2m3p J8QAn26UXYNPKe26iUd3+Oovm1V/2WDo =dqNJ -----END PGP SIGNATURE----- --iUdyFHenu1vPh/Ml-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 17:06:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 185B7C06; Fri, 9 Nov 2012 17:06:04 +0000 (UTC) (envelope-from prvs=1660defc6c=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C5BB18FC12; Fri, 9 Nov 2012 17:06:02 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001002154.msg; Fri, 09 Nov 2012 17:05:59 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 09 Nov 2012 17:05:59 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1660defc6c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Steven Hartland" , "Doug Ambrisko" References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> <20121105212911.GA17904@ambrisko.com> <27169C7FE704495087A093752D15E7B6@multiplay.co.uk> <20121106180152.GA40422@ambrisko.com> <6B5B65F4FC854EB8BBC701500096602E@multiplay.co.uk> <0B4E8AFF9DA04C6EBD2496A8B58F1D67@multiplay.co.uk> Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Date: Fri, 9 Nov 2012 17:06:03 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0276_01CDBE9C.80113780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:06:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0276_01CDBE9C.80113780 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Steven Hartland" ... > I've just had another panic, trace below, but it doesn't seem to be related > to my changes so I'd appreciate your feedback on them as they are for now. > > While the lock patch fixes the problems I've seen, its not clear to me > why mfi_tbolt_reset is acquiring the lock and hence requiring > mfi_process_fw_state_chg_isr to jump through hoops to ensure locking > around queue manipulation is done correctly. Given what its doing > (resetting the entire adapter) I wouldn't be surprised if it should > really be acquiring the config lock. > > Other things I've noticed / questions > * Should mfi_abort sleep even if its call to mfi_mapcmd fails? > * Should mfi_get_controller_info really ignore the error from mfi_mapcmd? > * Do these controllers not support none 512 byte requests? Currently > all syspd requests are done assuming 512 byte sectors which the disk may > not be. This will both reduce performance or potentially break totally > if the firmware isn't translating it under the surface correctly. > > Anyway the new panic manually transcribed is:- > panic: Bad linx elm 0xffffff0069b0fc0 next->prev != elm > ... > mfi_tbolt_get_cmd() > mfi_build_mpt_pass_thru() > mfi_tbolt_build_mpt_cmd() > mfi_tbolt_send_frame() > bus_dmamap_load() > mfi_mapcmd() > mfi_startio() > mfi_syspd_strategy() > g_disk_start() > g_io_schedule_down() > g_down_proc_body() > fork_exit() > fork_trampoline() > > Looks like mfi_cmd_tbolt_tqh has become corrupt some how, but as far as I > can tell all manip is done using the TAILQ macros and under mfi_io_lock > so its not obvious to me at this time why this is, any ideas? I've gone through looking for the possible cause of this and while there's nothing directly connected to the manip of this queue I've found and fixed quite a large number of additional problems which may have been indirectly causing this problem. The biggest change is to use mfi_max_cmds to limit the value stored in sc->mfi_max_fw_cmds as this is used extensively throughout the driver for allocation and range checks so having this inconsitently set opened up a large number of possible overrun errors. The new patch attached documents all the changes in detail. I've managed to do one test run so far which failed to reproduce any panics, so definitely moving in the right direction :) The machine has now been collected for repair by the supplier but I'm going to try and get them to put it online for more testing over the weekend. Given the failure rate so far if I can do another 4 runs with no panics I'd be happy that the majority of error conditions are working as expected. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_0276_01CDBE9C.80113780 Content-Type: application/octet-stream; name="zz-mfi-queue.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zz-mfi-queue.patch" Fixes queuing issues where mfi_release_command blindly sets the cm_flags = =3D 0=0A= without first removing the command from the relavent queue.=0A= =0A= This was causing panics in the queue functions which check to ensure a = command=0A= is not on another queue.=0A= =0A= Fixed some cases where the error from mfi_mapcmd was lost and where the = command=0A= was never released / dequeued in error cases.=0A= =0A= Ensure that all failures to mfi_mapcmd are logged.=0A= =0A= Fixed possible null pointer exception in mfi_aen_setup if = mfi_get_log_state=0A= failed.=0A= =0A= Fixed mfi_parse_entries & mfi_aen_setup not returning possible errors.=0A= =0A= Corrected MFI_DUMP_CMDS calls with invalid vars SC vs sc.=0A= =0A= Commands which have timed out now set cm_error to ETIMEDOUT and call=0A= mfi_complete which prevents them getting stuck in the busy queue forever.=0A= =0A= Fixed possible use of NULL pointer in mfi_tbolt_get_cmd.=0A= =0A= Changed output formats to be more easily recognisable when debugging.=0A= =0A= Optimised mfi_cmd_pool_tbolt cleanup.=0A= =0A= Made information about driver limiting commands always display as for = modern=0A= cards this can be severe.=0A= =0A= Fixed mfi_tbolt_alloc_cmd out of memory case which previously didnt = return an=0A= error.=0A= =0A= Added malloc checks for request_desc_pool including free when subsiquent = errors=0A= are detected.=0A= =0A= Fixed overflow error in SIMD reply descriptor check.=0A= =0A= Fixed tbolt_cmd leak in mfi_build_and_issue_cmd if there's an error = during IO=0A= build.=0A= =0A= Elimintated double checks on sc->mfi_aen_cm & sc->mfi_map_sync_cm in=0A= mfi_shutdown.=0A= =0A= Move local hdr calculation after error check in mfi_aen_complete.=0A= =0A= Fixed wakeup on NULL in mfi_aen_complete.=0A= =0A= Fixed mfi_aen_cm cleanup in mfi_process_fw_state_chg_isr not checking if = it was=0A= NULL.=0A= =0A= Changed mfi_alloc_commands to error if bus_dmamap_create fails. = Previously we=0A= would try to continue with the number of allocated commands but lots of = places=0A= in the driver assume sc->mfi_max_fw_cmds is whats available so its = unsafe to do=0A= this without lots of changes.=0A= =0A= Removed mfi_total_cmds as its no longer used due the above change.=0A= =0A= Corrected mfi_tbolt_alloc_cmd to return ENOMEM where appropriate.=0A= =0A= Fixed timeouts actually firing at double what they should.=0A= =0A= Setting hw.mfi.max_cmds=3D-1 now configures to use the controller max.=0A= =0A= A few style (9) fixes e.g. braced single line conditions and double = blank lines=0A= --- sys/dev/mfi/mfi.c.orig 2012-11-07 23:00:24.540112877 +0000=0A= +++ sys/dev/mfi/mfi.c 2012-11-09 14:10:12.288110349 +0000=0A= @@ -143,7 +143,7 @@=0A= static int mfi_max_cmds =3D 128;=0A= TUNABLE_INT("hw.mfi.max_cmds", &mfi_max_cmds);=0A= SYSCTL_INT(_hw_mfi, OID_AUTO, max_cmds, CTLFLAG_RD, &mfi_max_cmds,=0A= - 0, "Max commands");=0A= + 0, "Max commands limit (-1 =3D controller limit)");=0A= =0A= static int mfi_detect_jbod_change =3D 1;=0A= TUNABLE_INT("hw.mfi.detect_jbod_change", &mfi_detect_jbod_change);=0A= @@ -366,7 +366,7 @@=0A= {=0A= uint32_t status;=0A= int error, commsz, framessz, sensesz;=0A= - int frames, unit, max_fw_sge;=0A= + int frames, unit, max_fw_sge, max_fw_cmds;=0A= uint32_t tb_mem_size =3D 0;=0A= =0A= if (sc =3D=3D NULL)=0A= @@ -461,7 +461,13 @@=0A= * instead of compile time.=0A= */=0A= status =3D sc->mfi_read_fw_status(sc);=0A= - sc->mfi_max_fw_cmds =3D status & MFI_FWSTATE_MAXCMD_MASK;=0A= + max_fw_cmds =3D status & MFI_FWSTATE_MAXCMD_MASK;=0A= + if (mfi_max_cmds > 0 && mfi_max_cmds < max_fw_cmds) {=0A= + device_printf(sc->mfi_dev, "FW MaxCmds =3D %d, limiting to %d\n",=0A= + max_fw_cmds, mfi_max_cmds);=0A= + sc->mfi_max_fw_cmds =3D mfi_max_cmds;=0A= + } else=0A= + sc->mfi_max_fw_cmds =3D max_fw_cmds;=0A= max_fw_sge =3D (status & MFI_FWSTATE_MAXSGL_MASK) >> 16;=0A= sc->mfi_max_sge =3D min(max_fw_sge, ((MFI_MAXPHYS / PAGE_SIZE) + 1));=0A= =0A= @@ -469,7 +475,8 @@=0A= =0A= if (sc->mfi_flags & MFI_FLAGS_TBOLT) {=0A= mfi_tbolt_init_globals(sc);=0A= - device_printf(sc->mfi_dev, "MaxCmd =3D %x MaxSgl =3D %x state =3D %x = \n",=0A= + device_printf(sc->mfi_dev, "MaxCmd =3D %d, Drv MaxCmd =3D %d, "=0A= + "MaxSgl =3D %d, state =3D %#x\n", max_fw_cmds,=0A= sc->mfi_max_fw_cmds, sc->mfi_max_sge, status);=0A= tb_mem_size =3D mfi_tbolt_get_memory_requirement(sc);=0A= =0A= @@ -779,21 +786,16 @@=0A= mfi_alloc_commands(struct mfi_softc *sc)=0A= {=0A= struct mfi_command *cm;=0A= - int i, ncmds;=0A= + int i, j;=0A= =0A= /*=0A= * XXX Should we allocate all the commands up front, or allocate on=0A= * demand later like 'aac' does?=0A= */=0A= - ncmds =3D MIN(mfi_max_cmds, sc->mfi_max_fw_cmds);=0A= - if (bootverbose)=0A= - device_printf(sc->mfi_dev, "Max fw cmds=3D %d, sizing driver "=0A= - "pool to %d\n", sc->mfi_max_fw_cmds, ncmds);=0A= -=0A= - sc->mfi_commands =3D malloc(sizeof(struct mfi_command) * ncmds, = M_MFIBUF,=0A= - M_WAITOK | M_ZERO);=0A= + sc->mfi_commands =3D malloc(sizeof(struct mfi_command) *=0A= + sc->mfi_max_fw_cmds, M_MFIBUF, M_WAITOK | M_ZERO);=0A= =0A= - for (i =3D 0; i < ncmds; i++) {=0A= + for (i =3D 0; i < sc->mfi_max_fw_cmds; i++) {=0A= cm =3D &sc->mfi_commands[i];=0A= cm->cm_frame =3D (union mfi_frame *)((uintptr_t)sc->mfi_frames +=0A= sc->mfi_cmd_size * i);=0A= @@ -809,10 +811,20 @@=0A= mtx_lock(&sc->mfi_io_lock);=0A= mfi_release_command(cm);=0A= mtx_unlock(&sc->mfi_io_lock);=0A= + } else {=0A= + device_printf(sc->mfi_dev, "Failed to allocate %d "=0A= + "command blocks, only allocated %d\n",=0A= + sc->mfi_max_fw_cmds, i - 1);=0A= + for (j =3D 0; j < i; j++) {=0A= + cm =3D &sc->mfi_commands[i];=0A= + bus_dmamap_destroy(sc->mfi_buffer_dmat,=0A= + cm->cm_dmamap);=0A= + }=0A= + free(sc->mfi_commands, M_MFIBUF);=0A= + sc->mfi_commands =3D NULL;=0A= + =0A= + return (ENOMEM);=0A= }=0A= - else=0A= - break;=0A= - sc->mfi_total_cmds++;=0A= }=0A= =0A= return (0);=0A= @@ -837,6 +849,23 @@=0A= cm->cm_sg->sg32[0].addr =3D 0;=0A= }=0A= =0A= + /*=0A= + * Command may be on other queues e.g. busy queue depending on the=0A= + * flow of a previous call to mfi_mapcmd, so ensure its dequeued=0A= + * properly=0A= + */=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_BUSY) !=3D 0)=0A= + mfi_remove_busy(cm);=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_READY) !=3D 0)=0A= + mfi_remove_ready(cm);=0A= +=0A= + /* We're not expecting it to be on any other queue but check */=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_MASK) !=3D 0) {=0A= + printf("command %p is still on another queue, flags =3D %#x\n",=0A= + cm, cm->cm_flags);=0A= + panic("command is still on a queue");=0A= + }=0A= +=0A= hdr_data =3D (uint32_t *)cm->cm_frame;=0A= hdr_data[0] =3D 0; /* cmd, sense_len, cmd_status, scsi_status */=0A= hdr_data[1] =3D 0; /* target_id, lun_id, cdb_len, sg_count */=0A= @@ -950,15 +979,12 @@=0A= cm->cm_data =3D NULL;=0A= cm->cm_flags =3D MFI_CMD_POLLED;=0A= =0A= - if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0) {=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= device_printf(sc->mfi_dev, "failed to send init command\n");=0A= - mtx_unlock(&sc->mfi_io_lock);=0A= - return (error);=0A= - }=0A= mfi_release_command(cm);=0A= mtx_unlock(&sc->mfi_io_lock);=0A= =0A= - return (0);=0A= + return (error);=0A= }=0A= =0A= static int=0A= @@ -1046,27 +1072,26 @@=0A= class_locale.members.evt_class =3D mfi_event_class;=0A= =0A= if (seq_start =3D=3D 0) {=0A= - error =3D mfi_get_log_state(sc, &log_state);=0A= + if((error =3D mfi_get_log_state(sc, &log_state)) !=3D 0)=0A= + goto out;=0A= sc->mfi_boot_seq_num =3D log_state->boot_seq_num;=0A= - if (error) {=0A= - if (log_state)=0A= - free(log_state, M_MFIBUF);=0A= - return (error);=0A= - }=0A= =0A= /*=0A= * Walk through any events that fired since the last=0A= * shutdown.=0A= */=0A= - mfi_parse_entries(sc, log_state->shutdown_seq_num,=0A= - log_state->newest_seq_num);=0A= + if((error =3D mfi_parse_entries(sc, log_state->shutdown_seq_num,=0A= + log_state->newest_seq_num)) !=3D 0)=0A= + goto out;=0A= seq =3D log_state->newest_seq_num;=0A= } else=0A= seq =3D seq_start;=0A= - mfi_aen_register(sc, seq, class_locale.word);=0A= - free(log_state, M_MFIBUF);=0A= + error =3D mfi_aen_register(sc, seq, class_locale.word);=0A= +out:=0A= + if (log_state)=0A= + free(log_state, M_MFIBUF);=0A= =0A= - return 0;=0A= + return (error);=0A= }=0A= =0A= int=0A= @@ -1076,7 +1101,6 @@=0A= mtx_assert(&sc->mfi_io_lock, MA_OWNED);=0A= cm->cm_complete =3D NULL;=0A= =0A= -=0A= /*=0A= * MegaCli can issue a DCMD of 0. In this case do nothing=0A= * and return 0 to it as status=0A= @@ -1104,12 +1128,13 @@=0A= if (sc->mfi_cdev !=3D NULL)=0A= destroy_dev(sc->mfi_cdev);=0A= =0A= - if (sc->mfi_total_cmds !=3D 0) {=0A= - for (i =3D 0; i < sc->mfi_total_cmds; i++) {=0A= + if (sc->mfi_commands !=3D NULL) {=0A= + for (i =3D 0; i < sc->mfi_max_fw_cmds; i++) {=0A= cm =3D &sc->mfi_commands[i];=0A= bus_dmamap_destroy(sc->mfi_buffer_dmat, cm->cm_dmamap);=0A= }=0A= free(sc->mfi_commands, M_MFIBUF);=0A= + sc->mfi_commands =3D NULL;=0A= }=0A= =0A= if (sc->mfi_intr)=0A= @@ -1165,7 +1190,8 @@=0A= /* End LSIP200113393 */=0A= /* ThunderBolt INIT packet memory Free */=0A= if (sc->mfi_tb_init_busaddr !=3D 0)=0A= - bus_dmamap_unload(sc->mfi_tb_init_dmat, sc->mfi_tb_init_dmamap);=0A= + bus_dmamap_unload(sc->mfi_tb_init_dmat,=0A= + sc->mfi_tb_init_dmamap);=0A= if (sc->mfi_tb_init !=3D NULL)=0A= bus_dmamem_free(sc->mfi_tb_init_dmat, sc->mfi_tb_init,=0A= sc->mfi_tb_init_dmamap);=0A= @@ -1182,16 +1208,14 @@=0A= sc->mfi_tb_ioc_init_dmamap);=0A= if (sc->mfi_tb_ioc_init_dmat !=3D NULL)=0A= bus_dma_tag_destroy(sc->mfi_tb_ioc_init_dmat);=0A= - for (int i =3D 0; i < sc->mfi_max_fw_cmds; i++) {=0A= - if (sc->mfi_cmd_pool_tbolt !=3D NULL) {=0A= + if (sc->mfi_cmd_pool_tbolt !=3D NULL) {=0A= + for (int i =3D 0; i < sc->mfi_max_fw_cmds; i++) {=0A= if (sc->mfi_cmd_pool_tbolt[i] !=3D NULL) {=0A= free(sc->mfi_cmd_pool_tbolt[i],=0A= M_MFIBUF);=0A= sc->mfi_cmd_pool_tbolt[i] =3D NULL;=0A= }=0A= }=0A= - }=0A= - if (sc->mfi_cmd_pool_tbolt !=3D NULL) {=0A= free(sc->mfi_cmd_pool_tbolt, M_MFIBUF);=0A= sc->mfi_cmd_pool_tbolt =3D NULL;=0A= }=0A= @@ -1256,9 +1280,8 @@=0A= cm->cm_error =3D 0;=0A= mfi_complete(sc, cm);=0A= }=0A= - if (++ci =3D=3D (sc->mfi_max_fw_cmds + 1)) {=0A= + if (++ci =3D=3D (sc->mfi_max_fw_cmds + 1))=0A= ci =3D 0;=0A= - }=0A= }=0A= =0A= sc->mfi_comms->hw_ci =3D ci;=0A= @@ -1288,15 +1311,15 @@=0A= int error;=0A= =0A= =0A= - if (sc->mfi_aen_cm)=0A= + if (sc->mfi_aen_cm !=3D NULL) {=0A= sc->cm_aen_abort =3D 1;=0A= - if (sc->mfi_aen_cm !=3D NULL)=0A= mfi_abort(sc, &sc->mfi_aen_cm);=0A= + }=0A= =0A= - if (sc->mfi_map_sync_cm)=0A= + if (sc->mfi_map_sync_cm !=3D NULL) {=0A= sc->cm_map_abort =3D 1;=0A= - if (sc->mfi_map_sync_cm !=3D NULL)=0A= mfi_abort(sc, &sc->mfi_map_sync_cm);=0A= + }=0A= =0A= mtx_lock(&sc->mfi_io_lock);=0A= error =3D mfi_dcmd_command(sc, &cm, MFI_DCMD_CTRL_SHUTDOWN, NULL, 0);=0A= @@ -1310,9 +1333,8 @@=0A= cm->cm_flags =3D MFI_CMD_POLLED;=0A= cm->cm_data =3D NULL;=0A= =0A= - if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0) {=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= device_printf(sc->mfi_dev, "Failed to shutdown controller\n");=0A= - }=0A= =0A= mfi_release_command(cm);=0A= mtx_unlock(&sc->mfi_io_lock);=0A= @@ -1683,11 +1705,11 @@=0A= sc =3D cm->cm_sc;=0A= mtx_assert(&sc->mfi_io_lock, MA_OWNED);=0A= =0A= - hdr =3D &cm->cm_frame->header;=0A= -=0A= if (sc->mfi_aen_cm =3D=3D NULL)=0A= return;=0A= =0A= + hdr =3D &cm->cm_frame->header;=0A= +=0A= if (sc->cm_aen_abort ||=0A= hdr->cmd_status =3D=3D MFI_STAT_INVALID_STATUS) {=0A= sc->cm_aen_abort =3D 0;=0A= @@ -1713,8 +1735,8 @@=0A= }=0A= =0A= free(cm->cm_data, M_MFIBUF);=0A= - sc->mfi_aen_cm =3D NULL;=0A= wakeup(&sc->mfi_aen_cm);=0A= + sc->mfi_aen_cm =3D NULL;=0A= mfi_release_command(cm);=0A= =0A= /* set it up again so the driver can catch more events */=0A= @@ -1796,6 +1818,7 @@=0A= mtx_lock(&sc->mfi_io_lock);=0A= mfi_release_command(cm);=0A= mtx_unlock(&sc->mfi_io_lock);=0A= + error =3D EIO;=0A= break;=0A= }=0A= mtx_lock(&sc->mfi_io_lock);=0A= @@ -1824,7 +1847,7 @@=0A= }=0A= =0A= free(el, M_MFIBUF);=0A= - return (0);=0A= + return (error);=0A= }=0A= =0A= static int=0A= @@ -1941,11 +1964,12 @@=0A= dcmd->mbox[0]=3Did;=0A= dcmd->header.scsi_status =3D 0;=0A= dcmd->header.pad0 =3D 0;=0A= - if (mfi_mapcmd(sc, cm) !=3D 0) {=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0) {=0A= device_printf(sc->mfi_dev,=0A= "Failed to get physical drive info %d\n", id);=0A= free(pd_info, M_MFIBUF);=0A= - return (0);=0A= + mfi_release_command(cm);=0A= + return (error);=0A= }=0A= bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap,=0A= BUS_DMASYNC_POSTREAD);=0A= @@ -2211,11 +2235,14 @@=0A= if ((hdr->cmd_status !=3D MFI_STAT_OK) || (hdr->scsi_status !=3D 0)) {=0A= bio->bio_flags |=3D BIO_ERROR;=0A= bio->bio_error =3D EIO;=0A= - device_printf(sc->mfi_dev, "I/O error, status=3D %d "=0A= - "scsi_status=3D %d\n", hdr->cmd_status, hdr->scsi_status);=0A= + device_printf(sc->mfi_dev, "I/O error, status=3D%#x "=0A= + "scsi_status=3D%#x\n", hdr->cmd_status, hdr->scsi_status);=0A= mfi_print_sense(cm->cm_sc, cm->cm_sense);=0A= } else if (cm->cm_error !=3D 0) {=0A= bio->bio_flags |=3D BIO_ERROR;=0A= + bio->bio_error =3D cm->cm_error;=0A= + device_printf(sc->mfi_dev, "I/O error, error=3D%#x\n",=0A= + cm->cm_error);=0A= }=0A= =0A= mfi_release_command(cm);=0A= @@ -2251,6 +2278,9 @@=0A= =0A= /* Send the command to the controller */=0A= if (mfi_mapcmd(sc, cm) !=3D 0) {=0A= + device_printf(sc->mfi_dev, "Failed to startio\n");=0A= + if ((cm->cm_flags & MFI_ON_MFIQ_BUSY) !=3D 0)=0A= + mfi_remove_busy(cm);=0A= mfi_requeue_ready(cm);=0A= break;=0A= }=0A= @@ -2374,7 +2404,7 @@=0A= cm->cm_extra_frames =3D (cm->cm_total_frame_size - 1) / MFI_FRAME_SIZE;=0A= =0A= if (sc->MFA_enabled)=0A= - mfi_tbolt_send_frame(sc, cm);=0A= + mfi_tbolt_send_frame(sc, cm);=0A= else=0A= mfi_send_frame(sc, cm);=0A= =0A= @@ -2466,7 +2496,7 @@=0A= {=0A= struct mfi_command *cm;=0A= struct mfi_abort_frame *abort;=0A= - int i =3D 0;=0A= + int i =3D 0, error;=0A= uint32_t context =3D 0;=0A= =0A= mtx_lock(&sc->mfi_io_lock);=0A= @@ -2490,7 +2520,8 @@=0A= cm->cm_data =3D NULL;=0A= cm->cm_flags =3D MFI_CMD_POLLED;=0A= =0A= - mfi_mapcmd(sc, cm);=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= + device_printf(sc->mfi_dev, "failed to abort command\n");=0A= mfi_release_command(cm);=0A= =0A= mtx_unlock(&sc->mfi_io_lock);=0A= @@ -2506,7 +2537,7 @@=0A= mtx_unlock(&sc->mfi_io_lock);=0A= }=0A= =0A= - return (0);=0A= + return (error);=0A= }=0A= =0A= int=0A= @@ -2544,7 +2575,8 @@=0A= cm->cm_total_frame_size =3D MFI_IO_FRAME_SIZE;=0A= cm->cm_flags =3D MFI_CMD_POLLED | MFI_CMD_DATAOUT;=0A= =0A= - error =3D mfi_mapcmd(sc, cm);=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= + device_printf(sc->mfi_dev, "failed dump blocks\n");=0A= bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap,=0A= BUS_DMASYNC_POSTWRITE);=0A= bus_dmamap_unload(sc->mfi_buffer_dmat, cm->cm_dmamap);=0A= @@ -2587,7 +2619,8 @@=0A= cm->cm_total_frame_size =3D MFI_PASS_FRAME_SIZE;=0A= cm->cm_flags =3D MFI_CMD_POLLED | MFI_CMD_DATAOUT | MFI_CMD_SCSI;=0A= =0A= - error =3D mfi_mapcmd(sc, cm);=0A= + if ((error =3D mfi_mapcmd(sc, cm)) !=3D 0)=0A= + device_printf(sc->mfi_dev, "failed dump blocks\n");=0A= bus_dmamap_sync(sc->mfi_buffer_dmat, cm->cm_dmamap,=0A= BUS_DMASYNC_POSTWRITE);=0A= bus_dmamap_unload(sc->mfi_buffer_dmat, cm->cm_dmamap);=0A= @@ -3632,7 +3665,7 @@=0A= deadline =3D time_uptime - mfi_cmd_timeout;=0A= mtx_lock(&sc->mfi_io_lock);=0A= TAILQ_FOREACH(cm, &sc->mfi_busy, cm_link) {=0A= - if (cm->cm_timestamp < deadline) {=0A= + if (cm->cm_timestamp <=3D deadline) {=0A= device_printf(sc->mfi_dev,=0A= "COMMAND %p TIMEOUT AFTER %d SECONDS\n",=0A= cm, (int)(time_uptime - cm->cm_timestamp));=0A= @@ -3643,7 +3676,7 @@=0A= =0A= #if 0=0A= if (timedout)=0A= - MFI_DUMP_CMDS(SC);=0A= + MFI_DUMP_CMDS(sc);=0A= #endif=0A= =0A= mtx_unlock(&sc->mfi_io_lock);=0A= @@ -3656,7 +3689,7 @@=0A= mfi_timeout(void *data)=0A= {=0A= struct mfi_softc *sc =3D (struct mfi_softc *)data;=0A= - struct mfi_command *cm;=0A= + struct mfi_command *cm, *tmp;=0A= time_t deadline;=0A= int timedout =3D 0;=0A= =0A= @@ -3669,10 +3702,10 @@=0A= }=0A= }=0A= mtx_lock(&sc->mfi_io_lock);=0A= - TAILQ_FOREACH(cm, &sc->mfi_busy, cm_link) {=0A= + TAILQ_FOREACH_SAFE(cm, &sc->mfi_busy, cm_link, tmp) {=0A= if (sc->mfi_aen_cm =3D=3D cm || sc->mfi_map_sync_cm =3D=3D cm)=0A= continue;=0A= - if (cm->cm_timestamp < deadline) {=0A= + if (cm->cm_timestamp <=3D deadline) {=0A= if (sc->adpreset !=3D 0 && sc->issuepend_done =3D=3D 0) {=0A= cm->cm_timestamp =3D time_uptime;=0A= } else {=0A= @@ -3682,6 +3715,13 @@=0A= );=0A= MFI_PRINT_CMD(cm);=0A= MFI_VALIDATE_CMD(sc, cm);=0A= + /*=0A= + * Fail the command instead of leaving it on=0A= + * the queue where it could remain stuck forever=0A= + */=0A= + mfi_remove_busy(cm);=0A= + cm->cm_error =3D ETIMEDOUT;=0A= + mfi_complete(sc, cm);=0A= timedout++;=0A= }=0A= }=0A= @@ -3689,7 +3729,7 @@=0A= =0A= #if 0=0A= if (timedout)=0A= - MFI_DUMP_CMDS(SC);=0A= + MFI_DUMP_CMDS(sc);=0A= #endif=0A= =0A= mtx_unlock(&sc->mfi_io_lock);=0A= --- sys/dev/mfi/mfi_tbolt.c.orig 2012-11-07 23:00:24.542124476 +0000=0A= +++ sys/dev/mfi/mfi_tbolt.c 2012-11-09 14:16:13.036767564 +0000=0A= @@ -162,14 +162,14 @@=0A= while (!( HostDiag & DIAG_WRITE_ENABLE)) {=0A= for (i =3D 0; i < 1000; i++);=0A= HostDiag =3D (uint32_t)MFI_READ4(sc, MFI_HDR);=0A= - device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%x, "=0A= - "hostdiag=3D%x\n", retry, HostDiag);=0A= + device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%d, "=0A= + "hostdiag=3D%#x\n", retry, HostDiag);=0A= =0A= if (retry++ >=3D 100)=0A= return 1;=0A= }=0A= =0A= - device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: HostDiag=3D%x\n", = HostDiag);=0A= + device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: HostDiag=3D%#x\n", = HostDiag);=0A= =0A= MFI_WRITE4(sc, MFI_HDR, (HostDiag | DIAG_RESET_ADAPTER));=0A= =0A= @@ -181,8 +181,8 @@=0A= while (HostDiag & DIAG_RESET_ADAPTER) {=0A= for (i =3D 0; i < 1000; i++) ;=0A= HostDiag =3D (uint32_t)MFI_READ4(sc, MFI_RSR);=0A= - device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%x, "=0A= - "hostdiag=3D%x\n", retry, HostDiag);=0A= + device_printf(sc->mfi_dev, "ADP_RESET_TBOLT: retry time=3D%d, "=0A= + "hostdiag=3D%#x\n", retry, HostDiag);=0A= =0A= if (retry++ >=3D 1000)=0A= return 1;=0A= @@ -447,13 +447,21 @@=0A= sc->request_desc_pool =3D malloc(sizeof(=0A= union mfi_mpi2_request_descriptor) * sc->mfi_max_fw_cmds,=0A= M_MFIBUF, M_NOWAIT|M_ZERO);=0A= +=0A= + if (sc->request_desc_pool =3D=3D NULL) {=0A= + device_printf(sc->mfi_dev, "Could not alloc "=0A= + "memory for request_desc_pool\n");=0A= + return (ENOMEM);=0A= + }=0A= +=0A= sc->mfi_cmd_pool_tbolt =3D malloc(sizeof(struct mfi_cmd_tbolt*)=0A= * sc->mfi_max_fw_cmds, M_MFIBUF, M_NOWAIT|M_ZERO);=0A= =0A= - if (!sc->mfi_cmd_pool_tbolt) {=0A= - device_printf(sc->mfi_dev, "out of memory. Could not alloc "=0A= - "memory for cmd_list_fusion\n");=0A= - return 1;=0A= + if (sc->mfi_cmd_pool_tbolt =3D=3D NULL) {=0A= + free(sc->request_desc_pool, M_MFIBUF);=0A= + device_printf(sc->mfi_dev, "Could not alloc "=0A= + "memory for cmd_pool_tbolt\n");=0A= + return (ENOMEM);=0A= }=0A= =0A= for (i =3D 0; i < sc->mfi_max_fw_cmds; i++) {=0A= @@ -461,20 +469,24 @@=0A= struct mfi_cmd_tbolt),M_MFIBUF, M_NOWAIT|M_ZERO);=0A= =0A= if (!sc->mfi_cmd_pool_tbolt[i]) {=0A= - device_printf(sc->mfi_dev, "Could not alloc cmd list "=0A= - "fusion\n");=0A= + device_printf(sc->mfi_dev, "Could not alloc "=0A= + "cmd_pool_tbolt entry\n");=0A= =0A= for (j =3D 0; j < i; j++)=0A= free(sc->mfi_cmd_pool_tbolt[j], M_MFIBUF);=0A= =0A= + free(sc->request_desc_pool, M_MFIBUF);=0A= + sc->request_desc_pool =3D NULL;=0A= free(sc->mfi_cmd_pool_tbolt, M_MFIBUF);=0A= sc->mfi_cmd_pool_tbolt =3D NULL;=0A= +=0A= + return (ENOMEM);=0A= }=0A= }=0A= =0A= /*=0A= * The first 256 bytes (SMID 0) is not used. Don't add to the cmd=0A= - *list=0A= + * list=0A= */=0A= io_req_base =3D sc->request_message_pool_align=0A= + MEGASAS_THUNDERBOLT_NEW_MSG_SIZE;=0A= @@ -614,9 +626,16 @@=0A= static inline void=0A= mfi_tbolt_return_cmd(struct mfi_softc *sc, struct mfi_cmd_tbolt *cmd)=0A= {=0A= +/* TODO: remove this debugging */=0A= +struct mfi_cmd_tbolt *tbolt_cmd;=0A= mtx_assert(&sc->mfi_io_lock, MA_OWNED);=0A= =0A= cmd->sync_cmd_idx =3D sc->mfi_max_fw_cmds;=0A= +/* TODO: remove this debugging */=0A= +TAILQ_FOREACH(tbolt_cmd, &sc->mfi_cmd_tbolt_tqh, next) {=0A= + if (tbolt_cmd =3D=3D cmd)=0A= + panic("returning tbolt cmd=3D%p thats already present", cmd);=0A= +}=0A= TAILQ_INSERT_TAIL(&sc->mfi_cmd_tbolt_tqh, cmd, next);=0A= }=0A= =0A= @@ -652,13 +671,19 @@=0A= /* Read Reply descriptor */=0A= while ((val.u.low !=3D 0xFFFFFFFF) && (val.u.high !=3D 0xFFFFFFFF)) {=0A= smid =3D reply_desc->SMID;=0A= - if (!smid || smid > sc->mfi_max_fw_cmds + 1) {=0A= - device_printf(sc->mfi_dev, "smid is %x. Cannot "=0A= + if (!smid || smid > sc->mfi_max_fw_cmds) {=0A= + device_printf(sc->mfi_dev, "smid is %d. Cannot "=0A= "proceed. Returning \n", smid);=0A= return;=0A= }=0A= =0A= cmd_tbolt =3D sc->mfi_cmd_pool_tbolt[smid - 1];=0A= + if (cmd_tbolt->sync_cmd_idx =3D=3D sc->mfi_max_fw_cmds) {=0A= + device_printf(sc->mfi_dev, "cmd_tbolt %p "=0A= + "has invalid sync_cmd_idx=3D%d - returning\n",=0A= + cmd_tbolt, cmd_tbolt->sync_cmd_idx);=0A= + return;=0A= + }=0A= cmd_mfi =3D &sc->mfi_commands[cmd_tbolt->sync_cmd_idx];=0A= scsi_io_req =3D cmd_tbolt->io_request;=0A= =0A= @@ -666,10 +691,9 @@=0A= extStatus =3D cmd_mfi->cm_frame->dcmd.header.scsi_status;=0A= map_tbolt_cmd_status(cmd_mfi, status, extStatus);=0A= =0A= - if (cmd_mfi->cm_flags & MFI_CMD_SCSI &&=0A= + if ((cmd_mfi->cm_flags & MFI_CMD_SCSI) !=3D 0 &&=0A= (cmd_mfi->cm_flags & MFI_CMD_POLLED) !=3D 0) {=0A= /* polled LD/SYSPD IO command */=0A= - mfi_tbolt_return_cmd(sc, cmd_tbolt);=0A= /* XXX mark okay for now DJA */=0A= cmd_mfi->cm_frame->header.cmd_status =3D MFI_STAT_OK;=0A= } else {=0A= @@ -684,8 +708,8 @@=0A= =0A= /* complete the command */=0A= mfi_complete(sc, cmd_mfi);=0A= - mfi_tbolt_return_cmd(sc, cmd_tbolt);=0A= }=0A= + mfi_tbolt_return_cmd(sc, cmd_tbolt);=0A= =0A= sc->last_reply_idx++;=0A= if (sc->last_reply_idx >=3D sc->mfi_max_fw_cmds) {=0A= @@ -734,7 +758,8 @@=0A= =0A= mtx_assert(&sc->mfi_io_lock, MA_OWNED);=0A= =0A= - cmd =3D TAILQ_FIRST(&sc->mfi_cmd_tbolt_tqh);=0A= + if ((cmd =3D TAILQ_FIRST(&sc->mfi_cmd_tbolt_tqh)) =3D=3D NULL)=0A= + return NULL;=0A= TAILQ_REMOVE(&sc->mfi_cmd_tbolt_tqh, cmd, next);=0A= memset((uint8_t *)cmd->sg_frame, 0, MEGASAS_MAX_SZ_CHAIN_FRAME);=0A= memset((uint8_t *)cmd->io_request, 0,=0A= @@ -988,8 +1013,10 @@=0A= =0A= index =3D cmd->index;=0A= req_desc =3D mfi_tbolt_get_request_descriptor(sc, index-1);=0A= - if (mfi_tbolt_build_io(sc, mfi_cmd, cmd))=0A= + if (mfi_tbolt_build_io(sc, mfi_cmd, cmd) !=3D 0) {=0A= + mfi_tbolt_return_cmd(sc, cmd);=0A= return NULL;=0A= + }=0A= req_desc->header.SMID =3D index;=0A= return req_desc;=0A= }=0A= @@ -1119,9 +1146,9 @@=0A= * should be performed on the controller=0A= */=0A= if (cm->retry_for_fw_reset =3D=3D 3) {=0A= - device_printf(sc->mfi_dev, "megaraid_sas: command %d "=0A= - "was tried multiple times during adapter reset"=0A= - "Shutting down the HBA\n", cm->cm_index);=0A= + device_printf(sc->mfi_dev, "megaraid_sas: command %p "=0A= + "index=3D%d was tried multiple times during adapter "=0A= + "reset - Shutting down the HBA\n", cm, cm->cm_index);=0A= mfi_kill_hba(sc);=0A= sc->hw_crit_error =3D 1;=0A= return;=0A= @@ -1130,15 +1157,14 @@=0A= if ((cm->cm_flags & MFI_ON_MFIQ_BUSY) !=3D 0) {=0A= struct mfi_cmd_tbolt *cmd;=0A= mfi_remove_busy(cm);=0A= - cmd =3D sc->mfi_cmd_pool_tbolt[cm->cm_extra_frames -=0A= - 1 ];=0A= + cmd =3D sc->mfi_cmd_pool_tbolt[cm->cm_extra_frames - 1];=0A= mfi_tbolt_return_cmd(sc, cmd);=0A= if ((cm->cm_flags & MFI_ON_MFIQ_MASK) =3D=3D 0) {=0A= if (cm->cm_frame->dcmd.opcode !=3D=0A= MFI_DCMD_CTRL_EVENT_WAIT) {=0A= device_printf(sc->mfi_dev,=0A= - "APJ ****requeue command %d \n",=0A= - cm->cm_index);=0A= + "APJ ****requeue command %p "=0A= + "index=3D%d\n", cm, cm->cm_index);=0A= mfi_requeue_ready(cm);=0A= }=0A= }=0A= @@ -1196,22 +1222,22 @@=0A= }=0A= mtx_unlock(&sc->mfi_io_lock);=0A= if ((error =3D mfi_tbolt_init_MFI_queue(sc)) !=3D 0)=0A= - return;=0A= + return;=0A= =0A= mtx_lock(&sc->mfi_io_lock);=0A= =0A= sc->mfi_enable_intr(sc);=0A= sc->adpreset =3D 0;=0A= - free(sc->mfi_aen_cm->cm_data, M_MFIBUF);=0A= - mfi_remove_busy(sc->mfi_aen_cm);=0A= - cmd =3D sc->mfi_cmd_pool_tbolt[sc->mfi_aen_cm->cm_extra_frames=0A= - - 1];=0A= - mfi_tbolt_return_cmd(sc, cmd);=0A= - if (sc->mfi_aen_cm) {=0A= + if (sc->mfi_aen_cm !=3D NULL) {=0A= + free(sc->mfi_aen_cm->cm_data, M_MFIBUF);=0A= + mfi_remove_busy(sc->mfi_aen_cm);=0A= + cmd =3D sc->mfi_cmd_pool_tbolt[=0A= + sc->mfi_aen_cm->cm_extra_frames - 1];=0A= + mfi_tbolt_return_cmd(sc, cmd);=0A= mfi_release_command(sc->mfi_aen_cm);=0A= sc->mfi_aen_cm =3D NULL;=0A= }=0A= - if (sc->mfi_map_sync_cm) {=0A= + if (sc->mfi_map_sync_cm !=3D NULL) {=0A= mfi_release_command(sc->mfi_map_sync_cm);=0A= sc->mfi_map_sync_cm =3D NULL;=0A= }=0A= @@ -1357,6 +1383,8 @@=0A= device_printf(sc->mfi_dev, "failed to send map sync\n");=0A= free(ld_sync, M_MFIBUF);=0A= sc->mfi_map_sync_cm =3D NULL;=0A= + if ((cmd->cm_flags & MFI_ON_MFIQ_BUSY) !=3D 0)=0A= + mfi_remove_busy(cmd);=0A= mfi_requeue_ready(cmd);=0A= goto out;=0A= }=0A= --- sys/dev/mfi/mfi_debug.c.orig 2012-11-09 00:56:43.485019300 +0000=0A= +++ sys/dev/mfi/mfi_debug.c 2012-11-09 02:24:35.569778892 +0000=0A= @@ -271,7 +271,7 @@=0A= {=0A= int i;=0A= =0A= - for (i =3D 0; i < sc->mfi_total_cmds; i++)=0A= + for (i =3D 0; i < sc->mfi_max_fw_cmds; i++)=0A= mfi_print_generic_frame(sc, &sc->mfi_commands[i]);=0A= }=0A= =0A= --- sys/dev/mfi/mfivar.h.orig 2012-11-09 00:55:55.000000000 +0000=0A= +++ sys/dev/mfi/mfivar.h 2012-11-09 14:36:01.203796033 +0000=0A= @@ -267,10 +267,6 @@=0A= */=0A= struct mfi_command *mfi_commands;=0A= /*=0A= - * How many commands were actually allocated=0A= - */=0A= - int mfi_total_cmds;=0A= - /*=0A= * How many commands the firmware can handle. Also how big the reply=0A= * queue is, minus 1.=0A= */=0A= ------=_NextPart_000_0276_01CDBE9C.80113780-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 17:25:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CD5A274; Fri, 9 Nov 2012 17:25:09 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1918FC0A; Fri, 9 Nov 2012 17:25:08 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 09 Nov 2012 09:26:27 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id qA9HP8eY013825; Fri, 9 Nov 2012 09:25:08 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id qA9HP8oW013824; Fri, 9 Nov 2012 09:25:08 -0800 (PST) (envelope-from ambrisko) Date: Fri, 9 Nov 2012 09:25:08 -0800 From: Doug Ambrisko To: Steven Hartland Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock Message-ID: <20121109172508.GA13333@ambrisko.com> References: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> <39D16C43C8274CE9B8F23C18459E2FD4@multiplay.co.uk> <20121105212911.GA17904@ambrisko.com> <27169C7FE704495087A093752D15E7B6@multiplay.co.uk> <20121106180152.GA40422@ambrisko.com> <6B5B65F4FC854EB8BBC701500096602E@multiplay.co.uk> <0B4E8AFF9DA04C6EBD2496A8B58F1D67@multiplay.co.uk> 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-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:25:09 -0000 On Fri, Nov 09, 2012 at 05:06:03PM -0000, Steven Hartland wrote: | | ----- Original Message ----- | From: "Steven Hartland" | ... | >I've just had another panic, trace below, but it doesn't seem to be related | >to my changes so I'd appreciate your feedback on them as they are for now. | > | >While the lock patch fixes the problems I've seen, its not clear to me | >why mfi_tbolt_reset is acquiring the lock and hence requiring | >mfi_process_fw_state_chg_isr to jump through hoops to ensure locking | >around queue manipulation is done correctly. Given what its doing | >(resetting the entire adapter) I wouldn't be surprised if it should | >really be acquiring the config lock. | > | >Other things I've noticed / questions | >* Should mfi_abort sleep even if its call to mfi_mapcmd fails? | >* Should mfi_get_controller_info really ignore the error from mfi_mapcmd? | >* Do these controllers not support none 512 byte requests? Currently | >all syspd requests are done assuming 512 byte sectors which the disk may | >not be. This will both reduce performance or potentially break totally | >if the firmware isn't translating it under the surface correctly. | > | >Anyway the new panic manually transcribed is:- | >panic: Bad linx elm 0xffffff0069b0fc0 next->prev != elm | >... | >mfi_tbolt_get_cmd() | >mfi_build_mpt_pass_thru() | >mfi_tbolt_build_mpt_cmd() | >mfi_tbolt_send_frame() | >bus_dmamap_load() | >mfi_mapcmd() | >mfi_startio() | >mfi_syspd_strategy() | >g_disk_start() | >g_io_schedule_down() | >g_down_proc_body() | >fork_exit() | >fork_trampoline() | > | >Looks like mfi_cmd_tbolt_tqh has become corrupt some how, but as far as I | >can tell all manip is done using the TAILQ macros and under mfi_io_lock | >so its not obvious to me at this time why this is, any ideas? | | I've gone through looking for the possible cause of this and while there's | nothing directly connected to the manip of this queue I've found and fixed | quite a large number of additional problems which may have been indirectly | causing this problem. | | The biggest change is to use mfi_max_cmds to limit the value stored in | sc->mfi_max_fw_cmds as this is used extensively throughout the driver | for allocation and range checks so having this inconsitently set opened up | a large number of possible overrun errors. | | The new patch attached documents all the changes in detail. | | I've managed to do one test run so far which failed to reproduce any panics, | so definitely moving in the right direction :) | | The machine has now been collected for repair by the supplier but I'm going | to try and get them to put it online for more testing over the weekend. | | Given the failure rate so far if I can do another 4 runs with no panics I'd | be happy that the majority of error conditions are working as expected. Sounds like you have made some good progress. I looked at your prior locking change and they good. Haven't had time to go through the queue changes yet. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 19:23:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A71873D1; Fri, 9 Nov 2012 19:23:55 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0159E8FC08; Fri, 9 Nov 2012 19:23:54 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jm19so748990bkc.13 for ; Fri, 09 Nov 2012 11:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bsSSdMLKEABrOEdzBimJNP9gTbqlYmwaMwYhCnPHnwk=; b=faN3fSm41lqv/gcfBNXnRZq2dNT8jjS5NaShO+9SX4hciJn1t/V4HHm7oZQh9Ekacv ugSx/5rBOMNGObbFs2QRY2GFMyZ6OwZ29E/Laq5FniR7QFvEXzu2V+qfu6uuNyWj6/JN xtUzwZ7Ut5/Iv7yMyU9h1atn1quDSAMLliASnYx3/zAoePa20hYCdbPy32o7JWnmrSJO KE/VGuYLyPB4zLkyJ0A/isZVnFy+7qbYB4TLPCL3sYwCKzvh/bIXr/fAQ9R8MHbRhzPY /4vvop+phRbJsDePSfRBw4bGfkzOTZ2LFDeN9YOVPD0hLkeDJJ2EdDj31kndQ2TnGgm4 ZP2Q== MIME-Version: 1.0 Received: by 10.204.9.3 with SMTP id j3mr4238010bkj.15.1352489033894; Fri, 09 Nov 2012 11:23:53 -0800 (PST) Sender: jamebus@gmail.com Received: by 10.204.0.77 with HTTP; Fri, 9 Nov 2012 11:23:53 -0800 (PST) In-Reply-To: <5097D27E.1050705@FreeBSD.org> References: <5097A5E0.2000502@gmail.com> <5097D27E.1050705@FreeBSD.org> Date: Fri, 9 Nov 2012 13:23:53 -0600 X-Google-Sender-Auth: 4LYJWKen_sCJeM6FOAWs2IlMjd4 Message-ID: Subject: Re: buildworld fails on recent stable From: James To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:23:55 -0000 Thanks Dimitry. Confirmed successful build here, too. -- James. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 21:23:38 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4ABDB14 for ; Fri, 9 Nov 2012 21:23:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7385E8FC12 for ; Fri, 9 Nov 2012 21:23:38 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c50so3102794eek.13 for ; Fri, 09 Nov 2012 13:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DvfFkhAZ+GpO3479R1mrPpb/nFt60XnzgSwuZuHesIE=; b=0bmfikHM5c2+4NzIlg4SKKbNi9BwVWWVtAdg7YbfPRT97DI5dCNowknRPLUBuJQE8b Y/jCR0830/Z0RmkrsvFJeIDlUM2dEKJwZPzJ1ccamfQ2BHTw44oW2vJsyx2dYyoSgdTD 8PkOnSBqWKvpYwquPww9SVqH0Dx/MOePUtKP7r7uhKzCPSlkxTR64B7YuJ/qqAJLQBoL MB5sgLGXvn1uFcct053jV/8xV6/mABh878XPMEIQHDMkn/ezWZCLbkk3FFjbE+cMh0ja tzYXCsVTBSN74xdM6ExX0SUAVNxLiFXPJfjHFz7dIQyhZDwMZI9kx3i0QDj3HbGsTb+p KejQ== MIME-Version: 1.0 Received: by 10.14.220.71 with SMTP id n47mr40799896eep.26.1352496217357; Fri, 09 Nov 2012 13:23:37 -0800 (PST) Received: by 10.223.66.194 with HTTP; Fri, 9 Nov 2012 13:23:37 -0800 (PST) In-Reply-To: <509CED3E.8090103@bnrlabs.com> References: <20121109111843.GA25461@tunchi> <509CED3E.8090103@bnrlabs.com> Date: Fri, 9 Nov 2012 13:23:37 -0800 Message-ID: Subject: Re: smartctl question From: Kevin Oberman To: "Lucas B. Cohen" Content-Type: text/plain; charset=UTF-8 Cc: "H. Ingow" , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:23:39 -0000 On Fri, Nov 9, 2012 at 3:47 AM, Lucas B. Cohen wrote: > Hi, > > On 2012.11.09 12:18, H. Ingow wrote: >> >> Hi all, >> >> one single disk in a zfs mirror failed permanently throwing errors like >> kernel: (ada5:ata10:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 84 >> (ICRC ABRT ) and alike. >> >> The pool itself continued working degraded, smartctl showed a very high >> 199 UDMA_CRC_Error_Count value, which to my knowledge may indicate a >> broken cable, in this case indeed a cable replacement solved the >> problem, the pool resilvered and all is fine. >> >> Still smartctl -a displays a value of 199 UDMA_CRC_Error_Count I reckon >> to be way too high, though ( > 3900 ) . >> So is this value now including errors from previous broken cable ? > > I'm pretty sure it is. I don't think SMART attributes can vary in value > both up and down ; they seem to me like they're counters that can only > get incremented. > >> In other words, when, if at all, is the cache smartmontools read from >> flushed and values are to be taken as of the status after fixing a >> hardware problem but not swapping the disk ? > So, in my opinion no. This is a problem with S.M.A.R.T. All stats are stored by the drive in the drive and the assumption is that all of the errors are caused by problems in the drive (and usually are). But when they are from a cable problem, the drive never sees the problem as "gone", so the counters never reset. As long as you remember that you had a cable problem with that drive and that the count was 199, you can discount it or recognize a problem down the road if it starts increasing. I'd put it on a label that can be stuck to the drive as a last reminder that the count is "off by 199". By the way, I believe that some stats do go up and down, but not counters. Like in snmp, counters are never supposed to be reset or resettable. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 21:28:47 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96374C64 for ; Fri, 9 Nov 2012 21:28:47 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 524568FC0C for ; Fri, 9 Nov 2012 21:28:46 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TWw87-000Ho0-5O; Fri, 09 Nov 2012 22:28:47 +0100 Date: Fri, 9 Nov 2012 22:28:47 +0100 From: Kurt Jaeger To: "H. Ingow" Subject: Re: smartctl question Message-ID: <20121109212847.GN12114@home.opsec.eu> References: <20121109111843.GA25461@tunchi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121109111843.GA25461@tunchi> Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:28:47 -0000 Hi! > Still smartctl -a displays a value of 199 UDMA_CRC_Error_Count I reckon > to be way too high, though ( > 3900 ) . > So is this value now including errors from previous broken cable ? > In other words, when, if at all, is the cache smartmontools read from > flushed and values are to be taken as of the status after fixing a > hardware problem but not swapping the disk ? SMART values are stored in the drive, not on some cache in the system. The bad cable caused the drive to see errors. There is no way to reset the counters in the drive. So the error counter will stay at that value, but as long as it does no longer increase, you're fine. -- pi@opsec.eu +49 171 3101372 8 years to go ! From owner-freebsd-stable@FreeBSD.ORG Fri Nov 9 23:15:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E188996 for ; Fri, 9 Nov 2012 23:15:05 +0000 (UTC) (envelope-from bmah@kitchenlab.org) Received: from kaga.kitchenlab.org (unknown [IPv6:2001:470:1f04:55c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C95B8FC0A for ; Fri, 9 Nov 2012 23:15:05 +0000 (UTC) Received: from morimoto.int.kitchenlab.org (c-67-188-254-192.hsd1.ca.comcast.net [67.188.254.192]) (authenticated bits=0) by kaga.kitchenlab.org (8.14.5/8.14.5) with ESMTP id qA9NEvWb008583 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 15:14:57 -0800 (PST) (envelope-from bmah@kitchenlab.org) Message-ID: <509D8E6F.7020800@kitchenlab.org> Date: Fri, 09 Nov 2012 15:14:55 -0800 From: "Bruce A. Mah" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: smartctl question References: <20121109111843.GA25461@tunchi> <509CED3E.8090103@bnrlabs.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5F57EE29CD8C30A1FEA8FA02" X-Virus-Scanned: clamav-milter 0.97.6 at kaga.kitchenlab.org X-Virus-Status: Clean Cc: "Lucas B. Cohen" , stable@freebsd.org, "H. Ingow" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:15:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5F57EE29CD8C30A1FEA8FA02 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Kevin Oberman wrote: > By the way, I believe that some stats do go up and down, but not > counters. Like in snmp, counters are never supposed to be reset or > resettable. Examples of values that go up and down (actually the only examples I can think of) are the drive temperature and airflow temperature. But AFAIK you're right about the counter values. Bruce. --------------enig5F57EE29CD8C30A1FEA8FA02 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCdjm8ACgkQ2MoxcVugUsOrvQCg7c1WRyW5IpW1mbI6xeqeIbHB 0YIAoLhuVmOYINehcbx5IYfYpIdNvGSi =JEQ6 -----END PGP SIGNATURE----- --------------enig5F57EE29CD8C30A1FEA8FA02--