From owner-freebsd-stable@FreeBSD.ORG Sun Apr 1 10:08:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19442106566C for ; Sun, 1 Apr 2012 10:08:42 +0000 (UTC) (envelope-from prvs=043805a212=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 96B0A8FC08 for ; Sun, 1 Apr 2012 10:08:41 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SEHiC-000Jzl-0R for freebsd-stable@freebsd.org; Sun, 01 Apr 2012 12:08:40 +0200 Date: Sun, 1 Apr 2012 12:08:39 +0200 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20120401100839.GH65313@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20120330083830.GB65313@e-Gitt.NET> <4F761F4B.90409@p6m7g8.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <4F761F4B.90409@p6m7g8.com> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2012 10:08:42 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Mar 30, 2012 at 09:02:03PM +0000, Philip M. Gollucci wrote: > http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.ht= ml >=20 > Same issue different thread. Different software. >=20 > Its not NFS, its ZFS. >=20 > I don't really have a place to try it on 8.2, but my hunch from things > I've done rather similarly which don't cause tell me its a new issue in > 9.0, though I won't swear by that. I'll see, if I can setup a machine running 8 to take some of the=20 partitions over - but chances aren't really great. Thanx for the hint to=20 you thread. Also I'll start graphing (or at least logging) some of the higher values=20 =66rom vmstat that seems suspicious and ever growing to me to see if I can= =20 match one of them to the growth rate I see for mir wired mem apart from=20 ARC and L2ARC headers. - Oliver --=20 | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk94KScACgkQiqtMdzjafylVpgCfZXOUhUGYZJ2AueZRNr1HTJ5l 1H8AoJu3BW/il+ai8gFX3Z3CwnVYhRh/ =FlpA -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-stable@FreeBSD.ORG Sun Apr 1 19:31:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B091065672 for ; Sun, 1 Apr 2012 19:31:34 +0000 (UTC) (envelope-from prvs=043805a212=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD358FC16 for ; Sun, 1 Apr 2012 19:31:34 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SEQUv-000GgH-HZ for freebsd-stable@freebsd.org; Sun, 01 Apr 2012 21:31:33 +0200 Date: Sun, 1 Apr 2012 21:31:33 +0200 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20120401193133.GI65313@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20120330083830.GB65313@e-Gitt.NET> <4F761F4B.90409@p6m7g8.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx" Content-Disposition: inline In-Reply-To: <4F761F4B.90409@p6m7g8.com> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2012 19:31:34 -0000 --E39vaYmALEf/7YXx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Mar 30, 2012 at 09:02:03PM +0000, Philip M. Gollucci wrote: > http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.ht= ml >=20 > Same issue different thread. Different software. >=20 > Its not NFS, its ZFS. >=20 > I don't really have a place to try it on 8.2, but my hunch from things > I've done rather similarly which don't cause tell me its a new issue in > 9.0, though I won't swear by that. Just digging around I find one value ever-growing in vmstat -z and being=20 by far the biggest "USED" value: virgin# while ( 1 ) while? echo -n `date`: ; vmstat -z | fgrep NAMEI | sed 's/ */ /g' while? sleep 10 while? end Sun Apr 1 21:26:33 CEST 2012:NAMEI: 1024, 0, 9150656, 1152,288542469, 0, 0 Sun Apr 1 21:26:43 CEST 2012:NAMEI: 1024, 0, 9150877, 1187,288546408, 0, 0 Sun Apr 1 21:26:53 CEST 2012:NAMEI: 1024, 0, 9150966, 1226,288549358, 0, 0 Sun Apr 1 21:27:03 CEST 2012:NAMEI: 1024, 0, 9151079, 1241,288551944, 0, 0 Sun Apr 1 21:27:13 CEST 2012:NAMEI: 1024, 0, 9151264, 1184,288555091, 0, 0 Sun Apr 1 21:27:23 CEST 2012:NAMEI: 1024, 0, 9151338, 1238,288557632, 0, 0 Sun Apr 1 21:27:33 CEST 2012:NAMEI: 1024, 0, 9151488, 1344,288560345, 0, 0 Sun Apr 1 21:27:43 CEST 2012:NAMEI: 1024, 0, 9151610, 1350,288563532, 0, 0 Sun Apr 1 21:27:53 CEST 2012:NAMEI: 1024, 0, 9151765, 1451,288567086, 0, 0 Sun Apr 1 21:28:03 CEST 2012:NAMEI: 1024, 0, 9151935, 1409,288570645, 0, 0 Sun Apr 1 21:28:13 CEST 2012:NAMEI: 1024, 0, 9152086, 1258,288573371, 0, 0 Sun Apr 1 21:28:23 CEST 2012:NAMEI: 1024, 0, 9152244, 1100,288576862, 0, 0 Sun Apr 1 21:28:33 CEST 2012:NAMEI: 1024, 0, 9152429, 1171,288580235, 0, 0 Sun Apr 1 21:28:43 CEST 2012:NAMEI: 1024, 0, 9152615, 1113,288583356, 0, 0 I'll recheck that in more busy times again. Philip: Are you using: - another file system (like UFS/FFS for the system or similar?) - ZFS snapshots - ZFS send on the system? Can you also see the NAMEI growth? - Oliver --=20 | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | --E39vaYmALEf/7YXx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk94rRUACgkQiqtMdzjafymTRgCfcS1IHVM5WENQyzPXIWNTHGqw 1xAAnjkZqjWzupGieC9V3Eg3Tai6n3yV =bPz9 -----END PGP SIGNATURE----- --E39vaYmALEf/7YXx-- From owner-freebsd-stable@FreeBSD.ORG Sun Apr 1 21:11: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 B4A8F106564A for ; Sun, 1 Apr 2012 21:11:37 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id 69A2B8FC08 for ; Sun, 1 Apr 2012 21:11:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0M1T006YNK6JW710@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Sun, 01 Apr 2012 23:11:07 +0200 (CEST) Received: from kg-v2.kg4.no ([84.215.134.159]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTPA id <0M1T00FE8K6JDB60@terra-smin.broadpark.no> for freebsd-stable@freebsd.org; Sun, 01 Apr 2012 23:11:07 +0200 (CEST) Date: Sun, 01 Apr 2012 23:11:07 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20120401231107.62577f2f.torfinn.ingolfsen@broadpark.no> In-reply-to: <20120324172603.ee066e06.torfinn.ingolfsen@getmail.no> References: <20120324172603.ee066e06.torfinn.ingolfsen@getmail.no> X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD 9.0 - GPT boot problems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2012 21:11:37 -0000 On Sat, 24 Mar 2012 17:26:03 +0100 Torfinn Ingolfsen wrote: > Hi, > I just installed FreeBSD 9.0-release / amd64 on a new machine (Acer Aspire X1470). > I installed from a usb memory stick (the default amd64 image), which I booted by pressing "F12" and selecting it from the boot menu on the machine. > I installed on a SSD (which replaced the hard drive originally in the machine), using the default scheme for 9.0 (GPT). > The installation was painless (many thanks to all who made it that way), but when I try to boot the machine from the SSD afterwards, I just get this message from the BIOS: > "ERROR: No boot disk has been detected or the disk has failed." > I tried selecting the SSD from the boot menu (via F12) instead (it shows up as "EFI: M4-CT128M4SSD2"), but got the same message. > I upgraded the BIOS from version P01-A3 to version P01-A4 (the newest available), still no dice. Just an update: today I connected another disk to the machine (I used a sata-to-usb adapter, but I think that doesn't matter), this disk is MBR-partitioned, and the machine boots from this with no problems using the boot menu (via F12). root@kg-vm2# gpart show -p da1 => 63 117210177 da1 MBR (55G) 63 29350692 da1s1 freebsd (14G) 29350755 29360079 da1s2 freebsd [active] (14G) 58710834 58499406 - free - (27G) The non-working disk looks like this: root@kg-vm2# gpart show -p ada0 => 34 250069613 ada0 GPT (119G) 34 128 ada0p1 freebsd-boot (64k) 162 119537664 ada0p2 freebsd-ufs (57G) 119537826 8388608 ada0p3 freebsd-swap (4.0G) 127926434 121634816 ada0p4 freebsd-ufs (58G) 249561250 508397 - free - (248M) -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sun Apr 1 23:48:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7801F106564A for ; Sun, 1 Apr 2012 23:48:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01F178FC08 for ; Sun, 1 Apr 2012 23:48:33 +0000 (UTC) Received: by wern13 with SMTP id n13so1797733wer.13 for ; Sun, 01 Apr 2012 16:48:32 -0700 (PDT) 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:content-transfer-encoding; bh=Xd4Nkf7/WZJDT4pH/DQbzyZIA0h+gTvPmI37xOHOC5M=; b=N8TogY9NXTMbukCByYJLhqb4y6f6UzcZWFE6GibhBwdTbQdTfnBnKUMmfy0xu8Jt7m By+CU6bOh1PpcRpYxr29qITrJCtwJOFh8X+g1O2r8BaB54+UKIh1Oyi8CEBP+73Ly3Dd kNlsEU2mhyDgVGAU6N/W/ZybKbuku0VvunMegYHK9ILPV2cJd9qULuR4y8khJygumqvE ucRkA/7dcF+0BjlK2Dey5Hp+Zj+c6cfGOPggcPQwI1w6RwncLqykHMENMYaaT2m8zhZl oDVqrTICy46LeUtaAGF9dm8oEuGuqTRiMBfWijX1y00VWoaUE9IzZZTrpC6rRNxOoHox nrBA== MIME-Version: 1.0 Received: by 10.180.107.132 with SMTP id hc4mr18858017wib.21.1333324112373; Sun, 01 Apr 2012 16:48:32 -0700 (PDT) Received: by 10.223.54.207 with HTTP; Sun, 1 Apr 2012 16:48:32 -0700 (PDT) In-Reply-To: <20120401231107.62577f2f.torfinn.ingolfsen@broadpark.no> References: <20120324172603.ee066e06.torfinn.ingolfsen@getmail.no> <20120401231107.62577f2f.torfinn.ingolfsen@broadpark.no> Date: Sun, 1 Apr 2012 16:48:32 -0700 Message-ID: From: Kevin Oberman To: Torfinn Ingolfsen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0 - GPT boot problems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2012 23:48:34 -0000 On Sun, Apr 1, 2012 at 2:11 PM, Torfinn Ingolfsen wrote: > On Sat, 24 Mar 2012 17:26:03 +0100 > Torfinn Ingolfsen wrote: > >> Hi, >> I just installed FreeBSD 9.0-release / amd64 on a new machine (Acer Aspi= re X1470). >> I installed from a usb memory stick (the default amd64 image), which I b= ooted by pressing "F12" and selecting it from the boot menu on the machine. >> I installed on a SSD (which replaced the hard drive originally in the ma= chine), using the default scheme for 9.0 (GPT). >> The installation was painless (many thanks to all who made it that way),= but when I try to boot the machine from the SSD afterwards, I just get thi= s message from the BIOS: >> "ERROR: No boot disk has been detected or the disk has failed." >> I tried selecting the SSD from the boot menu (via F12) instead (it shows= up as "EFI: M4-CT128M4SSD2"), but got the same message. >> I upgraded the BIOS from version P01-A3 to version P01-A4 (the newest av= ailable), still no dice. > > Just an update: > today I connected another disk to the machine (I used a sata-to-usb adapt= er, but I think that doesn't matter), this disk is MBR-partitioned, > and the machine boots from this with no problems using the boot menu (via= F12). > root@kg-vm2# gpart show -p da1 > =3D> =A0 =A0 =A0 63 =A0117210177 =A0 =A0da1 =A0MBR =A0(55G) > =A0 =A0 =A0 =A0 63 =A0 29350692 =A0da1s1 =A0freebsd =A0(14G) > =A0 29350755 =A0 29360079 =A0da1s2 =A0freebsd =A0[active] =A0(14G) > =A0 58710834 =A0 58499406 =A0 =A0 =A0 =A0 - free - =A0(27G) > > The non-working disk looks like this: > root@kg-vm2# gpart show -p ada0 > =3D> =A0 =A0 =A0 34 =A0250069613 =A0 =A0ada0 =A0GPT =A0(119G) > =A0 =A0 =A0 =A0 34 =A0 =A0 =A0 =A0128 =A0ada0p1 =A0freebsd-boot =A0(64k) > =A0 =A0 =A0 =A0162 =A0119537664 =A0ada0p2 =A0freebsd-ufs =A0(57G) > =A0119537826 =A0 =A08388608 =A0ada0p3 =A0freebsd-swap =A0(4.0G) > =A0127926434 =A0121634816 =A0ada0p4 =A0freebsd-ufs =A0(58G) > =A0249561250 =A0 =A0 508397 =A0 =A0 =A0 =A0 =A0- free - =A0(248M) Just for reference, my GPT disk boots fine on my ThinkPad with the followin= g: > gpart show /dev/ada1 =3D> 34 1465149101 ada1 GPT (698G) 34 6 - free - (3.0k) 40 128 1 freebsd-boot (64k) 168 2097152 2 freebsd-ufs (1.0G) 2097320 8388608 3 freebsd-swap (4.0G) 10485928 10217472 4 freebsd-ufs (4.9G) 20703400 1048576 5 freebsd-ufs (512M) 21751976 124539712 6 freebsd-ufs (59G) 146291688 31134928 - free - (14G) 177426616 1287722512 7 freebsd-ufs (614G) 1465149128 7 - free - (3.5k) The disk has native 4K sectors, so the partitions are aligned accordingly. That is why the free chunk at the beginning. the second free chunk is due to my error which I'll get around to adding to p6 some day. I use traditional partitions (root, tmp, var, bin, and home) and the home partition is GELI encrypted. (I I had hardware crypto support, I'd encrypt everything.) The disk does have the protective MBR installed, though it's not really part of the GPT. (See the "GUID Partition Table" article on Wikipedia for more information.) --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 01:38:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4BC7106566B for ; Mon, 2 Apr 2012 01:38:44 +0000 (UTC) (envelope-from pgollucci@taximagic.com) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE698FC08 for ; Mon, 2 Apr 2012 01:38:44 +0000 (UTC) Received: by qafi31 with SMTP id i31so1778345qaf.15 for ; Sun, 01 Apr 2012 18:38:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=YV5PcE31zBTnqqL1Xs6kRleuNuPp30Bd4qBd669sy2U=; b=YBR9ijKFwz6j2kwAiBVGoabrgrRvNXS2ZwFzDpuqWKZwsfpQz69PHmZwlkClWBmaAR raxuzaZj1DynUiFwj5Ucj3JVRn9qVjgOpELjZkjKPxadFP6i47t2I/XdEevRaGbIF+WS eWuzbnmLhwk6PBIBNCvqLa0WYtrI1KvVGhKdlnxGoiOLSKHQM1Gu7OIKoiZ+HXXJjJ8Q QGiTAusllSlnv6Rlhwr3qEEDvU+XoS9ANPz00Evi2JD51QPDWEjDp/+n9x2/v59iaUrj qbGTwOi77wq4xjKoIenHTPKzZLQ41VayfKoLG1Ics6LxQUcipM0EMbc+5yzJ+PyiyEaB 3IZw== Received: by 10.224.31.203 with SMTP id z11mr8924748qac.72.1333330717096; Sun, 01 Apr 2012 18:38:37 -0700 (PDT) Received: from jlhewitt.local (pool-108-28-196-170.washdc.fios.verizon.net. [108.28.196.170]) by mx.google.com with ESMTPS id fo9sm32108090qab.21.2012.04.01.18.38.36 (version=SSLv3 cipher=OTHER); Sun, 01 Apr 2012 18:38:36 -0700 (PDT) Message-ID: <4F79031B.2060706@p6m7g8.com> Date: Sun, 01 Apr 2012 21:38:35 -0400 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20120330083830.GB65313@e-Gitt.NET> <4F761F4B.90409@p6m7g8.com> <20120401193133.GI65313@e-Gitt.NET> In-Reply-To: <20120401193133.GI65313@e-Gitt.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn2wTcBZ2HMYe/y3Mth1PO8qdQ4KTnKkFLzDR7xdkp3B/msd/DZ6xkzRPrqz0a5WrF4j1Hp Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 01:38:44 -0000 On 4/1/12 3:31 PM, Oliver Brandmueller wrote: > Philip: > > Are you using: > > - another file system (like UFS/FFS for the system or similar?) > - ZFS snapshots > - ZFS send > > on the system? > > Can you also see the NAMEI growth? The system is 100% zfs. zmirror for the os (2 disks) zmysqlL(zmirror) for mysql logs (2disks +1 cache(ssd)) zmysqlD(raidz2) for mysql data (11 disks + 1cache(ssd) +1zil(ssd)) No snapshots No zfs send/recv, but there might be in the future. I have not charted NAMEI growth, but I can try it monday I think. -- ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 04:08: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 635C5106566C; Mon, 2 Apr 2012 04:08:42 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmaila.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id EB4C38FC0A; Mon, 2 Apr 2012 04:08:41 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8A386D55C; Sun, 1 Apr 2012 23:58:48 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 00077D509; Sun, 1 Apr 2012 23:58:46 -0400 (EDT) Received: from smtp1.acsu.buffalo.edu (smtp1.acsu.buffalo.edu [128.205.5.253]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id DBD3DD4E4; Sun, 1 Apr 2012 23:58:46 -0400 (EDT) Received: from [192.168.1.101] (cpe-72-231-248-9.buffalo.res.rr.com [72.231.248.9]) (Authenticated sender: kensmith@buffalo.edu) by smtp1.acsu.buffalo.edu (Postfix) with ESMTPSA id 613EC4A5A9; Sun, 1 Apr 2012 23:58:46 -0400 (EDT) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HZ/MTT0eIrfdicCpzq0P" Organization: U. Buffalo Date: Sun, 01 Apr 2012 23:58:39 -0400 Message-ID: <1333339119.14443.14.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 28% Cc: re Subject: 8.3-RC2 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 04:08:42 -0000 --=-HZ/MTT0eIrfdicCpzq0P Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The second Release Candidate build of the 8.3-RELEASE release cycle is now available on the FTP servers for the amd64, i386, pc98, and sparc64 architectures. The MD5/SHA256 sums are at the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.3/ (or any of the FreeBSD mirror sites). What will likely be the package sets for the upcoming release have been placed on the RC2 images. For the disc1 images due to size issues only the English documentation package is available. The memstick images include the documentation packages for all languages but no other packages. The dvd images include all of the documentation packages as well as enough packages to set up a basic graphical workstation. Unless a show-stopper caliber problem is found this will be the last test build of the 8.3-RELEASE cycle. Some nits that came up as part of getting RC2 ready have put us off the original schedule. I just updated the schedule, available here: http://www.freebsd.org/releases/8.3R/schedule.html to reflect a new target date for starting up the release builds of April 9th, 2012. The release announcement itself should be three to four days after the builds start. It will take a little time for the update I just made to go live on the Web site. If you notice any problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you would like to use csup/cvsup mechanisms to do a source-based update of an existing system the branch tag to use is "RELENG_8_3". If you would like to use SVN instead use "releng/8.3". The freebsd-update(8) utility supports binary upgrades of i386 and amd64= =20 systems running earlier FreeBSD releases. Systems running 8.1-RELEASE, 8.2-RELEASE, 8.3-BETA1, or 8.3-RC1 can upgrade as follows: # freebsd-update upgrade -r 8.3-RC2 During this process, FreeBSD Update may ask the user to help by merging=20 some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before=20 continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new= =20 userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 7.x) can also use freebsd-update to upgrade to FreeBSD 8.3-RC1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 7.x and FreeBSD 8.x. Checksums: MD5 (FreeBSD-8.3-RC2-amd64-bootonly.iso) =3D 0f3beb80d02b7563da648e13010ca4= ed MD5 (FreeBSD-8.3-RC2-amd64-disc1.iso) =3D ea9f1333fe0cca74be2a1c4ccbdf85ab MD5 (FreeBSD-8.3-RC2-amd64-dvd1.iso) =3D 793047044545780f09ef3843840a50ec MD5 (FreeBSD-8.3-RC2-amd64-livefs.iso) =3D 2aeef67483a1cca3ae73afb5dde2f622 MD5 (FreeBSD-8.3-RC2-amd64-memstick.img) =3D 376762e238695290c4d350bedaff6f= 12 MD5 (FreeBSD-8.3-RC2-i386-bootonly.iso) =3D 6062f26c0c86b9dee335e3143058bcb= 6 MD5 (FreeBSD-8.3-RC2-i386-disc1.iso) =3D 1104102d16a82d81b7160ed304b7ed08 MD5 (FreeBSD-8.3-RC2-i386-dvd1.iso) =3D eddd1563698af673d387d721c8e52cf3 MD5 (FreeBSD-8.3-RC2-i386-livefs.iso) =3D 4b0187b90132c598db1d40dc9fb1f19d MD5 (FreeBSD-8.3-RC2-i386-memstick.img) =3D 6b1e3eb84b4f02723a6edd361498c2d= 8 MD5 (FreeBSD-8.3-RC2-pc98-bootonly.iso) =3D 272f1e73c988c6a9eb3e3f0f7312894= a MD5 (FreeBSD-8.3-RC2-pc98-disc1.iso) =3D 98f0fd017cc9943d4fcbec1ee02da6a4 MD5 (FreeBSD-8.3-RC2-pc98-livefs.iso) =3D 5ece7196f2534fd20061b6aa0e01cb75 MD5 (FreeBSD-8.3-RC2-sparc64-bootonly.iso) =3D d06e0ea3b549009cb90c8008d9dd= 3e97 MD5 (FreeBSD-8.3-RC2-sparc64-disc1.iso) =3D 7f061b801af2e8636d8640257d5cf15= 9 MD5 (FreeBSD-8.3-RC2-sparc64-dvd1.iso) =3D 539d1a57f47ab026eaa489e80a11a7db MD5 (FreeBSD-8.3-RC2-sparc64-livefs.iso) =3D cbd09419d8fd9634c3675456ee2ba7= b1 SHA256 (FreeBSD-8.3-RC2-amd64-bootonly.iso) =3D 365491958c16c4773b476a54ab4= 560fea42bb0ba3c195cb4c8cde444e1c3510a SHA256 (FreeBSD-8.3-RC2-amd64-disc1.iso) =3D 0c2024e6de19ddf783272e191f41c5= 0f212b44f83f87354e8e93dc5545d10e09 SHA256 (FreeBSD-8.3-RC2-amd64-dvd1.iso) =3D d5987dfe8c7bf14c0f1205ce5fd03a0= 2a158230fed8897606db36e2cadc7cc8b SHA256 (FreeBSD-8.3-RC2-amd64-livefs.iso) =3D 130803fadeae3ce2212519784969c= 694bdd7cb79a5b979ecc8e1680a8ac04e33 SHA256 (FreeBSD-8.3-RC2-amd64-memstick.img) =3D e7a23258f23ce40a9aaf801cb70= 6333cb0954720c389082841c55f136054e392 SHA256 (FreeBSD-8.3-RC2-i386-bootonly.iso) =3D 87994fa3ff1547eecb90cb4ac2ce= 9b80e127dde3b552ba2d75a35c05610b14b3 SHA256 (FreeBSD-8.3-RC2-i386-disc1.iso) =3D 5cca1166525d1972cb10f2115f1faef= 04ab8ad71a5f697fd9603559c05db191f SHA256 (FreeBSD-8.3-RC2-i386-dvd1.iso) =3D d32cc6ad60cbcb3071e7dab6c59ae1e1= 04d161d89c95a30f91534b61687e8bee SHA256 (FreeBSD-8.3-RC2-i386-livefs.iso) =3D 8a1852a9178de99cfec6a8acfa72af= 94052fa8cf6021d71e2aee5c16771b16ef SHA256 (FreeBSD-8.3-RC2-i386-memstick.img) =3D 6078745475b88d51e65eb3602e97= b2375d31e5d3eeb0c25cf7e9404c363222e7 SHA256 (FreeBSD-8.3-RC2-pc98-bootonly.iso) =3D 2c31c8bafeb75f4531a96a6adc3b= b4eb4286cd362145538fcf25ff92df1c89ae SHA256 (FreeBSD-8.3-RC2-pc98-disc1.iso) =3D f86e102241828ef1f89f63f266470db= 13bd28ed3444e8931f1e8ddc9ab497ba0 SHA256 (FreeBSD-8.3-RC2-pc98-livefs.iso) =3D cb6ff8fd8c7c219c081d9dbd8faf44= b5271d444ad4ca083e1302f72bd7d0819a SHA256 (FreeBSD-8.3-RC2-sparc64-bootonly.iso) =3D 6c2b79a02e9a05adbbd2c69de= cc79323a3c63cd98af5e6e313e76e6ad734e238 SHA256 (FreeBSD-8.3-RC2-sparc64-disc1.iso) =3D 181580752916ee5be6a277e201e3= 72f7a082da6d4bd6162efd80b406a1f43ba3 SHA256 (FreeBSD-8.3-RC2-sparc64-dvd1.iso) =3D 1e87d7fd75747539c4b921a342643= 8701d091b36ea85d88054d3b7859807358b SHA256 (FreeBSD-8.3-RC2-sparc64-livefs.iso) =3D 518910b4094a37c0af2eb3b6f20= b218e9ca67736b3b54a078fea30b1a84901f2 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-HZ/MTT0eIrfdicCpzq0P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk95I+QACgkQ/G14VSmup/ba5ACeLQdLCgd3NKP+2B1z55ufx5sM kacAnAmCjO+pq2I5jd+KRGZIhPP+9Jev =bSnm -----END PGP SIGNATURE----- --=-HZ/MTT0eIrfdicCpzq0P-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 06:53:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE68B1065738 for ; Mon, 2 Apr 2012 06:53:37 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5EA168FC0A for ; Mon, 2 Apr 2012 06:53:37 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so1880819wib.13 for ; Sun, 01 Apr 2012 23:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dRuyJnEGX1D4Yr6UgniALJonphvIKgDK/ejxC6txeRo=; b=EbppzPlRHVrVfEsJTtPdIAryzn8H8puW4KlLZlcOs9Ec0XeGkqHVOA4SMoXNlHgu3H hkjX5yIVeZNY7ff/Gaq93rWtooUsC78LQrSpEcKSpZ6kDzE+MQ9c46+HPSVHuEGtVbBq W6TD6kAwQqqLbv2wwrWRUUjqaNqwvIWU2MuXMtsvbQwqHmKtToAfJjKQ3SXf3M3jPE0F Y+wKFImRnXYY7x7ypUIHe8t2t1PlDW34GVc6Ij4mNbEWGWXw59QDBfFb8hBu8Jh2nS2O Gnpi2+Cz0HABftwxM2HFovQ+4cdDuBsMakj106j9xE+ciJxn2F5YYoObJ9XyOhx6yli8 c2NA== MIME-Version: 1.0 Received: by 10.180.107.162 with SMTP id hd2mr22573703wib.8.1333349616291; Sun, 01 Apr 2012 23:53:36 -0700 (PDT) Received: by 10.180.102.67 with HTTP; Sun, 1 Apr 2012 23:53:36 -0700 (PDT) Date: Mon, 2 Apr 2012 02:53:36 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: 8.3-RC2 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 06:53:37 -0000 Is it right to presume virtualbox package will be available in 8.3-RELEASE? As it is currently not available in packages-8.3-release/All or packages-8-stable/All for i386 or amd64. I will probably make the move to 9.0 stable as it is currently available there for both and that is the future of things. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 09:56: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 B3DB7106564A for ; Mon, 2 Apr 2012 09:56:33 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 63F768FC12 for ; Mon, 2 Apr 2012 09:56:33 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2261132vcm.13 for ; Mon, 02 Apr 2012 02:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9iDN4weh9gpq+vFGY+oNYPAlcpql40RPxZqVebWdpjA=; b=NTgNaKxxX5puCfNO1oT18rv3lVP9QdRPk1OIYW19XOwQomlgrHfuI7o6pioDv7jHHm CdF+m97Etn8TSI+A/c6MYl3dKhocMUs2YWQg8GZzfUQaP9zmXX2BJGsdtPX7gw45PUfq ub3knCrZLRLYmVqnbxCPz8/+M7p2y9k8pyBPHC+GHbzT5PcFjHZTBSE76BShoP+8OzJ0 H+sqxNtNtxWofzaRAWi+m/oZTZXeu4YPYwGQrtym2b0dwMEeCSW5Y8sV6xhaXv8X2ajN /Ypo2meEppb9tsh83NvI637IFmGeUBGRzSXQl6+HZebsb9FrBl10+4Q32HrWCcudQWeQ mU1A== MIME-Version: 1.0 Received: by 10.52.91.16 with SMTP id ca16mr2969546vdb.125.1333360592127; Mon, 02 Apr 2012 02:56:32 -0700 (PDT) Received: by 10.52.181.129 with HTTP; Mon, 2 Apr 2012 02:56:32 -0700 (PDT) In-Reply-To: <4F766F29.2030803@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 10:56:32 +0100 Message-ID: From: Tom Evans To: Richard Yao Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 09:56:33 -0000 On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: >> There are no security implications, no system resources to be wasted. >> >> And if you think there are security implications, then lets see a >> proof-of-concept. > > If I find time to write a proof-of-concept, I promise to publish it > publicly. Your security team will find out when everyone else does. Richard, I'm not sure what you are trying to accomplish here. You have had a clear explanation of why certain things are done in a certain way in the FreeBSD codebase, and a confirmation that they do not think it causes any security issues in FreeBSD. Your response is to threaten to write an exploit against FreeBSD, and distribute it publicly before disclosing to security@. Are you trying to be an ass? Someone disagrees with you on the internet, so you throw all the toys out the pram? Tom From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 14:31:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1D101065673; Mon, 2 Apr 2012 14:31:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95BD28FC18; Mon, 2 Apr 2012 14:31:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1BA7CB979; Mon, 2 Apr 2012 10:31:50 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Mon, 2 Apr 2012 08:49:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> <201203301714.37323.jhb@freebsd.org> <1333143034.4450.1.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1333143034.4450.1.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201204020849.58087.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Apr 2012 10:31:50 -0400 (EDT) Cc: "freebsd-stable@freebsd.org" Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 14:31:50 -0000 On Friday, March 30, 2012 5:30:34 pm Sean Bruno wrote: > > > This is the relevant bits: > > > > Handle 0x2600, DMI type 38, 18 bytes > > IPMI Device Information > > Interface Type: KCS (Keyboard Control Style) > > Specification Version: 2.0 > > I2C Slave Address: 0x10 > > NV Storage Device: Not Present > > Base Address: 0x0000000000000CA8 (I/O) > > Register Spacing: 32-bit Boundaries > > > > Note the '32-bit' boundaries. I think ACPI doesn't support that for its > > attachment (well, it does if they specify each port as a separate thing in > > _CRS). Can you get acpidump -d output? > > > > Aye, here ya go. > > http://people.freebsd.org/~sbruno/acpidump_r815.txt Hmm, that actually looks correct. Try sabotaging the ACPI attach just for testing (i.e. add a 'return (ENXIO)' to the top of the probe routine in ipmi_acpi.c) just to see if that makes a difference. If not, then I think the BMC is just broken or your BIOS is lying. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 15:03: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 7663D106564A; Mon, 2 Apr 2012 15:03:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9E38FC23; Mon, 2 Apr 2012 15:03:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AFED0B94A; Mon, 2 Apr 2012 11:03:53 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 2 Apr 2012 11:00:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203311925.q2VJPmCB056070@ambrisko.com> In-Reply-To: <201203311925.q2VJPmCB056070@ambrisko.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204021100.15742.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Apr 2012 11:03:53 -0400 (EDT) Cc: Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 15:03:54 -0000 On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: > Sean Bruno writes: > | Noting a failure to attach to the onboard IPMI controller with this dell > | R815. Not sure what to start poking at and thought I'd though this over > | here for comment. > | > | -bash-4.2$ dmesg |grep ipmi > | ipmi0: KCS mode found at io 0xca8 on acpi > | ipmi1: on isa0 > | device_attach: ipmi1 attach returned 16 > | ipmi1: on isa0 > | device_attach: ipmi1 attach returned 16 > | ipmi0: Timed out waiting for GET_DEVICE_ID > > I've run into this recently. A quick hack to fix it is: > > Index: ipmi.c > =================================================================== > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v > retrieving revision 1.14 > diff -u -p -r1.14 ipmi.c > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) > if (error == EWOULDBLOCK) { > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); > ipmi_free_request(req); > - return; > } else if (error) { > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); > ipmi_free_request(req); > > The issue is that the wakeup doesn't actually wake up the msleep > in ipmi_submit_driver_request. The error being reported is that > the msleep timed out. This doesn't seem to be critical problem > since after this things seemed to work work. I saw this on 9.X. > Haven't seen it on 8.2. Not sure about -current. > > It doesn't happen on all machines. Hmm, are you seeing the KCS thread manage the request but the wakeup() is lost? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 16:16: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 A2EF91065670; Mon, 2 Apr 2012 16:16:04 +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 7610E8FC08; Mon, 2 Apr 2012 16:16:04 +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; 02 Apr 2012 09:16:10 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q32GG3OQ001977; Mon, 2 Apr 2012 09:16:03 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q32GG3Yr001976; Mon, 2 Apr 2012 09:16:03 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201204021616.q32GG3Yr001976@ambrisko.com> In-Reply-To: <201204021100.15742.jhb@freebsd.org> To: John Baldwin Date: Mon, 2 Apr 2012 09:16:03 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@freebsd.org Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 16:16:04 -0000 John Baldwin writes: | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: | > Sean Bruno writes: | > | Noting a failure to attach to the onboard IPMI controller with this dell | > | R815. Not sure what to start poking at and thought I'd though this over | > | here for comment. | > | | > | -bash-4.2$ dmesg |grep ipmi | > | ipmi0: KCS mode found at io 0xca8 on acpi | > | ipmi1: on isa0 | > | device_attach: ipmi1 attach returned 16 | > | ipmi1: on isa0 | > | device_attach: ipmi1 attach returned 16 | > | ipmi0: Timed out waiting for GET_DEVICE_ID | > | > I've run into this recently. A quick hack to fix it is: | > | > Index: ipmi.c | > =================================================================== | > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v | > retrieving revision 1.14 | > diff -u -p -r1.14 ipmi.c | > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 | > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 | > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) | > if (error == EWOULDBLOCK) { | > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); | > ipmi_free_request(req); | > - return; | > } else if (error) { | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); | > ipmi_free_request(req); | > | > The issue is that the wakeup doesn't actually wake up the msleep | > in ipmi_submit_driver_request. The error being reported is that | > the msleep timed out. This doesn't seem to be critical problem | > since after this things seemed to work work. I saw this on 9.X. | > Haven't seen it on 8.2. Not sure about -current. | > | > It doesn't happen on all machines. | | Hmm, are you seeing the KCS thread manage the request but the wakeup() is | lost? It was a couple of weeks ago that I played with it. I put printf's around the msleep and wakeup. I saw the wakeup called but the sleep not get it. I can try the test again later today. Right now my main work machine is recovering from a power outage. This was with 9.0 when I first saw it. This issue seems to only happen at boot time. If I kldload the module after the system is booted then it seems to work okay. The KCS part was working fine and got the data okay from the request. I haven't seen or heard any issues with 8.2. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 16:51: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 2841910657E0 for ; Mon, 2 Apr 2012 16:51:04 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge2.cs.stonybrook.edu (edge2.cs.stonybrook.edu [130.245.9.211]) by mx1.freebsd.org (Postfix) with ESMTP id B96098FC0A for ; Mon, 2 Apr 2012 16:51:02 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge2.cs.stonybrook.edu (130.245.9.211) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 2 Apr 2012 12:51:02 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 12:51:01 -0400 Message-ID: <4F79D88B.3040102@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 12:49:15 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Tom Evans References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1E24C98EB82718245EB64EA0" X-Originating-IP: [72.89.250.133] Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 16:51:04 -0000 --------------enig1E24C98EB82718245EB64EA0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/02/12 05:56, Tom Evans wrote: > On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao w= rote: >>> There are no security implications, no system resources to be wasted.= >>> >>> And if you think there are security implications, then lets see a >>> proof-of-concept. >> >> If I find time to write a proof-of-concept, I promise to publish it >> publicly. Your security team will find out when everyone else does. >=20 > Richard, I'm not sure what you are trying to accomplish here. You have > had a clear explanation of why certain things are done in a certain > way in the FreeBSD codebase, and a confirmation that they do not think > it causes any security issues in FreeBSD. >=20 > Your response is to threaten to write an exploit against FreeBSD, and > distribute it publicly before disclosing to security@. Some people believe that projects that do not take proper countermeasures against security vulnerabilities do not deserve to have special notification of issues. I happen to be one of them. > Are you trying to be an ass? Someone disagrees with you on the > internet, so you throw all the toys out the pram? I suggest that you look at things from my perspective. I asked a simple question on your mailing list. I then received several private emails from various FreeBSD developers insulting my intelligence for the act of asking a question. Who is the "ass" here? --------------enig1E24C98EB82718245EB64EA0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPediQAAoJELFAT5FmjZuEY3cQAM+Gm+9I1L6vj9mJzkcBcA4m BC2qiFtHixpRz51JQXAxWYVUoBnAvagSD+258blDrBTV9BuPCvGPJ4QOgcnS1wGW vJsTJQeGV1B/C0jvLtJGZb5eGatgnwVn4gxp4eputZMY6eQRTltE0QNyOrxqGY+n NXLRcYsp4dADe11s6VsMWJH59rtjKjaEtQFkMhMs1zUOxoL3zbjPpRXyqz6q0e9+ XQyYq0r+7tcfwLEf4KQlV2Qq68Xwf65Pkj30Y7mpg/dzOx1hcZaC2EBMyWddVX5/ Cybr32MnDwS46NFI+alpJwh98z5T6n5mianhThlXZw4229j0qEJzX/M8ah7XZcfE UCZJlaNZdOUbr02zYB5JO+ttDh1fi1t8bJhZh1yW2I5j3fC2W1BW0jB/bE9o93aV yAnb9HVBWANXj/y9gqjpzgJZ1U/woLAcOcqPAoqGUy+Jb6IoLFDpu3ChIBlhMcO8 AAQUoQrf3LC34epQcWvVDVJxuX4bgUKbjQZ7Z8hXGTVbtZc8DTEtlIGhB2U+keqW b57sfA5wWuyLfE1sFSNfR4HE9O71xdyNqokvySb0NdXaKaj6dxEHBP2bmpiKc0GR tqior/ahftGq/8EcygiqhUUKHeeBhmnxZsRLYCPSN0Tg8YKSJU+1m83+r+bftnfP SdS7YHQbFQtkQj0s+LEr =z0/z -----END PGP SIGNATURE----- --------------enig1E24C98EB82718245EB64EA0-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 17:08: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 048A8106566B for ; Mon, 2 Apr 2012 17:08:58 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5CF8FC12 for ; Mon, 2 Apr 2012 17:08:56 +0000 (UTC) Received: by qao25 with SMTP id 25so2021840qao.13 for ; Mon, 02 Apr 2012 10:08:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Y3NnXh9N5O61+99ZDqcoqSH3fpTR52P+KwQBQVmmoZk=; b=UnBD+isCc6ZE/Tg7Jdx0aHNLvZPd2cZonppyoGo5/RjJkdGtBDwdS8OKlNbaauPs+/ tn6uQUxgRyzrRIC8lQ5Ocw0VQs+9TEbUesyzMjwpkzI2pxz+Md/nJqUe1Q/BicK6IZCJ nRwm9nynEjdEgYy/R2YMaiQwpk7gycqli1YlVznH5Hz0QF6tsAq4xTSnU4g1eK/Samat t/Vux6EE23/MTec+gf9odkdcwtZtHjMUfq9jDRLCoFC7yOiBz+Bg/VfN7p7EP01yqfz0 N1kFrmSgem0c2pSZ7wug4Q0E/MeLwBuJXTgjZT2NdQkzupOIWoYsyg311brScI1WlPxN kSlQ== Received: by 10.224.35.130 with SMTP id p2mr2566079qad.32.1333386535773; Mon, 02 Apr 2012 10:08:55 -0700 (PDT) Received: from jims-iMac.local (pool-108-39-82-70.nrflva.fios.verizon.net. [108.39.82.70]) by mx.google.com with ESMTPS id ha3sm35500113qab.13.2012.04.02.10.08.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 10:08:54 -0700 (PDT) Message-ID: <4F79DD24.2010000@ohlste.in> Date: Mon, 02 Apr 2012 13:08:52 -0400 From: Jim Ohlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> In-Reply-To: <4F79D88B.3040102@cs.stonybrook.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmML4wtxFRoOIn6ShDIM4/wz07nKjlcqaWGJyr/fkOPgguk4ykserN76tmwyl/+tT3mUNRM Cc: Richard Yao Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 17:08:58 -0000 On 4/2/12 12:49 PM, Richard Yao wrote: > On 04/02/12 05:56, Tom Evans wrote: >> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: >>>> There are no security implications, no system resources to be wasted. >>>> >>>> And if you think there are security implications, then lets see a >>>> proof-of-concept. >>> >>> If I find time to write a proof-of-concept, I promise to publish it >>> publicly. Your security team will find out when everyone else does. >> >> Richard, I'm not sure what you are trying to accomplish here. You have >> had a clear explanation of why certain things are done in a certain >> way in the FreeBSD codebase, and a confirmation that they do not think >> it causes any security issues in FreeBSD. >> >> Your response is to threaten to write an exploit against FreeBSD, and >> distribute it publicly before disclosing to security@. > > Some people believe that projects that do not take proper > countermeasures against security vulnerabilities do not deserve to have > special notification of issues. I happen to be one of them. Wow. You're not only an ass, you're a pompous ass. > >> Are you trying to be an ass? Someone disagrees with you on the >> internet, so you throw all the toys out the pram? > > I suggest that you look at things from my perspective. I asked a simple > question on your mailing list. I then received several private emails > from various FreeBSD developers insulting my intelligence for the act of > asking a question. Who is the "ass" here? > See above. Or... look in the mirror. -- Jim Ohlstein From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 17:12: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 17C1E106566B for ; Mon, 2 Apr 2012 17:12:53 +0000 (UTC) (envelope-from lattera@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 C25558FC14 for ; Mon, 2 Apr 2012 17:12:52 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so5269324obb.13 for ; Mon, 02 Apr 2012 10:12:52 -0700 (PDT) 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=249n+T3mKEkQSwcFXfkDBAbjYrDpis2c5TyduzsGsdI=; b=QaId8U3IRm9C52osrfinaEpjcfa7zBarFG/2ZGX4HH0ZYGAq5xA27dJyK++2RQyMmP EOljoWPLBvCsY39BQONEwC/68TSRPcVah/tua3SaYQnr7N8v13cgTk4L0KqMIcJ05gmT 0X+5QVTPoa+d1wJDn6zu69shbBA/8frtX+8JxCyu10TMdo+34fjxIljzObvhE+eXMSrk mw8d7HjlK0VpiKwMttP9tQDCAzETCxm8hrQiEKpv2l+U7w8nPMHtOGkBSkNrTKO6iwwN asoqgbQBkxSCsBCD45dYbkRbj6g3UF3Kq5CwhRD29neyGltSWxASnZYRaxmGn8FgCWch /Ycw== MIME-Version: 1.0 Received: by 10.182.48.36 with SMTP id i4mr13553084obn.72.1333386772149; Mon, 02 Apr 2012 10:12:52 -0700 (PDT) Received: by 10.182.19.161 with HTTP; Mon, 2 Apr 2012 10:12:52 -0700 (PDT) Received: by 10.182.19.161 with HTTP; Mon, 2 Apr 2012 10:12:52 -0700 (PDT) In-Reply-To: <4F79D88B.3040102@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 11:12:52 -0600 Message-ID: From: Shawn Webb To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Tom Evans , freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 17:12:53 -0000 Let's all calm down here. No need to make this personal. Let's please try to keep this conversation professional and respectful to all parties involved. Richard, I suggest that if you think the current implementation is less secure than other implementations, you could write a patch and submit it upstream. I'm sure that the FreeBSD security team would love any patches that enhance security. Granted, you might have to present a strong case for a patch of this nature to be accepted upstream, but I'm sure you will learn a lot about FreeBSD and others (like me) who maintain modified FreeBSD codebases would benefit from such a patch. I might be interested to help you develop this patch if you decide to take it on. Thanks, Shawn Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 2, 2012 10:53 AM, "Richard Yao" wrote: > On 04/02/12 05:56, Tom Evans wrote: > > On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao > wrote: > >>> There are no security implications, no system resources to be wasted. > >>> > >>> And if you think there are security implications, then lets see a > >>> proof-of-concept. > >> > >> If I find time to write a proof-of-concept, I promise to publish it > >> publicly. Your security team will find out when everyone else does. > > > > Richard, I'm not sure what you are trying to accomplish here. You have > > had a clear explanation of why certain things are done in a certain > > way in the FreeBSD codebase, and a confirmation that they do not think > > it causes any security issues in FreeBSD. > > > > Your response is to threaten to write an exploit against FreeBSD, and > > distribute it publicly before disclosing to security@. > > Some people believe that projects that do not take proper > countermeasures against security vulnerabilities do not deserve to have > special notification of issues. I happen to be one of them. > > > Are you trying to be an ass? Someone disagrees with you on the > > internet, so you throw all the toys out the pram? > > I suggest that you look at things from my perspective. I asked a simple > question on your mailing list. I then received several private emails > from various FreeBSD developers insulting my intelligence for the act of > asking a question. Who is the "ass" here? > > From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 17:13:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4D110657A6 for ; Mon, 2 Apr 2012 17:13:09 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 64F8D8FC15 for ; Mon, 2 Apr 2012 17:13:09 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2664545vbm.13 for ; Mon, 02 Apr 2012 10:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P17o1IJ6Q4vn/Fs0A/OlI5YBqDa+KVIlJ+Csu3HD43U=; b=nJvMDEr1Md5Unvv8kzXLH0DZ1xXYwjNi2zypUnhVCKXPXX5oQTE/BE10Rh+AduGL+M TkM6rOEbA8iU9pMCv1e4oxgLm0hKnuDQD2fX+dEg9Gis25ckQLu3QrKI0CCKTGGibKTt JAbbaTBoayM2zPiBLmKqGOeXZA7LVIGzUmrPHiBYGiEVvnUU6wLHw8+awkgF1xz4ZQx8 GHuD5OjqSktvSNfnxXLxIn1fNwkghwUxPPyLeR3rg7hM2xZmnoxa9lJ/d6ujC5SDjGj0 lxl7J3fngI6JgRgy9T/IpP8bu8P9y2Bj8Io0P0pMQa9xsV1M5E5O7ztESczQDNMeqEsq MVGQ== MIME-Version: 1.0 Received: by 10.52.95.198 with SMTP id dm6mr3510206vdb.91.1333386787868; Mon, 02 Apr 2012 10:13:07 -0700 (PDT) Received: by 10.52.181.129 with HTTP; Mon, 2 Apr 2012 10:13:07 -0700 (PDT) In-Reply-To: <4F79D88B.3040102@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 18:13:07 +0100 Message-ID: From: Tom Evans To: Richard Yao Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 17:13:09 -0000 On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote: > On 04/02/12 05:56, Tom Evans wrote: >> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: >>>> There are no security implications, no system resources to be wasted. >>>> >>>> And if you think there are security implications, then lets see a >>>> proof-of-concept. >>> >>> If I find time to write a proof-of-concept, I promise to publish it >>> publicly. Your security team will find out when everyone else does. >> >> Richard, I'm not sure what you are trying to accomplish here. You have >> had a clear explanation of why certain things are done in a certain >> way in the FreeBSD codebase, and a confirmation that they do not think >> it causes any security issues in FreeBSD. >> >> Your response is to threaten to write an exploit against FreeBSD, and >> distribute it publicly before disclosing to security@. > > Some people believe that projects that do not take proper > countermeasures against security vulnerabilities do not deserve to have > special notification of issues. I happen to be one of them. This is a straw man argument - FreeBSD does take proper countermeasures against security vulnerabilities - and so your conclusion that you can blithely fully disclose vulnerabilities with no moral concerns is a logical fallacy. You have posited that this is a vulnerability to FreeBSD (based upon checks put in place for a Linux project) whilst many FreeBSD committers have said that you are mistaken, and it does not do so. If you disagree with them, then show them by example or argument that they are wrong. If you think they are wrong and that it is a vulnerability to FreeBSD, you should be discussing this off list in detail with the sec team - security-officer@FreeBSD.org Threatening to jeopardise FreeBSD's security by public disclosure, with no discussion with the FreeBSD security team is a puerile way of acting, and does neither you, your university nor Gentoo any favours. > I suggest that you look at things from my perspective. I asked a simple > question on your mailing list. I then received several private emails > from various FreeBSD developers insulting my intelligence for the act of > asking a question. Who is the "ass" here? > I can't comment as to what people said to you off-list, I'm not party to that. What you said on-list: > If I find time to write a proof-of-concept, I promise to publish it > publicly. Your security team will find out when everyone else does. that is "ass" territory. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 17:33:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C14D106566B for ; Mon, 2 Apr 2012 17:33:28 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge1.cs.stonybrook.edu (edge1.cs.stonybrook.edu [130.245.9.210]) by mx1.freebsd.org (Postfix) with ESMTP id A250F8FC0C for ; Mon, 2 Apr 2012 17:33:27 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge1.cs.stonybrook.edu (130.245.9.210) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 2 Apr 2012 13:33:21 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 13:33:24 -0400 Message-ID: <4F79E27E.3000509@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 13:31:42 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Tom Evans References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig84D05DD8B3C98EF127CDEA97" X-Originating-IP: [72.89.250.133] Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 17:33:28 -0000 --------------enig84D05DD8B3C98EF127CDEA97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/02/12 13:13, Tom Evans wrote: > On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wr= ote: >> On 04/02/12 05:56, Tom Evans wrote: >>> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao = wrote: >>>>> There are no security implications, no system resources to be waste= d. >>>>> >>>>> And if you think there are security implications, then lets see a >>>>> proof-of-concept. >>>> >>>> If I find time to write a proof-of-concept, I promise to publish it >>>> publicly. Your security team will find out when everyone else does. >>> >>> Richard, I'm not sure what you are trying to accomplish here. You hav= e >>> had a clear explanation of why certain things are done in a certain >>> way in the FreeBSD codebase, and a confirmation that they do not thin= k >>> it causes any security issues in FreeBSD. >>> >>> Your response is to threaten to write an exploit against FreeBSD, and= >>> distribute it publicly before disclosing to security@. >> >> Some people believe that projects that do not take proper >> countermeasures against security vulnerabilities do not deserve to hav= e >> special notification of issues. I happen to be one of them. >=20 > This is a straw man argument - FreeBSD does take proper > countermeasures against security vulnerabilities - and so your > conclusion that you can blithely fully disclose vulnerabilities with > no moral concerns is a logical fallacy. My opinion is that any OS that lacks ALSR lacks proper countermeasures against vunerabilities that ASLR would kill. Furthermore, I believe that trying to minimize the impact of bugs that would be addressed by ASLR is ultimately harmful to users' security. Logically, full disclosure would only apply to attacks that ASLR would kill. With that said, I should remind you of the FreeBSD project's license, which disclaims the possibility of "moral concerns": THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. It is highly unlikely that anyone who opts for full disclosure of vulnerabilities that ASLR would kill would also be the person who wrote the vulnerable code in the first place. However, should he be the same person, it would seem that you have already accepted a license freeing him of responsibility. there are many people who have commit access. Any of them could intentionally commit vulnerabilities that ASLR would kill. If you do not like this situation, I suggest that you consider alternative operating systems, such as AIX, Mac OS X or Solaris. Their licenses might be more permissive in your ability to hold their makers responsible for flaws. --------------enig84D05DD8B3C98EF127CDEA97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPeeKAAAoJELFAT5FmjZuE1YwQAIiV3JFU+Kg+GumulPhMP8sp 3uPaSg+Wg/ztD2ZCHMz491z/PKldW9DoEqF6JJDS/+nxqOf+OPYdUarnkAx1K0N+ 0ANhchqJjt7XrO26YL8YFHtH8kkT1Xl+ltmS0tohtuEltO/Wq1xQpDTb0B4AW75F LVHW6vprs4P8vCXpis5OG61qY2pSQFp5wdFoiv8Q0HK/wPt9PfdYHTgt/avSghrN +X1MatQtr/wnuA9R5vGvyPwj2WhBWOB84S/1Fn4MRnFPg4eeIF4Qkyh+WHBNAj0H bpyQSwzCyHL/g94EqvC9HDHjs5j/OrHcEVE0KXIZYY0+Eu6CTCHpLUJu94gW3vyD fEDjXz9owFHJexFWmY/KjjeVr5tvv79s/2NQHvEGaoYJHpZ28JruGdf+B6+9mALE 1RuVAUs1SgjNTMJkEosVK4SlGBwWnAc3V5PCGpIU7pH08WYROetF2xUKIEvA96R8 +l1jKPqpXKudDf/Drg9gMP14JSCq0+d8Jjk/MjCuCWLjYLyxnw0OfV1QHyuuWyTf d5PlRiHgoJU0yPA87zo7kV5YS8eJq91PIoRTeoTS40yCyDiNcJRxlFoJKawfCcmM teTMulO1ZjT0ZOhXZychvE6PK0ihoCtOR46MqGn02iFc+0374UcSyXzJxc2UP+wp Tca3la+kbxPADYBVZBzd =pcUP -----END PGP SIGNATURE----- --------------enig84D05DD8B3C98EF127CDEA97-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 18:42: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 514C31065670 for ; Mon, 2 Apr 2012 18:42:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 072AC8FC08 for ; Mon, 2 Apr 2012 18:42:27 +0000 (UTC) Received: by iahk25 with SMTP id k25so6123814iah.13 for ; Mon, 02 Apr 2012 11:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AQ7TD/SqCGbMIhVf4/AVGT7rJqEFKQ4/9jpC2k0yloI=; b=WPs4R1HAu4w+f8BkZHF5/W1vL7p3LqQ3dydumE2lDeFXEX05dea/i7uaF/ffNQhbsJ aq6gqdrt5qxPt2LxG6CCiN+fBl2K2b0zijrz16l8YW6ZfK2Ej3MMRuNi2ip+z//EYJPm cdA2IWYeWVklSdW7xeLvSAETegYYEKhI7oMhE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AQ7TD/SqCGbMIhVf4/AVGT7rJqEFKQ4/9jpC2k0yloI=; b=IziK+Nv3nTSx4WYgEMfg2/n2ciBBo8n7Tw2X9f9EbsSzxExheS3VD5IY1k3ssh9OZ6 YakWDkvdqlB4fihp8yuGDfeWN6HCD97CTGAQLc8o7dJyX1lNnoF8V8rrlM2lMD37ISDO RYrEuPEDxROK4cFOZ9QTnQm7JC9OpatXIlX8gFilu+8ctoLp9ThSXEUVUuYO43TAkSve 81/YpCE1VaMftTCsUdVmreq7ZDg7VosPUKW7OqT3NL8gL4EpMtI3o/IUy/WNNds5Pr1I FRyclcXaY8A/Q/+Fq76RDjANNN9QW+lv3MnCcSmqUtS42WIFQaxdoCtFsa8ALnwgKH0+ meiQ== MIME-Version: 1.0 Received: by 10.50.219.200 with SMTP id pq8mr7706838igc.6.1333392147434; Mon, 02 Apr 2012 11:42:27 -0700 (PDT) Received: by 10.231.172.138 with HTTP; Mon, 2 Apr 2012 11:42:27 -0700 (PDT) In-Reply-To: <4F766F29.2030803@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 11:42:27 -0700 Message-ID: From: Peter Wemm To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnbPkeGlNby8k3xQ8uZl89lVFYG30pWWnd7kVXWKFsBR2PGtPaV+MgA01ck51g9Xziiuez1 Cc: Konstantin Belousov , freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 18:42:28 -0000 On Fri, Mar 30, 2012 at 7:42 PM, Richard Yao wrote= : > On 03/30/12 22:15, Peter Wemm wrote: >> On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wr= ote: >>> On 03/30/12 18:46, Konstantin Belousov wrote: >>>> Reread what I wrote to you. Also, it pays off learning how ELF works >>>> before making conclusion from the absence of the output of readelf -d. >>>> Amd64 modules _are not_ shared objects. >>> >>> Whether or not they are shared objects is irrelevant. The fact is that >>> they have text relocations, which interfere with ASLR. Do I need to >>> produce exploit code before you take me seriously? >>> >> >> I am the person who wrote it and deliberately chose to cause text >> relocations to be generated on i386. =A0It is by design, not a bug. >> >> All of your concerns are perfectly valid if they were for userland. >> >> For the record, our amd64 modules ALSO do this, but your tools simply >> do not detect it. >> >> Here is what happens, and here is why it is not a problem: >> >> When you compile with -fpic on an architecture that doesn't support >> PC-relative addressing adequately, the compiler generates code to do >> indirect memory references via the global offset table. =A0This is so >> that all the relocations can be collected into a single location in >> order to not dirty the MAP_PRIVATE data pages. >> >> example: >> if there is an function at 0x12345, and another function in a >> different .so file that wants to call it at 0x22345, then the call >> instruction would have to be relocated. =A0The asm instructions would >> look like: >> 0xE8FFEFFFFF =A0(offset is -0x10000) >> >> If the same .so file was loaded in another user process at 0x32345, >> then the relocation would be different. =A0An entire page would be >> dirtied by the dynamic linker so that the second instance of the .so >> file had 0xE8FFDFFFFF (-0x20000). =A0This is a waste of memory and >> causes a storm of VM faults at startup. >> >> Instead, the code is compiled with -fPIC, which causes an extra memory >> reference via the global offset table. =A0Instead of the relocations >> being spread over the text segment, the relocations are in a single >> page. =A0The dynamic linker has to dirty one page only in order to set >> up a whole host of relocations. >> >> The cost is i386 doesn't have native pc-relative mode, so it has to >> waste an entire register. =A0We dedicate one of the 6 general purpose >> registers which costs a hefty performance hit. =A0This is why crypto >> code tends to be compiled without -fpic, for example. >> >> For KERNEL modules, all this changes. >> >> In userland, there is a dynamic linker. In the kernel, there is none. >> In userland, the .so files are mapped with mmap(MAP_PRIVATE), the >> kernel does not use mmap and always uses a private copy. >> In userland, the .so files are shared, the kernel NEVER shares them. >> In userland, doing a relocation causes a copy on write fault, this >> never happens to the kernel because its using private, exclusive >> malloc() pages. >> In userland, we make the performance tradeoff from -fpic in order to >> share memory pages, the kernel never shares pages so -fpic is a waste. >> In userland, ASLR has security benefits. =A0The kernel already does >> this.. if you load a module on one machine it'll ALWAYS be at >> different address space compared to another. >> >> In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non >> pic .o files into a container that was more convenient at the time to >> parse. =A0There is no global-offset-table. >> In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same >> non-pic code into a less convenient form that we can feed back into >> the linker if we wish. =A0There is no global offset table. >> >> Both i386 and amd64 use raw relocations, regardless of where the came >> from. =A0Text, data, anywhere. >> >> This has nothing to do with ASLR, because they are kernel objects, not >> shared libraries. > > Most people seem to think that I am unaware of these things, but I > already knew most of it. Note that this mostly applies to remarks people > are sending me privately. > > With that said, thank you for the detailed explanation. It filled in a > few blanks that I had, specifically in how FreeBSD does things. > >> You posted: >> =A0* QA Notice: The following files contain runtime text relocations >> =A0* =A0Text relocations force the dynamic linker to perform extra >> =A0* =A0work at startup, waste system resources, and may pose a security >> =A0* =A0risk. =A0On some architectures, the code may not even function >> =A0* =A0properly, if at all. >> The key here is "dynamic linker". =A0There is no dynamic linker to >> process this stuff. > >> This is simply a tools problem on your end. =A0It's not a bug. > > My tools are doing what they were supposed to do. However, people on the > list seem to think that the idea that they are checking for a problem to > be a matter of opinion. No, your tools are checking for, and reporting a USERLAND performance probl= em. A kernel .ko file is NOT used by the USERLAND dynamic linker. Your attempt to invoke ASLR are irrelevant to the situation because ASLR is a USERLAND thing, and kernel modules are ALREADY loaded at random locations. >> There are no security implications, no system resources to be wasted. >> >> And if you think there are security implications, then lets see a >> proof-of-concept. > > If I find time to write a proof-of-concept, I promise to publish it > publicly. Your security team will find out when everyone else does. "Daaaad! I found a cool security hole but the mean FreeBSD people don't believe me and won't take me seriously! I'm taking my toys and going home, so there! That'll teach them!" I'm not concerned your threat, and I would encourage you to do the research that it would take to implement a proof because you'll learn it doesn't work the way you seem to think it does. > You can argue otherwise, but for all I know, exploit code that ASLR > breaks is already in the wild. I believe that nothing short of full > disclosure would be beneficial to your users' security. "For all I know". And again, "ASLR".. ASLR is NOT RELEVANT here. Its a kernel file. Not anything to do with the userland dynamic linker where ASLR is implemented. Your argument is akin to saying ".zip files are guaranteed to be a security hole because .zip files might contain a .exe which might have a virus, so therefore .zip files must be banned even the ones containing a .txt file" --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 18:46:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 139DE1065672 for ; Mon, 2 Apr 2012 18:46:58 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB9BC8FC0C for ; Mon, 2 Apr 2012 18:46:57 +0000 (UTC) Received: by iahk25 with SMTP id k25so6129962iah.13 for ; Mon, 02 Apr 2012 11:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AQ8tsWCxKEWLXw++1QGXBpeCCrOanokO4AHABC+74Qo=; b=B/xqovvxfeP8iTOZscGK5TdJQRL2liJhhhkKBzC/zDS60s8/C7n/d95HcZLgJycjcr 4FJolfVSnHbyvwm7UZWrqALPlntwOyxfvSvARliR50RZOSHv4mTNOFuJwD8aXUW6ZqNU jRrqoCE+/THOM1XnI3zSNYwdFGcJdu/9orN5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AQ8tsWCxKEWLXw++1QGXBpeCCrOanokO4AHABC+74Qo=; b=mUkCLd0JbkneH3fnxlgBR4mUOSNZeIR/JwSdPEyS71VcYfMym1X3ghBD6DA1jRsXlG 1PGAW24WUTpmj2kUqjhXEEK8choExHdwB/o0oa15R5r497+bzmiH97CbzOmv62nmkJPI EzQFlHs9XzW2Ov0gynBqhPmbx3uS68UEQj5cvdSVcC0LekXR4ctW3Dd7c1wM7PlOBfdj S3x3vJtzan7z2obfbrS9Sk9rztsmDGNiH6sTccopY1tlgstuaK00Th8T2sXT+5QMCDWF ObsK7Fu+snl1kSW84HzWbJcB7u6VqYk2LMWl5aYXA3YnbUoq+jSizpEjYRcK6OKOmIwu eoJA== MIME-Version: 1.0 Received: by 10.50.219.200 with SMTP id pq8mr7717640igc.6.1333392417312; Mon, 02 Apr 2012 11:46:57 -0700 (PDT) Received: by 10.231.172.138 with HTTP; Mon, 2 Apr 2012 11:46:57 -0700 (PDT) In-Reply-To: <4F79E27E.3000509@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 11:46:57 -0700 Message-ID: From: Peter Wemm To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnJH+HeNp7okbLfvg4dtmpZDO1PcFgzPsP4mS5Zi+rG4ZEWrCZu1vJvMQ1ic3sy0qS0gDnZ Cc: Tom Evans , freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 18:46:58 -0000 On Mon, Apr 2, 2012 at 10:31 AM, Richard Yao wrote: > On 04/02/12 13:13, Tom Evans wrote: >> On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote: >>> On 04/02/12 05:56, Tom Evans wrote: >>>> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: >>>>>> There are no security implications, no system resources to be wasted. >>>>>> >>>>>> And if you think there are security implications, then lets see a >>>>>> proof-of-concept. >>>>> >>>>> If I find time to write a proof-of-concept, I promise to publish it >>>>> publicly. Your security team will find out when everyone else does. >>>> >>>> Richard, I'm not sure what you are trying to accomplish here. You have >>>> had a clear explanation of why certain things are done in a certain >>>> way in the FreeBSD codebase, and a confirmation that they do not think >>>> it causes any security issues in FreeBSD. >>>> >>>> Your response is to threaten to write an exploit against FreeBSD, and >>>> distribute it publicly before disclosing to security@. >>> >>> Some people believe that projects that do not take proper >>> countermeasures against security vulnerabilities do not deserve to have >>> special notification of issues. I happen to be one of them. >> >> This is a straw man argument - FreeBSD does take proper >> countermeasures against security vulnerabilities - and so your >> conclusion that you can blithely fully disclose vulnerabilities with >> no moral concerns is a logical fallacy. > > My opinion is that any OS that lacks ALSR lacks proper countermeasures > against vunerabilities that ASLR would kill. Furthermore, I believe that > trying to minimize the impact of bugs that would be addressed by ASLR is > ultimately harmful to users' security. Logically, full disclosure would > only apply to attacks that ASLR would kill. Remember.. ASLR is a userland thing. .ko files, which is what this thread is about, already use random address layout. When you do a "kldload virtio.ko", you have no way to predict what address it will be loaded at. And you don't even have access to the addresses. Of course if you want to talk about ASLR and userland .so files then that's an entirely different thing. But this thread is about your tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 19:25: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 ADEDB106566B for ; Mon, 2 Apr 2012 19:25:20 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge2.cs.stonybrook.edu (edge2.cs.stonybrook.edu [130.245.9.211]) by mx1.freebsd.org (Postfix) with ESMTP id 468A28FC0A for ; Mon, 2 Apr 2012 19:25:20 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge2.cs.stonybrook.edu (130.245.9.211) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 2 Apr 2012 15:25:20 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 15:25:18 -0400 Message-ID: <4F79FCB8.1090003@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 15:23:36 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Peter Wemm References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2B11ADE89A5E704533C71CB" X-Originating-IP: [72.89.250.133] Cc: Tom Evans , freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 19:25:20 -0000 --------------enigD2B11ADE89A5E704533C71CB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/02/12 14:46, Peter Wemm wrote: > Remember.. ASLR is a userland thing. .ko files, which is what this > thread is about, already use random address layout. When you do a > "kldload virtio.ko", you have no way to predict what address it will > be loaded at. And you don't even have access to the addresses. >=20 > Of course if you want to talk about ASLR and userland .so files then > that's an entirely different thing. But this thread is about your > tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. >=20 The PaX project's patches to the Linux kernel include kernel stack randomization. The Gentoo Hardened project makes use of this in their fork of the Linux kernel. --------------enigD2B11ADE89A5E704533C71CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPefy7AAoJELFAT5FmjZuEDkgQANVP4ETuoTEjHxSKiubdH7JD KnAQvdvEULuwJFhQNsAfEF3ls6mjMRIRDyXEQrIupzEjldMgIXCGd9gnjsT0X+PW mf60bgnc0VlIkoyYBUTeBCLZ4TWC03lSVVWohzqkiGWDCtzqONpR0G5dgcxOrRTZ 0a4IOu8AO6SxVUjne/a+zW/XKxktyXSpo2k9zdJqQX9tx5rdaCuZ6ZlzUI+VL11C Q2negh6n2pdLU0xy15xy3VRdG/figb5vAtG/WfFhHP7UYql4xnQbDIkEFEY/e8XE TyVXJ2Yy0eGCtFQcNpUGNMoNAtqDNXRXUEAVbNd9lqTmVlb6PSx5hnLWbFGVmCha 514relB4CrN5Nq4K0ATF9BkvwBQROH0cvWfOikNGCAwi8MegMaoWNH4atQV8i1xl F1xjndrlVDlGagqw7HUG8sXPIi9ZUsOAjhchA6bnctUAjgok3qk3A34+8v0xZqa4 3sdLngLk1z661YDaKmF6WUbuxbLBRElQUb/ZYeiYyX4EHja1Ya6Mmfe2EdXbRdTv CkHJZduQuEmBCAbqOi14FsL7UAEnCr1WcxDXkhfhYfL6BR6o2IuhS771i9xRo9oA E+exWU3/H5Tgl0ABNZcy/js7qARy22uELcnZujeyuI8MMJUHFCHfuSwvCk/+6YGX 6cPm06lSLrNde9fVKbCQ =LdKQ -----END PGP SIGNATURE----- --------------enigD2B11ADE89A5E704533C71CB-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 19:37:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E7A1065672 for ; Mon, 2 Apr 2012 19:37:40 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6EF8FC12 for ; Mon, 2 Apr 2012 19:37:39 +0000 (UTC) Received: by ghrr20 with SMTP id r20so1677283ghr.13 for ; Mon, 02 Apr 2012 12:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Pbxew3SWIwipZ7vY3s1KPjLKlPnOeGFk2r1ExUeklEk=; b=SWkVtu0n9zoL+jPJpKbuHHbRZV9eMRT4vBkn+zRkuUAYEGPyO3kee2WuvcKnEEnCna pT6HCCc7joWxszSm6ZYRnZGPvLuPd3zWBS7lu4zRXm3cSAPA9sP+LntqYRy/33LyK9R5 LZWTIGB4TRJddRqrwb54fam+BvHbmgGx7XSb4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Pbxew3SWIwipZ7vY3s1KPjLKlPnOeGFk2r1ExUeklEk=; b=aNbzWFTIazOkhVSe5EEtB3qvD/sWssHJsej+kKzOYafFrU6zAVY+D+eXcZq1BGCf3/ b37f0CinnWxNuspVLW88mK6vFdkyoXjnloLl7TJNRXHxObtDIgjQWY8HiUJV7gLI8JDN NDI8m+SA2pNCURzbIiUg5fcLcViHcZH4H5y2TRuB476DdEiWYps9g6nENGxrxd0V7f03 IsvnjuzM2OLjO47VerJlAO2eB5e6Bp0Xsrg46XJoxLLoplwdCHBFL5kyHPJpHbzZ2SOu bZhFFFDjI23xs51NRLIivnoVQf+8PdEY8FabM+Oy5ja7lm04dcqxEO67cMCTP7AjDFzG As8w== MIME-Version: 1.0 Received: by 10.50.216.132 with SMTP id oq4mr7915941igc.6.1333395459081; Mon, 02 Apr 2012 12:37:39 -0700 (PDT) Received: by 10.231.172.138 with HTTP; Mon, 2 Apr 2012 12:37:38 -0700 (PDT) In-Reply-To: <4F79FCB8.1090003@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 12:37:38 -0700 Message-ID: From: Peter Wemm To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmGlbonorq3Nz2dSW5BAAS9kz/BbLi23BE3eSKGezvzYeaEVO4CUeOauhzBx/7Txt9UPrSi Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 19:37:40 -0000 On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao wrote= : > On 04/02/12 14:46, Peter Wemm wrote: >> Remember.. ASLR is a userland thing. =A0.ko files, which is what this >> thread is about, already use random address layout. =A0When you do a >> "kldload virtio.ko", you have no way to predict what address it will >> be loaded at. =A0And you don't even have access to the addresses. >> >> Of course if you want to talk about ASLR and userland .so files then >> that's an entirely different thing. =A0But this thread is about your >> tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. >> > > The PaX project's patches to the Linux kernel include kernel stack > randomization. The Gentoo Hardened project makes use of this in their > fork of the Linux kernel. > I looked at their code, and their description here: http://pax.grsecurity.net/docs/randkstack.txt Of note: "pax_randomize_kstack() gathers entropy from the rdtsc instruction (read time stamp counter) and applies it to bits 2-6 of the kernel stack pointer. This means that 5 bits are randomized providing a maximum shift of 128 bytes - this was deemed safe enough to not cause kernel stack overflows yet give enough randomness to deter guessing/brute forcing attempts." This has nothing to do with the DT_TEXTREL in .ko that this thread is about and has no bearing on ASLR in any way. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 20:03: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 0809D1065670 for ; Mon, 2 Apr 2012 20:03:58 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge1.cs.stonybrook.edu (edge1.cs.stonybrook.edu [130.245.9.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8B50D8FC1B for ; Mon, 2 Apr 2012 20:03:57 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge1.cs.stonybrook.edu (130.245.9.210) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 2 Apr 2012 16:03:50 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 16:03:54 -0400 Message-ID: <4F7A05C4.9070808@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 16:02:12 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Peter Wemm References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCE81F30EC81A02BB7386186E" X-Originating-IP: [72.89.250.133] Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 20:03:58 -0000 --------------enigCE81F30EC81A02BB7386186E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/02/12 15:37, Peter Wemm wrote: > On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao w= rote: >> On 04/02/12 14:46, Peter Wemm wrote: >>> Remember.. ASLR is a userland thing. .ko files, which is what this >>> thread is about, already use random address layout. When you do a >>> "kldload virtio.ko", you have no way to predict what address it will >>> be loaded at. And you don't even have access to the addresses. >>> >>> Of course if you want to talk about ASLR and userland .so files then >>> that's an entirely different thing. But this thread is about your >>> tools finding DT_TEXTREL in a .ko kernel file, not userland .so files= =2E >>> >> >> The PaX project's patches to the Linux kernel include kernel stack >> randomization. The Gentoo Hardened project makes use of this in their >> fork of the Linux kernel. >> >=20 > I looked at their code, and their description here: > http://pax.grsecurity.net/docs/randkstack.txt >=20 > Of note: > "pax_randomize_kstack() gathers entropy from the rdtsc instruction > (read time stamp counter) and applies it to bits 2-6 of the kernel > stack pointer. This means that 5 bits are randomized providing a > maximum shift of 128 bytes - this was deemed safe enough to not cause > kernel stack overflows yet give enough randomness to deter > guessing/brute forcing attempts." >=20 > This has nothing to do with the DT_TEXTREL in .ko that this thread is > about and has no bearing on ASLR in any way. There are plenty of techniques employed to do ASLR by both the upstream Linux kernel and the PaX patches to it. I only needed to state one to prove that you were wrong about ASLR being exclusive to userland. If the QA checks had been triggered for an out-of-tree Linux kernel module, the Gentoo developers would consider it to be a bug. I have verified this with the Gentoo Hardened developers. Furthermore, they confirmed that text relocations in out-of-tree kernel modules would negatively affect ASLR. My original email to the list asked if this was an issue in FreeBSD. That question had been answered. However, people went ballistic upon the mere presence of my question, so I assured them that if I ever found time to write exploit code, I would do full disclosure to ensure that this issue was fixed. I stumbled across this issue when setting up an environment in which I could port gptzfsloader to Linux, so I have no reason to implement ASLR in the FreeBSD kernel. Also, the abuse I received over this has lead me to conclude that doing anything for upstream would be deterimental to my mental health, so I am not inclined to try. However, there could be unknown exploits in the wild that would be killed by ASLR in the wild. It would be best for someone, who considers securing FreeBSD to be worth suffering from abuse, to implement it. That person is not me. --------------enigCE81F30EC81A02BB7386186E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPegXHAAoJELFAT5FmjZuExZMQAKteZYCJdHHVHyF9YyJbCgbu eir2tSxJDygBtk58da56ZB5dx0UEW5/IDyLXFLJSLXZz7ZCZItc64WqgMv5zWf1W aAkpwV2g6EP7YEPYXryHPNlEzgpPgUIjkHGOMkDoyFMX6aii7lvz7SboEpArA3ak zuRWk1q9/8FBvAbkcR08DuZZYoVp6p4iBAtOFoWDFOfOkI7gL+3uSIKXHemxRaHX mslVHVLYGtKI7CxUdJW3kXqpV6BElerhbRXR9PHqJhC2Y1VTy7ZmOgpIYMCzWgPI woQk/N9MXcA/XHYmmpzSZEuYCiIpcPID1wdxaMPsz/g6UawFapxzJwiKKvbRjxNF 90BGKrQQncJE0eNzXjK+iSqBDBPMHoWJMSR1h2evKkCzDE37GpDjLOXLRuW/gjjd 5soH0t9mcFfZPRf77IwFHyhOxHF5Jy/wC4JdOXZdjinWK3DWv959P0Gmp/5UUFu6 iT1XAPYEo1D/BIa7kBP0PbLMzuwa4gtdcwspj61TAFsJl0PRBocMSleYoUUBtGOF j6cN0fPuL34eVxq2hEKY3NceTXQwDHeg6zb5I0inKiefDsIqIJeO5v8OsWFGHmqj RO760KhY/gZEAvoQQQOmw373OGllW3NNS4GjYcq9jC5pHYHjmEPsR6J6+VTZKDjf qMurt6yCYl993KOSM6Y0 =XyxY -----END PGP SIGNATURE----- --------------enigCE81F30EC81A02BB7386186E-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 22:08: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 1B6BF106564A for ; Mon, 2 Apr 2012 22:08:38 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BEFF08FC18 for ; Mon, 2 Apr 2012 22:08:37 +0000 (UTC) Received: by iahk25 with SMTP id k25so6404862iah.13 for ; Mon, 02 Apr 2012 15:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=52FFXBKsG41Ag9E16GRJHHWhifjE7xxZZSHApN5Gj0g=; b=D8Hjybk3fL1nHA6pt1mKlQo8Cfwg5mZHqKXMPnd7UKi5oLkZcRfKKAF0N2mW2yd9Qo /7w8CYFjaDfPIikYY8R/lL8PgGXJB0rG0NuSKoGg78/sSKcLkuqDo3dp+jUeuuC+6WkW TOCq0elnJebzZs17gcfK+UNeEzy1uFm6ZYu9o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=52FFXBKsG41Ag9E16GRJHHWhifjE7xxZZSHApN5Gj0g=; b=n/PTuMRktVMhePWjR+VJv5TFtt01U83egcYXlWJixOqrkwVe1tpGOnGrFV6aQV7O3p NLtgo9eMHNN265FXjRcil1EM4IF4QsrdVNl7JmRCoLwLW26sLloBKthmroIxQ8HXdnCo +551KUdpEDDsQUrY5+NPhsjgjLKS/BsFnVSBpw6JkThwhby7HYKXpUBPp7g9AfehAL87 GxHI9VoPY2GO2uR43tERVA/ABafKDkOAZzhgPvICZgd71Z9v6lnwGZyr/foNJ42TKN8x vxd2uYqx7W+NtWQz17WxvKEw4j1jSD35eKbNcLvtT2q98xpZPNxuxxLRCS6fYqrf47Pq IzWA== MIME-Version: 1.0 Received: by 10.50.95.167 with SMTP id dl7mr8443391igb.6.1333404517156; Mon, 02 Apr 2012 15:08:37 -0700 (PDT) Received: by 10.231.172.138 with HTTP; Mon, 2 Apr 2012 15:08:37 -0700 (PDT) In-Reply-To: <4F7A05C4.9070808@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> Date: Mon, 2 Apr 2012 15:08:37 -0700 Message-ID: From: Peter Wemm To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl+6Dl6U0+XrAn7lSqqrco8duHyQiAy46oirOfZwzRu2EaF00RVF5VwY/Y3q8/xvsYbFqGD Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 22:08:38 -0000 On Mon, Apr 2, 2012 at 1:02 PM, Richard Yao wrote: > On 04/02/12 15:37, Peter Wemm wrote: >> On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao wr= ote: >>> On 04/02/12 14:46, Peter Wemm wrote: >>>> Remember.. ASLR is a userland thing. =A0.ko files, which is what this >>>> thread is about, already use random address layout. =A0When you do a >>>> "kldload virtio.ko", you have no way to predict what address it will >>>> be loaded at. =A0And you don't even have access to the addresses. >>>> >>>> Of course if you want to talk about ASLR and userland .so files then >>>> that's an entirely different thing. =A0But this thread is about your >>>> tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. >>>> >>> >>> The PaX project's patches to the Linux kernel include kernel stack >>> randomization. The Gentoo Hardened project makes use of this in their >>> fork of the Linux kernel. >>> >> >> I looked at their code, and their description here: >> http://pax.grsecurity.net/docs/randkstack.txt >> >> Of note: >> "pax_randomize_kstack() gathers entropy from the rdtsc instruction >> (read time stamp counter) and applies it to bits 2-6 of the kernel >> stack pointer. This means that 5 bits are randomized providing a >> maximum shift of 128 bytes - this was deemed safe enough to not cause >> kernel stack overflows =A0yet give enough randomness to deter >> guessing/brute forcing attempts." >> >> This has nothing to do with the DT_TEXTREL in .ko that this thread is >> about and has no bearing on ASLR in any way. > > There are plenty of techniques employed to do ASLR by both the upstream > Linux kernel and the PaX patches to it. I only needed to state one to > prove that you were wrong about ASLR being exclusive to userland. ASLR is a generic term for a worthwhile goal - to raise the difficulty bar for an attacker to do something meaningful when they find a vulnerability that leads to the ability to inject code. There's people actively working on this in FreeBSD, but it has nothing to do with the DT_TEXTREL in an i386 .ko file. I wasn't the one who brought up ASLR, you keep bringing it up without a single DETAIL about why it's relevant. And then dismissing all of the details we provide to explain, in detail, why DT_TEXTREL on a .ko file has nothing to do with ASLR. > If the QA checks had been triggered for an out-of-tree Linux kernel > module, the Gentoo developers would consider it to be a bug. I have > verified this with the Gentoo Hardened developers. Furthermore, they > confirmed that text relocations in out-of-tree kernel modules would > negatively affect ASLR. I don't believe you. The way I see it, either: 1) you asked the wrong people who are as misguided as you are, or 2) you told them what they'd need to hear in order to arrive at the conclusion you want, or 3) you're making it up. I find it hard to believe that seasoned folks who wrote the excellently detailed 'how to fix' page for USERLAND libraries at http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml would make such a colossal mistake. If such an opinion was actually expressed to you, I think its far more likely it was based on a lack of working knowledge of what a freebsd .ko file is and how its used, or based on misinformation from you. Or you asked the wrong people. A http url link to the mailing list archives would be greatly appreciated, so I can find out exactly what the source of this insanity is. > My original email to the list asked if this was an issue in FreeBSD. > That question had been answered. Yes, it has been answered. No, not a bug, not a security issue, and not even the slightest cause for concern in any way, and does not in any way interfere with ASLR type goals. > However, people went ballistic upon the > mere presence of my question, so I assured them that if I ever found > time to write exploit code, I would do full disclosure to ensure that > this issue was fixed. That's akin to saying: "I'm going to drown your neighbor's cousin's daugher's pet kitten if you don't put a better muffler on your car." Nobody's disputing that ASLR is a worthwhile thing. What we're disputing is your unfounded, unsupported assertion that a DT_TEXTREL is a cause for concern in a kernel module. What people reacted to was your stubborn unwillingness to accept that you were wrong when you were told you were wrong by something approaching six different people now, with explicit details about how you were wrong. "Because I said so" isn't a valid rebuttal. > However, there could be unknown exploits in the wild that would be > killed by ASLR in the wild. Ah, here we go again. You bring up ASLR again. I find it hard to believe your "I might write an exploit" threat to be credible when you can't provide any details and don't seem to be able to demonstrate understanding of any of the basic concepts. Repeat: ASLR is good. But your DT_TEXTREL bug report in a .ko file is not a bug and has nothing to do with ASLR in any way, shape, form, variant or technique. Your tools are for USERLAND shared libraries, and a .ko file not a USERLAND shared library. There's a multitude of things to complain about in the .ko file loader, but DT_TEXTREL is not one of them. The FreeBSD project isn't in the habit of making changes based on vague hand-waving, fear mongering and threats in the face of detailed, considered reason why it shouldn't be changed. I'm happy to talk details about why it's a problem, but I don't believe they exist. I'm happy to be proven wrong on that. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 23:27: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 6F20810656A5; Mon, 2 Apr 2012 23:27: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 284458FC16; Mon, 2 Apr 2012 23:27: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; 02 Apr 2012 16:27:20 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q32NRDLg070100; Mon, 2 Apr 2012 16:27:13 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q32NRDG7070099; Mon, 2 Apr 2012 16:27:13 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201204022327.q32NRDG7070099@ambrisko.com> In-Reply-To: To: jhb@freebsd.org Date: Mon, 2 Apr 2012 16:27:13 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2012 23:27:14 -0000 Doug Ambrisko writes: | John Baldwin writes: | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: | | > Sean Bruno writes: | | > | Noting a failure to attach to the onboard IPMI controller with this dell | | > | R815. Not sure what to start poking at and thought I'd though this over | | > | here for comment. | | > | | | > | -bash-4.2$ dmesg |grep ipmi | | > | ipmi0: KCS mode found at io 0xca8 on acpi | | > | ipmi1: on isa0 | | > | device_attach: ipmi1 attach returned 16 | | > | ipmi1: on isa0 | | > | device_attach: ipmi1 attach returned 16 | | > | ipmi0: Timed out waiting for GET_DEVICE_ID | | > | | > I've run into this recently. A quick hack to fix it is: | | > | | > Index: ipmi.c | | > =================================================================== | | > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v | | > retrieving revision 1.14 | | > diff -u -p -r1.14 ipmi.c | | > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 | | > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 | | > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) | | > if (error == EWOULDBLOCK) { | | > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); | | > ipmi_free_request(req); | | > - return; | | > } else if (error) { | | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); | | > ipmi_free_request(req); | | > | | > The issue is that the wakeup doesn't actually wake up the msleep | | > in ipmi_submit_driver_request. The error being reported is that | | > the msleep timed out. This doesn't seem to be critical problem | | > since after this things seemed to work work. I saw this on 9.X. | | > Haven't seen it on 8.2. Not sure about -current. | | > | | > It doesn't happen on all machines. | | | | Hmm, are you seeing the KCS thread manage the request but the wakeup() is | | lost? | | It was a couple of weeks ago that I played with it. I put printf's | around the msleep and wakeup. I saw the wakeup called but the sleep | not get it. I can try the test again later today. Right now my main | work machine is recovering from a power outage. This was with 9.0 | when I first saw it. This issue seems to only happen at boot time. | If I kldload the module after the system is booted then it seems to work | okay. The KCS part was working fine and got the data okay from the | request. I haven't seen or heard any issues with 8.2. With -current I patched ipmi.c with: Index: ipmi.c =================================================================== --- ipmi.c (revision 233806) +++ ipmi.c (working copy) @@ -523,7 +523,11 @@ * waiter that we awaken. */ if (req->ir_owner == NULL) +{ +device_printf(sc->ipmi_dev, "DEBUG %s %d before wakeup %d\n",__FUNCTION__,__LINE__,ticks); wakeup(req); +device_printf(sc->ipmi_dev, "DEBUG %s %d after wakeup %d\n",__FUNCTION__,__LINE__,ticks); +} else { dev = req->ir_owner; TAILQ_INSERT_TAIL(&dev->ipmi_completed_requests, req, ir_link); @@ -543,7 +547,11 @@ IPMI_LOCK(sc); error = sc->ipmi_enqueue_request(sc, req); if (error == 0) +{ +device_printf(sc->ipmi_dev, "DEBUG %s %d before msleep %d\n",__FUNCTION__,__LINE__,ticks); error = msleep(req, &sc->ipmi_lock, 0, "ipmireq", timo); +device_printf(sc->ipmi_dev, "DEBUG %s %d after msleep %d\n",__FUNCTION__,__LINE__,ticks); +} if (error == 0) error = req->ir_error; IPMI_UNLOCK(sc); @@ -695,8 +703,11 @@ error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT); if (error == EWOULDBLOCK) { device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); + printf("DJA\n"); +/* ipmi_free_request(req); return; +*/ } else if (error) { device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); ipmi_free_request(req); and get # dmesg | grep ipmi ipmi0: KCS mode found at io 0xca8 on acpi ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323 ipmi0: Timed out waiting for GET_DEVICE_ID ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 6503 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6620 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6682 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6742 ... # sysctl kern.clockrate kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 } # The 6000+ ticks before calling wakeup looks to be a problem. Maybe a few things are getting delayed for a while. On a working machine I see: # dmesg | grep ipmi ipmi0: port 0xca2,0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 1 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 397 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 464 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 539 ipmi0: IPMI device rev. 1, firmware rev. 2.03, version 2.0 ... if I kldunload/kldload on the problem machine I see: ipmi0: KCS mode found at io 0xca8 on acpi ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 675117 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 675189 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 675253 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 675315 ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 ... Another machine that fails: ipmi0: port 0xca8,0xcac on acpi0 ipmi0: KCS mode found at io 0xca8 on acpi ipmi0: KCS error: ff ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 0 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3046 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3168 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3234 ipmi0: Timed out waiting for GET_DEVICE_ID ipmi0: IPMI device rev. 0, firmware rev. 1.70, version 1.5 ... FWIW, Dell machine are tending to have this problem. I wonder, if the multiple probes are messing something up. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 2 23:49:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C411065672 for ; Mon, 2 Apr 2012 23:49:32 +0000 (UTC) (envelope-from www-data@xt4.reefnet.co.uk) Received: from xt4.reefnet.co.uk (xt4.reefnet.co.uk [82.113.154.248]) by mx1.freebsd.org (Postfix) with ESMTP id B8AFE8FC0A for ; Mon, 2 Apr 2012 23:49:32 +0000 (UTC) Received: by xt4.reefnet.co.uk (Postfix, from userid 33) id 0EAC6364D6; Mon, 2 Apr 2012 23:43:29 +0000 (UTC) To: stable@freebsd.org From: Baris B kaya.. MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20120402234329.0EAC6364D6@xt4.reefnet.co.uk> Date: Mon, 2 Apr 2012 23:43:29 +0000 (UTC) Cc: Subject: Did You Get My last Email? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barisb1950@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:49:33 -0000 Good Day , I pray my mail gets to you this time. I'd write you on two occasions concerning your assistance to help certify a piece of document due to some similarities in location with the supposed care-taker to enable a safe transfer of securities proceeds out of Turkey. Please let me know if you were in receipt of my previous communication emailed to you. Further information will be forwarded to you on receipt of your confirmation. Thank you, Mr. Baris B Kaya. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 01:55:21 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 00F65106566B; Tue, 3 Apr 2012 01:55:21 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 668AE8FC0C; Tue, 3 Apr 2012 01:55:20 +0000 (UTC) Received: by iahk25 with SMTP id k25so6709415iah.13 for ; Mon, 02 Apr 2012 18:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=dBhNqemsj0QgkRqHe3MZpOPNXtMNY4QK7m5zDDJzUV4=; b=gXDhgNiZek6ggExdCbiSR4XXa9s4JIbWaLuOAy3i5ywGNMsCczexvwceQ7mWjdH/99 cRKZO/6gh1/mdH1Jtn7iaKkC6ZVkL1jKe6Ly5f8Ogn60mlBcTxNRToq+hTCmXObghMcJ PPZX/67cMZkVC0yOkMLKiYWSCU66vB/mw420JArBC7uPjdmlwqVWCbazYXvbjcdLEGTv UvDePfRVqt/q/4XmrlypZuSGzNPUWpBmGVC2DCpuS2HLJPbbd34IpVpLZu8pTyVdXCCN aAxncoAnWcyrJAA3C+iOdGhZ/T1MpCOIzsxwxs0rbutSwj5FXLF3M1zmd0fy/P3nceSx M5cQ== MIME-Version: 1.0 Received: by 10.50.106.132 with SMTP id gu4mr131570igb.59.1333418119817; Mon, 02 Apr 2012 18:55:19 -0700 (PDT) Sender: infofarmer@gmail.com Received: by 10.50.109.197 with HTTP; Mon, 2 Apr 2012 18:55:19 -0700 (PDT) Date: Tue, 3 Apr 2012 05:55:19 +0400 X-Google-Sender-Auth: ne2b7kgt0GGQ-KNYLFV10t3pvBY Message-ID: From: Andrew Pantyukhin To: marius@FreeBSD.org, Kashyap Desai Content-Type: text/plain; charset=UTF-8 Cc: stable@freebsd.org, zvqops@di.vc, ken@FreeBSD.org Subject: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 01:55:21 -0000 Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0: class=0x010000 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Best, Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 08:29:36 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 763A71065670; Tue, 3 Apr 2012 08:29:36 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id F3A688FC1D; Tue, 3 Apr 2012 08:29:35 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q338TSfx047238; Tue, 3 Apr 2012 10:29:28 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q338TR7W047237; Tue, 3 Apr 2012 10:29:27 +0200 (CEST) (envelope-from marius) Date: Tue, 3 Apr 2012 10:29:27 +0200 From: Marius Strobl To: Andrew Pantyukhin Message-ID: <20120403082927.GH93449@alchemy.franken.de> References: 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: stable@FreeBSD.org, zvqops@di.vc, ken@FreeBSD.org, Kashyap Desai Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 08:29:36 -0000 On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > Hello, > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > X8ST3 motherboards for us. > > All of them are also equipped with two extra 1068 controllers, which > are detected fine. Reverting to r231518 with otherwise latest stable > kernel works around the problem. > > The issue is still there at r233425. > > Here's the disappearing device: > > mpt2@pci0:5:0:0: class=0x010000 card=0x10001000 chip=0x00591000 > rev=0x08 hdr=0x00 > vendor = 'LSI Logic / Symbios Logic' > device = 'MegaRAID SAS 8208ELP/8208ELP' > class = mass storage > subclass = SCSI > Should be fixed in r233827. Marius From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 09:09:15 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 553A9106566C for ; Tue, 3 Apr 2012 09:09:15 +0000 (UTC) (envelope-from streamsendbouncer@me-ss2-T4CqVp.mailengine1.com) Received: from me-ss2-T4CqVp.mailengine1.com (me-ss2-T4CqVp.mailengine1.com [66.59.15.241]) by mx1.freebsd.org (Postfix) with ESMTP id BD1F28FC18 for ; Tue, 3 Apr 2012 09:09:13 +0000 (UTC) Received: by me-ss2-T4CqVp.mailengine1.com (PowerMTA(TM) v3.5r14) id hfav3i0j0qg3 for ; Tue, 3 Apr 2012 02:02:16 -0700 (envelope-from ) MIME-Version: 1.0 X-Mailer: StreamSend2 - 347829 X-Mailer-Version: 2.0 X-Mailer-Environment: production X-Report-Abuse-At: abuse@streamsend.com X-Report-Abuse-Info: It is important to please include full email headers in the report X-rpcampaign: StreamSend15956231 X-Streamsend2id: 347829+1+3807479+15956231+me-ss2-T4CqVp.mailengine1.com Date: Tue, 03 Apr 2012 02:00:21 -0700 From: "Mitchell Wells" To: stable@freebsd.org Message-ID: <200.0.0.31.1CD11787790B698.1F91B@me-ss2-T4CqVp.mailengine1.com> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Contractjobs.com - 250,000 Live Searchable Contractor CVs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 09:09:15 -0000 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 12:29:01 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 D924A106566B; Tue, 3 Apr 2012 12:29:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6FCE18FC15; Tue, 3 Apr 2012 12:29:01 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q33CSxlF048415; Tue, 3 Apr 2012 14:28:59 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q33CSwie048414; Tue, 3 Apr 2012 14:28:58 +0200 (CEST) (envelope-from marius) Date: Tue, 3 Apr 2012 14:28:58 +0200 From: Marius Strobl To: Kashyap Desai Message-ID: <20120403122858.GA48373@alchemy.franken.de> References: <20120403082927.GH93449@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120403082927.GH93449@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, zvqops@di.vc, ken@freebsd.org, Andrew Pantyukhin Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 12:29:01 -0000 On Tue, Apr 03, 2012 at 10:29:27AM +0200, Marius Strobl wrote: > On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > > Hello, > > > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > > X8ST3 motherboards for us. > > > > All of them are also equipped with two extra 1068 controllers, which > > are detected fine. Reverting to r231518 with otherwise latest stable > > kernel works around the problem. > > > > The issue is still there at r233425. > > > > Here's the disappearing device: > > > > mpt2@pci0:5:0:0: class=0x010000 card=0x10001000 chip=0x00591000 > > rev=0x08 hdr=0x00 > > vendor = 'LSI Logic / Symbios Logic' > > device = 'MegaRAID SAS 8208ELP/8208ELP' > > class = mass storage > > subclass = SCSI > > > > Should be fixed in r233827. > Btw., Kashyap, could you please trigger LSI to update their mpi_cnfg.h to include all the device IDs that actually should be handled by MPT drivers. The FreeBSD mpt(4) additionally knows about the devices below, which based on the fact they are not probed by the Linux counterpart and are not found in PCI ID lists might not even exist in the wild, or as in the above case, still might miss some actual devices not currently found in mpi_cnfg.h. #define MPI_MANUFACTPAGE_DEVICEID_FC909_FB 0x0620 #define MPI_MANUFACTPAGE_DEVICEID_FC919_LAN_FB 0x0625 #define MPI_MANUFACTPAGE_DEVICEID_FC929_LAN_FB 0x0623 #define MPI_MANUFACTPAGE_DEVICEID_FC929X_LAN_FB 0x0627 #define MPI_MANUFACTPAGE_DEVICEID_FC919X_LAN_FB 0x0629 #define MPI_MANUFACTPAGE_DEVID_SAS1068A_FB 0x0055 #define MPI_MANUFACTPAGE_DEVID_SAS1068E_FB 0x0059 #define MPI_MANUFACTPAGE_DEVID_SAS1078DE_FB 0x007C Marius From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 12:34:50 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 4A545106566C; Tue, 3 Apr 2012 12:34:50 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from psmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by mx1.freebsd.org (Postfix) with ESMTP id 787438FC0A; Tue, 3 Apr 2012 12:34:49 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKT3ruaIk/+1EwoFaPaj5BHPlXFeO8c6BL@postini.com; Tue, 03 Apr 2012 05:34:49 PDT Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Apr 2012 08:40:06 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Apr 2012 08:34:47 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Tue, 3 Apr 2012 18:04:44 +0530 From: "Desai, Kashyap" To: Marius Strobl Date: Tue, 3 Apr 2012 18:04:43 +0530 Thread-Topic: r232411 breaks onboard 1068 detection Thread-Index: Ac0RlV2G2Ktuhz0PRDC47TGO5d/5dwAADGjA Message-ID: References: <20120403082927.GH93449@alchemy.franken.de> <20120403122858.GA48373@alchemy.franken.de> In-Reply-To: <20120403122858.GA48373@alchemy.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stable@freebsd.org" , "zvqops@di.vc" , "ken@freebsd.org" , Andrew Pantyukhin , "McConnell, Stephen" Subject: RE: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 12:34:50 -0000 > -----Original Message----- > From: Marius Strobl [mailto:marius@alchemy.franken.de] > Sent: Tuesday, April 03, 2012 5:59 PM > To: Desai, Kashyap > Cc: stable@freebsd.org; zvqops@di.vc; ken@freebsd.org; Andrew Pantyukhin > Subject: Re: r232411 breaks onboard 1068 detection >=20 > On Tue, Apr 03, 2012 at 10:29:27AM +0200, Marius Strobl wrote: > > On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > > > Hello, > > > > > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > > > X8ST3 motherboards for us. > > > > > > All of them are also equipped with two extra 1068 controllers, which > > > are detected fine. Reverting to r231518 with otherwise latest stable > > > kernel works around the problem. > > > > > > The issue is still there at r233425. > > > > > > Here's the disappearing device: > > > > > > mpt2@pci0:5:0:0: class=3D0x010000 card=3D0x10001000 > chip=3D0x00591000 > > > rev=3D0x08 hdr=3D0x00 > > > vendor =3D 'LSI Logic / Symbios Logic' > > > device =3D 'MegaRAID SAS 8208ELP/8208ELP' > > > class =3D mass storage > > > subclass =3D SCSI > > > > > > > Should be fixed in r233827. > > >=20 > Btw., Kashyap, could you please trigger LSI to update their mpi_cnfg.h > to include all the device IDs that actually should be handled by MPT > drivers. The FreeBSD mpt(4) additionally knows about the devices below, > which based on the fact they are not probed by the Linux counterpart > and are not found in PCI ID lists might not even exist in the wild, > or as in the above case, still might miss some actual devices not > currently found in mpi_cnfg.h. >=20 > #define MPI_MANUFACTPAGE_DEVICEID_FC909_FB 0x0620 > #define MPI_MANUFACTPAGE_DEVICEID_FC919_LAN_FB 0x0625 > #define MPI_MANUFACTPAGE_DEVICEID_FC929_LAN_FB 0x0623 > #define MPI_MANUFACTPAGE_DEVICEID_FC929X_LAN_FB 0x0627 > #define MPI_MANUFACTPAGE_DEVICEID_FC919X_LAN_FB 0x0629 > #define MPI_MANUFACTPAGE_DEVID_SAS1068A_FB 0x0055 > #define MPI_MANUFACTPAGE_DEVID_SAS1068E_FB 0x0059 > #define MPI_MANUFACTPAGE_DEVID_SAS1078DE_FB 0x007C Hi Marius, This is very critical part of discussion and I do not have real= ly best answer, because I don't know the history behind it. Added Steve M f= or better help. Also I have contacted Megaraid Driver team to respond what is device id 0x0= 059 ?=20 FYI: I am referring pciid from below link.=20 http://pciids.sourceforge.net/v2.2/pci.ids >=20 > Marius >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 12:55:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 001AB106564A; Tue, 3 Apr 2012 12:55:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B6ABB8FC1A; Tue, 3 Apr 2012 12:55:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2C41FB95E; Tue, 3 Apr 2012 08:55:44 -0400 (EDT) From: John Baldwin To: Doug Ambrisko Date: Tue, 3 Apr 2012 08:51:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201204022327.q32NRDG7070099@ambrisko.com> In-Reply-To: <201204022327.q32NRDG7070099@ambrisko.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204030851.43785.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Apr 2012 08:55:44 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 12:55:45 -0000 On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: > Doug Ambrisko writes: > | John Baldwin writes: > | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: > | | > Sean Bruno writes: > | | > | Noting a failure to attach to the onboard IPMI controller with this dell > | | > | R815. Not sure what to start poking at and thought I'd though this over > | | > | here for comment. > | | > | > | | > | -bash-4.2$ dmesg |grep ipmi > | | > | ipmi0: KCS mode found at io 0xca8 on acpi > | | > | ipmi1: on isa0 > | | > | device_attach: ipmi1 attach returned 16 > | | > | ipmi1: on isa0 > | | > | device_attach: ipmi1 attach returned 16 > | | > | ipmi0: Timed out waiting for GET_DEVICE_ID > | | > > | | > I've run into this recently. A quick hack to fix it is: > | | > > | | > Index: ipmi.c > | | > =================================================================== > | | > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v > | | > retrieving revision 1.14 > | | > diff -u -p -r1.14 ipmi.c > | | > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 > | | > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 > | | > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) > | | > if (error == EWOULDBLOCK) { > | | > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); > | | > ipmi_free_request(req); > | | > - return; > | | > } else if (error) { > | | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); > | | > ipmi_free_request(req); > | | > > | | > The issue is that the wakeup doesn't actually wake up the msleep > | | > in ipmi_submit_driver_request. The error being reported is that > | | > the msleep timed out. This doesn't seem to be critical problem > | | > since after this things seemed to work work. I saw this on 9.X. > | | > Haven't seen it on 8.2. Not sure about -current. > | | > > | | > It doesn't happen on all machines. > | | > | | Hmm, are you seeing the KCS thread manage the request but the wakeup() is > | | lost? > | > | It was a couple of weeks ago that I played with it. I put printf's > | around the msleep and wakeup. I saw the wakeup called but the sleep > | not get it. I can try the test again later today. Right now my main > | work machine is recovering from a power outage. This was with 9.0 > | when I first saw it. This issue seems to only happen at boot time. > | If I kldload the module after the system is booted then it seems to work > | okay. The KCS part was working fine and got the data okay from the > | request. I haven't seen or heard any issues with 8.2. > > With -current I patched ipmi.c with: > Index: ipmi.c > =================================================================== > --- ipmi.c (revision 233806) > +++ ipmi.c (working copy) > @@ -523,7 +523,11 @@ > * waiter that we awaken. > */ > if (req->ir_owner == NULL) > +{ > +device_printf(sc->ipmi_dev, "DEBUG %s %d before wakeup %d\n",__FUNCTION__,__LINE__,ticks); > wakeup(req); > +device_printf(sc->ipmi_dev, "DEBUG %s %d after wakeup %d\n",__FUNCTION__,__LINE__,ticks); > +} > else { > dev = req->ir_owner; > TAILQ_INSERT_TAIL(&dev->ipmi_completed_requests, req, ir_link); > @@ -543,7 +547,11 @@ > IPMI_LOCK(sc); > error = sc->ipmi_enqueue_request(sc, req); > if (error == 0) > +{ > +device_printf(sc->ipmi_dev, "DEBUG %s %d before msleep %d\n",__FUNCTION__,__LINE__,ticks); > error = msleep(req, &sc->ipmi_lock, 0, "ipmireq", timo); > +device_printf(sc->ipmi_dev, "DEBUG %s %d after msleep %d\n",__FUNCTION__,__LINE__,ticks); > +} > if (error == 0) > error = req->ir_error; > IPMI_UNLOCK(sc); > @@ -695,8 +703,11 @@ > error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT); > if (error == EWOULDBLOCK) { > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); > + printf("DJA\n"); > +/* > ipmi_free_request(req); > return; > +*/ > } else if (error) { > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); > ipmi_free_request(req); > > and get > # dmesg | grep ipmi > ipmi0: KCS mode found at io 0xca8 on acpi > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201 > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263 > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323 Actually, can you compile with: options KTR options KTR_COMPILE=KTR_SCHED options KTR_MASK=KTR_SCHED and then add a temporary hack to ipmi.c to set ktr_mask to 0 after ipmi_submit_driver_request() returns in ipmi_startup()? You can then use 'ktrdump -ct' after boot to capture a log of what the scheduler did including if it timed out the sleep, etc. I think this would be useful for figuring out what went wrong. It does seem that it timed out after 3 seconds. Also, it doesn't seem clear if pehaps the IPMI worker thread was stalled behind another thread during boot. The KTR traces would show us that if so. I don't think the ipmi1 probe can cause the problem (it bails out right away and shouldn't be touching any hardware state). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 13:33:52 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 D6742106566B for ; Tue, 3 Apr 2012 13:33:52 +0000 (UTC) (envelope-from prvs=04409cda91=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 606298FC19 for ; Tue, 3 Apr 2012 13:33:52 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SF3rr-000Kaz-Jz for freebsd-stable@freebsd.org; Tue, 03 Apr 2012 15:33:51 +0200 Date: Tue, 3 Apr 2012 15:33:51 +0200 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20120403133351.GY65313@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20120330083830.GB65313@e-Gitt.NET> <4F761F4B.90409@p6m7g8.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c3bfwLpm8qysLVxt" Content-Disposition: inline In-Reply-To: <4F761F4B.90409@p6m7g8.com> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 13:33:52 -0000 --c3bfwLpm8qysLVxt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Mar 30, 2012 at 09:02:03PM +0000, Philip M. Gollucci wrote: > http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.ht= ml >=20 > Same issue different thread. Different software. >=20 > Its not NFS, its ZFS. >=20 > I don't really have a place to try it on 8.2, but my hunch from things > I've done rather similarly which don't cause tell me its a new issue in > 9.0, though I won't swear by that. So we're having different issues. I could boil it down to NFS=20 definitely: If I change back to the old NFS server the problem=20 immediately stops. I'm currently checking, where in the new NFS server might be the problem=20 (together with people who have a deeper understanding of what's=20 happening). - Oliver --=20 | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | --c3bfwLpm8qysLVxt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk96/D8ACgkQiqtMdzjafymtrgCguwhXnBFt6s4v/VOGgvZvLloN W4QAn2XzFu9fPokotbdKlWWTl+XNgDBc =h03x -----END PGP SIGNATURE----- --c3bfwLpm8qysLVxt-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 15:13:20 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 D3260106566C; Tue, 3 Apr 2012 15:13:20 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 98DC58FC14; Tue, 3 Apr 2012 15:13:20 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q33FDFAs007040; Tue, 3 Apr 2012 09:13:15 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q33FDEcg007039; Tue, 3 Apr 2012 09:13:14 -0600 (MDT) (envelope-from ken) Date: Tue, 3 Apr 2012 09:13:14 -0600 From: "Kenneth D. Merry" To: Marius Strobl Message-ID: <20120403151314.GA7014@nargothrond.kdm.org> References: <20120403082927.GH93449@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120403082927.GH93449@alchemy.franken.de> User-Agent: Mutt/1.4.2i Cc: Andrew Pantyukhin , zvqops@di.vc, re@FreeBSD.org, Kashyap Desai , stable@FreeBSD.org Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 15:13:20 -0000 On Tue, Apr 03, 2012 at 10:29:27 +0200, Marius Strobl wrote: > On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > > Hello, > > > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > > X8ST3 motherboards for us. > > > > All of them are also equipped with two extra 1068 controllers, which > > are detected fine. Reverting to r231518 with otherwise latest stable > > kernel works around the problem. > > > > The issue is still there at r233425. > > > > Here's the disappearing device: > > > > mpt2@pci0:5:0:0: class=0x010000 card=0x10001000 chip=0x00591000 > > rev=0x08 hdr=0x00 > > vendor = 'LSI Logic / Symbios Logic' > > device = 'MegaRAID SAS 8208ELP/8208ELP' > > class = mass storage > > subclass = SCSI > > > > Should be fixed in r233827. We should get this into 8.3 if that is still possible. Otherwise folks with these machines will not be able to boot 8.3. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 15:17:23 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 D67FB106564A; Tue, 3 Apr 2012 15:17:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8618FC16; Tue, 3 Apr 2012 15:17:23 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q33FHLEM049039; Tue, 3 Apr 2012 17:17:21 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q33FHL52049038; Tue, 3 Apr 2012 17:17:21 +0200 (CEST) (envelope-from marius) Date: Tue, 3 Apr 2012 17:17:21 +0200 From: Marius Strobl To: "Kenneth D. Merry" Message-ID: <20120403151721.GJ93449@alchemy.franken.de> References: <20120403082927.GH93449@alchemy.franken.de> <20120403151314.GA7014@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120403151314.GA7014@nargothrond.kdm.org> User-Agent: Mutt/1.4.2.3i Cc: Andrew Pantyukhin , zvqops@di.vc, re@FreeBSD.org, Kashyap Desai , stable@FreeBSD.org Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 15:17:23 -0000 On Tue, Apr 03, 2012 at 09:13:14AM -0600, Kenneth D. Merry wrote: > On Tue, Apr 03, 2012 at 10:29:27 +0200, Marius Strobl wrote: > > On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > > > Hello, > > > > > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > > > X8ST3 motherboards for us. > > > > > > All of them are also equipped with two extra 1068 controllers, which > > > are detected fine. Reverting to r231518 with otherwise latest stable > > > kernel works around the problem. > > > > > > The issue is still there at r233425. > > > > > > Here's the disappearing device: > > > > > > mpt2@pci0:5:0:0: class=0x010000 card=0x10001000 chip=0x00591000 > > > rev=0x08 hdr=0x00 > > > vendor = 'LSI Logic / Symbios Logic' > > > device = 'MegaRAID SAS 8208ELP/8208ELP' > > > class = mass storage > > > subclass = SCSI > > > > > > > Should be fixed in r233827. > > We should get this into 8.3 if that is still possible. Otherwise folks > with these machines will not be able to boot 8.3. > I'll try but based on previous experiences it's just too late in the release cycle. Marius From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 16:37:57 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 5F22F106564A; Tue, 3 Apr 2012 16:37:57 +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 3058F8FC12; Tue, 3 Apr 2012 16:37:57 +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; 03 Apr 2012 09:37:57 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q33GboQY040792; Tue, 3 Apr 2012 09:37:50 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q33GboNt040791; Tue, 3 Apr 2012 09:37:50 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201204031637.q33GboNt040791@ambrisko.com> In-Reply-To: <201204030851.43785.jhb@freebsd.org> To: John Baldwin Date: Tue, 3 Apr 2012 09:37:50 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@freebsd.org Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 16:37:57 -0000 John Baldwin writes: | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: | > Doug Ambrisko writes: | > | John Baldwin writes: | > | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: | > | | > Sean Bruno writes: | > | | > | Noting a failure to attach to the onboard IPMI controller with this | dell | > | | > | R815. Not sure what to start poking at and thought I'd though this | over | > | | > | here for comment. | > | | > | | > | | > | -bash-4.2$ dmesg |grep ipmi | > | | > | ipmi0: KCS mode found at io 0xca8 on acpi | > | | > | ipmi1: on isa0 | > | | > | device_attach: ipmi1 attach returned 16 | > | | > | ipmi1: on isa0 | > | | > | device_attach: ipmi1 attach returned 16 | > | | > | ipmi0: Timed out waiting for GET_DEVICE_ID | > | | > | > | | > I've run into this recently. A quick hack to fix it is: | > | | > | > | | > Index: ipmi.c | > | | > =================================================================== | > | | > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v | > | | > retrieving revision 1.14 | > | | > diff -u -p -r1.14 ipmi.c | > | | > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 | > | | > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 | > | | > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) | > | | > if (error == EWOULDBLOCK) { | > | | > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); | > | | > ipmi_free_request(req); | > | | > - return; | > | | > } else if (error) { | > | | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); | > | | > ipmi_free_request(req); | > | | > | > | | > The issue is that the wakeup doesn't actually wake up the msleep | > | | > in ipmi_submit_driver_request. The error being reported is that | > | | > the msleep timed out. This doesn't seem to be critical problem | > | | > since after this things seemed to work work. I saw this on 9.X. | > | | > Haven't seen it on 8.2. Not sure about -current. | > | | > | > | | > It doesn't happen on all machines. | > | | | > | | Hmm, are you seeing the KCS thread manage the request but the wakeup() | is | > | | lost? | > | | > | It was a couple of weeks ago that I played with it. I put printf's | > | around the msleep and wakeup. I saw the wakeup called but the sleep | > | not get it. I can try the test again later today. Right now my main | > | work machine is recovering from a power outage. This was with 9.0 | > | when I first saw it. This issue seems to only happen at boot time. | > | If I kldload the module after the system is booted then it seems to work | > | okay. The KCS part was working fine and got the data okay from the | > | request. I haven't seen or heard any issues with 8.2. | > | > With -current I patched ipmi.c with: | > Index: ipmi.c | > =================================================================== | > --- ipmi.c (revision 233806) | > +++ ipmi.c (working copy) | > @@ -523,7 +523,11 @@ | > * waiter that we awaken. | > */ | > if (req->ir_owner == NULL) | > +{ | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before wakeup | %d\n",__FUNCTION__,__LINE__,ticks); | > wakeup(req); | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after wakeup | %d\n",__FUNCTION__,__LINE__,ticks); | > +} | > else { | > dev = req->ir_owner; | > TAILQ_INSERT_TAIL(&dev->ipmi_completed_requests, req, | ir_link); | > @@ -543,7 +547,11 @@ | > IPMI_LOCK(sc); | > error = sc->ipmi_enqueue_request(sc, req); | > if (error == 0) | > +{ | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before msleep | %d\n",__FUNCTION__,__LINE__,ticks); | > error = msleep(req, &sc->ipmi_lock, 0, "ipmireq", timo); | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after msleep | %d\n",__FUNCTION__,__LINE__,ticks); | > +} | > if (error == 0) | > error = req->ir_error; | > IPMI_UNLOCK(sc); | > @@ -695,8 +703,11 @@ | > error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT); | > if (error == EWOULDBLOCK) { | > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); | > + printf("DJA\n"); | > +/* | > ipmi_free_request(req); | > return; | > +*/ | > } else if (error) { | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); | > ipmi_free_request(req); | > | > and get | > # dmesg | grep ipmi | > ipmi0: KCS mode found at io 0xca8 on acpi | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201 | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263 | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323 | | Actually, can you compile with: | | options KTR | options KTR_COMPILE=KTR_SCHED | options KTR_MASK=KTR_SCHED | | and then add a temporary hack to ipmi.c to set ktr_mask to 0 after | ipmi_submit_driver_request() returns in ipmi_startup()? You can | then use 'ktrdump -ct' after boot to capture a log of what the scheduler | did including if it timed out the sleep, etc. I think this would be | useful for figuring out what went wrong. It does seem that it timed | out after 3 seconds. Assuming I didn't mess up, the log should be at: http://people.freebsd.org/~ambrisko/ipmi_ktr_dump.txt again, I using ipmi(4) as module loaded via the loader. | Also, it doesn't seem clear if pehaps the IPMI worker thread was | stalled behind another thread during boot. The KTR traces would show | us that if so. | | I don't think the ipmi1 probe can cause the problem (it bails out right | away and shouldn't be touching any hardware state). Agreed, but computers like to prove me wrong. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 21:52: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 66A66106564A; Tue, 3 Apr 2012 21:52:24 +0000 (UTC) (envelope-from Stephen.McConnell@lsi.com) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by mx1.freebsd.org (Postfix) with ESMTP id BA47E8FC16; Tue, 3 Apr 2012 21:52:23 +0000 (UTC) Received: from cosedge01.lsi.com ([192.19.220.66]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKT3txELAf+85r/LK28EE97/pd1ybV98Iv@postini.com; Tue, 03 Apr 2012 14:52:24 PDT Received: from coscas03.lsi.com (135.142.2.56) by COSEDGE01.lsi.com (192.19.220.66) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Apr 2012 15:50:34 -0600 Received: from cosmail03.lsi.com ([172.21.36.37]) by coscas03.lsi.com ([fe80::68f1:97ad:d56e:135a%14]) with mapi; Tue, 3 Apr 2012 15:52:15 -0600 From: "McConnell, Stephen" To: "Desai, Kashyap" , Marius Strobl Date: Tue, 3 Apr 2012 15:52:14 -0600 Thread-Topic: r232411 breaks onboard 1068 detection Thread-Index: Ac0RlV2G2Ktuhz0PRDC47TGO5d/5dwAADGjAABMo6WA= Message-ID: References: <20120403082927.GH93449@alchemy.franken.de> <20120403122858.GA48373@alchemy.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stable@freebsd.org" , "zvqops@di.vc" , "ken@freebsd.org" , Andrew Pantyukhin Subject: RE: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 21:52:24 -0000 Marius, Since the 0x59 device is a MegaRAID device, shouldn't you be using the Mega= RAID driver. Why is the MPT driver being used in this case? The problem i= s that the MPT driver was wrongly attaching to some MegaRAID controllers an= d that was causing conflict problems, so that was fixed by removing MegaRAI= D ID's from the MPT driver. Steve McConnell -----Original Message----- From: Desai, Kashyap=20 Sent: Tuesday, April 03, 2012 6:35 AM To: Marius Strobl Cc: stable@freebsd.org; zvqops@di.vc; ken@freebsd.org; Andrew Pantyukhin; M= cConnell, Stephen Subject: RE: r232411 breaks onboard 1068 detection > -----Original Message----- > From: Marius Strobl [mailto:marius@alchemy.franken.de] > Sent: Tuesday, April 03, 2012 5:59 PM > To: Desai, Kashyap > Cc: stable@freebsd.org; zvqops@di.vc; ken@freebsd.org; Andrew=20 > Pantyukhin > Subject: Re: r232411 breaks onboard 1068 detection >=20 > On Tue, Apr 03, 2012 at 10:29:27AM +0200, Marius Strobl wrote: > > On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > > > Hello, > > > > > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > > > X8ST3 motherboards for us. > > > > > > All of them are also equipped with two extra 1068 controllers,=20 > > > which are detected fine. Reverting to r231518 with otherwise=20 > > > latest stable kernel works around the problem. > > > > > > The issue is still there at r233425. > > > > > > Here's the disappearing device: > > > > > > mpt2@pci0:5:0:0: class=3D0x010000 card=3D0x10001000 > chip=3D0x00591000 > > > rev=3D0x08 hdr=3D0x00 > > > vendor =3D 'LSI Logic / Symbios Logic' > > > device =3D 'MegaRAID SAS 8208ELP/8208ELP' > > > class =3D mass storage > > > subclass =3D SCSI > > > > > > > Should be fixed in r233827. > > >=20 > Btw., Kashyap, could you please trigger LSI to update their mpi_cnfg.h=20 > to include all the device IDs that actually should be handled by MPT=20 > drivers. The FreeBSD mpt(4) additionally knows about the devices=20 > below, which based on the fact they are not probed by the Linux=20 > counterpart and are not found in PCI ID lists might not even exist in=20 > the wild, or as in the above case, still might miss some actual=20 > devices not currently found in mpi_cnfg.h. >=20 > #define MPI_MANUFACTPAGE_DEVICEID_FC909_FB 0x0620 > #define MPI_MANUFACTPAGE_DEVICEID_FC919_LAN_FB 0x0625 > #define MPI_MANUFACTPAGE_DEVICEID_FC929_LAN_FB 0x0623 > #define MPI_MANUFACTPAGE_DEVICEID_FC929X_LAN_FB 0x0627 > #define MPI_MANUFACTPAGE_DEVICEID_FC919X_LAN_FB 0x0629 > #define MPI_MANUFACTPAGE_DEVID_SAS1068A_FB 0x0055 > #define MPI_MANUFACTPAGE_DEVID_SAS1068E_FB 0x0059 > #define MPI_MANUFACTPAGE_DEVID_SAS1078DE_FB 0x007C Hi Marius, This is very critical part of discussion and I do not have real= ly best answer, because I don't know the history behind it. Added Steve M f= or better help. Also I have contacted Megaraid Driver team to respond what is device id 0x0= 059 ?=20 FYI: I am referring pciid from below link.=20 http://pciids.sourceforge.net/v2.2/pci.ids >=20 > Marius >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 21:57:16 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A987106566B; Tue, 3 Apr 2012 21:57:16 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2258FC15; Tue, 3 Apr 2012 21:57:15 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q33LvEfS051878; Tue, 3 Apr 2012 23:57:14 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q33LvEFJ051877; Tue, 3 Apr 2012 23:57:14 +0200 (CEST) (envelope-from marius) Date: Tue, 3 Apr 2012 23:57:14 +0200 From: Marius Strobl To: "McConnell, Stephen" Message-ID: <20120403215714.GO93449@alchemy.franken.de> References: <20120403082927.GH93449@alchemy.franken.de> <20120403122858.GA48373@alchemy.franken.de> 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: Andrew Pantyukhin , "stable@freebsd.org" , "zvqops@di.vc" , "ken@freebsd.org" , "Desai, Kashyap" Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 21:57:16 -0000 On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: > Marius, > > Since the 0x59 device is a MegaRAID device, shouldn't you be using the MegaRAID driver. Why is the MPT driver being used in this case? The problem is that the MPT driver was wrongly attaching to some MegaRAID controllers and that was causing conflict problems, so that was fixed by removing MegaRAID ID's from the MPT driver. > Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. Are MegaRAID devices backwards-compatible so they can alternatively be driven by MPT drivers? Marius From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 22:26:39 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5E5F1065731; Tue, 3 Apr 2012 22:26:39 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55C2F8FC08; Tue, 3 Apr 2012 22:26:39 +0000 (UTC) Received: by iahk25 with SMTP id k25so325435iah.13 for ; Tue, 03 Apr 2012 15:26:38 -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 :content-transfer-encoding; bh=UM7++9qK4OQ7PwgDZCb9TmAF008jnku458Om2Mc1lj8=; b=QH6BSubDqFMCp1l8Tyr34xgfHZMAXmKJ3c0N1SSen9ntzt2E4pWGqHCt89uVM+Qk9g P8Xya4hyfym/iaeiLhJFlILgfQ3eoJkLSETET2YavFBJcUcsrq4XHzB0W64kpn0N641Z rZmnrVPN1cKcrg8WweHOj3VW7RzqTFQdEn0ayfrjjjw+vYqbInoN6Ag6ORmV6X7opNbm 3GCWLUj8tHFdFzhQHQJDb+wpq3XlAHlJOpmyyGYoqtEUDOmy5xUb2zHr3eMRjVYe0CSv oKdHnF/vYrrOWPQ1GqN+4HwZaO14DwJQhWXQw66ka4T8+hiLFnrgBwahuBc/hF6WCdqG lhZg== MIME-Version: 1.0 Received: by 10.50.106.132 with SMTP id gu4mr3429687igb.59.1333491998786; Tue, 03 Apr 2012 15:26:38 -0700 (PDT) Sender: infofarmer@gmail.com Received: by 10.50.109.197 with HTTP; Tue, 3 Apr 2012 15:26:38 -0700 (PDT) In-Reply-To: <20120403215714.GO93449@alchemy.franken.de> References: <20120403082927.GH93449@alchemy.franken.de> <20120403122858.GA48373@alchemy.franken.de> <20120403215714.GO93449@alchemy.franken.de> Date: Wed, 4 Apr 2012 02:26:38 +0400 X-Google-Sender-Auth: avOp4TUErq_0_X5htyItRJpP9Uo Message-ID: From: Andrew Pantyukhin To: Marius Strobl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "stable@freebsd.org" , "zvqops@di.vc" , "ken@freebsd.org" , "Desai, Kashyap" , "McConnell, Stephen" Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 22:26:39 -0000 On Wed, Apr 4, 2012 at 1:57 AM, Marius Strobl w= rote: > On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: >> Marius, >> >> Since the 0x59 device is a MegaRAID device, shouldn't you be using the M= egaRAID driver. =C2=A0Why is the MPT driver being used in this case? =C2=A0= The problem is that the MPT driver was wrongly attaching to some MegaRAID c= ontrollers and that was causing conflict problems, so that was fixed by rem= oving MegaRAID ID's from the MPT driver. > > Apparently, the 0x59 devices worked just fine using mpt(4) before r232411= . > Are MegaRAID devices backwards-compatible so they can alternatively be > driven by MPT drivers? The device in question is a built-in 1068-based controller on a SuperMicro X8ST3 board. It can be converted to MegaRAID mode with a special addon "button" (AOC-IButton68). http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 22:33: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 29F16106564A; Tue, 3 Apr 2012 22:33:25 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id AE7288FC14; Tue, 3 Apr 2012 22:33:24 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q33MXMAe052013; Wed, 4 Apr 2012 00:33:22 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q33MXMY4052012; Wed, 4 Apr 2012 00:33:22 +0200 (CEST) (envelope-from marius) Date: Wed, 4 Apr 2012 00:33:22 +0200 From: Marius Strobl To: Andrew Pantyukhin Message-ID: <20120403223322.GP93449@alchemy.franken.de> References: <20120403082927.GH93449@alchemy.franken.de> <20120403122858.GA48373@alchemy.franken.de> <20120403215714.GO93449@alchemy.franken.de> 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: "stable@freebsd.org" , "zvqops@di.vc" , "ken@freebsd.org" , "Desai, Kashyap" , "McConnell, Stephen" Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 22:33:25 -0000 On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: > On Wed, Apr 4, 2012 at 1:57 AM, Marius Strobl wrote: > > On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: > >> Marius, > >> > >> Since the 0x59 device is a MegaRAID device, shouldn't you be using the MegaRAID driver. ??Why is the MPT driver being used in this case? ??The problem is that the MPT driver was wrongly attaching to some MegaRAID controllers and that was causing conflict problems, so that was fixed by removing MegaRAID ID's from the MPT driver. > > > > Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. > > Are MegaRAID devices backwards-compatible so they can alternatively be > > driven by MPT drivers? > > The device in question is a built-in 1068-based controller on a > SuperMicro X8ST3 board. > > It can be converted to MegaRAID mode with a special addon "button" > (AOC-IButton68). > > http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm Okay, so unless these devices also can be driven by mfi(4) when not in MegaRAID mode, we need a way to tell both modes apart in the probe functions of both drivers. Marius From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 22:38:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6072C106566C; Tue, 3 Apr 2012 22:38:55 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 11F4F8FC12; Tue, 3 Apr 2012 22:38:55 +0000 (UTC) Received: by iahk25 with SMTP id k25so340984iah.13 for ; Tue, 03 Apr 2012 15:38:54 -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=aWCVyf/lMUFyZTzaglHV1MYcl7rC8ObjFyf22IA1LLU=; b=ZrPfas1kPMSi6NGo2NKSaItXMbbjRyVQTyoI/ABciU6vwqODnKTcvA7lxXYI16zp7V lN27NpAnUvepJID50Ol6S+Qfe1XPXiEDMfh5JhZnCKVp/r6PScwR7WQKXUKJ6XkoNIVj 8iESmIqu6/dk9286Q6BDbu4Z7izutMg+cggsCzKkCTeKlHZmMXl9DIOqoIQNKWmZlm6Q gLLVSUDHOA+SvTab5caPc2ybzvaQvm/vGYYjQvTs9zuOIqD+qdbF1GJQ5nRI2hBC8XZo kPaceIS0sDzkYzemSeplwTh0FjFTLhW3q3wfh6UWTmcPeJDH1MgMj+4NSR9mO7rTdry5 vg5A== MIME-Version: 1.0 Received: by 10.43.134.134 with SMTP id ic6mr8593254icc.36.1333492734625; Tue, 03 Apr 2012 15:38:54 -0700 (PDT) Sender: infofarmer@gmail.com Received: by 10.50.109.197 with HTTP; Tue, 3 Apr 2012 15:38:54 -0700 (PDT) In-Reply-To: <20120403223322.GP93449@alchemy.franken.de> References: <20120403082927.GH93449@alchemy.franken.de> <20120403122858.GA48373@alchemy.franken.de> <20120403215714.GO93449@alchemy.franken.de> <20120403223322.GP93449@alchemy.franken.de> Date: Wed, 4 Apr 2012 02:38:54 +0400 X-Google-Sender-Auth: rmI-V0Dt_MVrzawtcyA4nbKbrI0 Message-ID: From: Andrew Pantyukhin To: Marius Strobl Content-Type: text/plain; charset=UTF-8 Cc: "stable@freebsd.org" , "zvqops@di.vc" , "ken@freebsd.org" , "Desai, Kashyap" , "McConnell, Stephen" Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 22:38:55 -0000 On Wed, Apr 4, 2012 at 2:33 AM, Marius Strobl wrote: > On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: >> The device in question is a built-in 1068-based controller on a >> SuperMicro X8ST3 board. >> >> It can be converted to MegaRAID mode with a special addon "button" >> (AOC-IButton68). >> >> http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm > > Okay, so unless these devices also can be driven by mfi(4) when not > in MegaRAID mode, we need a way to tell both modes apart in the probe > functions of both drivers. mfi(4) obviously didn't attach, but if anyone is willing to provide a quick patch listing the IDs in mfi(4), I'll try. I wouldn't welcome the change though, as we prefer the JBOD way. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 23:06: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 012AB106566C; Tue, 3 Apr 2012 23:06:51 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF1A8FC16; Tue, 3 Apr 2012 23:06:50 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q33N6m3M052115; Wed, 4 Apr 2012 01:06:48 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q33N6mDd052114; Wed, 4 Apr 2012 01:06:48 +0200 (CEST) (envelope-from marius) Date: Wed, 4 Apr 2012 01:06:48 +0200 From: Marius Strobl To: Andrew Pantyukhin Message-ID: <20120403230648.GQ93449@alchemy.franken.de> References: <20120403082927.GH93449@alchemy.franken.de> <20120403122858.GA48373@alchemy.franken.de> <20120403215714.GO93449@alchemy.franken.de> <20120403223322.GP93449@alchemy.franken.de> 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: "stable@freebsd.org" , "zvqops@di.vc" , "ken@freebsd.org" , "Desai, Kashyap" , "McConnell, Stephen" Subject: Re: r232411 breaks onboard 1068 detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2012 23:06:51 -0000 On Wed, Apr 04, 2012 at 02:38:54AM +0400, Andrew Pantyukhin wrote: > On Wed, Apr 4, 2012 at 2:33 AM, Marius Strobl wrote: > > On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: > >> The device in question is a built-in 1068-based controller on a > >> SuperMicro X8ST3 board. > >> > >> It can be converted to MegaRAID mode with a special addon "button" > >> (AOC-IButton68). > >> > >> http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm > > > > Okay, so unless these devices also can be driven by mfi(4) when not > > in MegaRAID mode, we need a way to tell both modes apart in the probe > > functions of both drivers. > > mfi(4) obviously didn't attach, but if anyone is willing to provide a > quick patch listing the IDs in mfi(4), I'll try. > > I wouldn't welcome the change though, as we prefer the JBOD way. I still highly doubt that 0x59 will work with mfi(4) in non-MegaRAID mode. Looking at the source of the Linux megasr driver, that one attaches to several 0x59 devices but only in case of certain sub-vendor (amongst other Supermicro) and sub-device IDs, but not in case of a sub-vendor ID of LSI and a sub-device ID of 0x1000 like in your case. So this seems like a way to go to distinguish the modes if LSI can provide a complete list of sub-device IDs (and sub-vendor in case something besides LSI is used) in which case 0x59 should be treated in MPT mode. Marius From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 08:39: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 F05D21065673 for ; Wed, 4 Apr 2012 08:39:02 +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 A34128FC18 for ; Wed, 4 Apr 2012 08:39:02 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFLk3-0000WX-Ew for freebsd-stable@freebsd.org; Wed, 04 Apr 2012 10:38:59 +0200 Received: from np-19-75.prenet.pl ([np-19-75.prenet.pl]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 10:38:59 +0200 Received: from jb.1234abcd by np-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 10:38:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Wed, 4 Apr 2012 08:38:48 +0000 (UTC) Lines: 50 Message-ID: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.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:10.0.2) Gecko/20100101 Firefox/10.0.2) Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 08:39:03 -0000 pobox.com> writes: > ... > You can appeal to authority by saying the Gentoo Hardened developers said > such-and-such all you want, but it would be more useful for you to be able > to make specific technical arguments yourself. Saying "it could be a > problem" or "in the wild there may be" isn't useful. A valid technical > argument giving a mechanism for relocations to be exploited is all that > is needed for you to prove your point. > ... I have a question regarding security of FreeBSD kernel module loading and relocation. According to KLDLOAD(8): "...The kldload utility loads file.ko into the kernel using the kernel linker. ..." So, kernel module is loaded: # kldload /boot/kernel/foo.ko Here is my question: is foo.ko modified at this time ? Due to relocations ? The reason I ask about it is this Gentoo Hardened FAQ item: http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf "I keep getting the message: "error while loading shared libraries: cannot make segment writable for relocation: Permission denied." What does this mean?" I understand this is about .so and does not apply directly to .ko . But of interest to me is this: "... Text relocations are a way in which references in the executable code to addresses not known at link time are solved. Basically they just write the appropriate address at runtime marking the code segment writable in order to change the address then unmarking it. This can be a problem as an attacker could try to exploit a bug when the text relocation happens in order to be able to write arbitrary code in the text segment which would be executed. ..." Now, let me apply the above quoted paragraph to .ko and ask my question again, this time being more specific: are you doing any "marking" and "unmarking" of it at relocations and load time, thus creating an attack window opportunity ? jb From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 12:13:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F4331065675; Wed, 4 Apr 2012 12:13:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 000398FC15; Wed, 4 Apr 2012 12:13:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5F592B96B; Wed, 4 Apr 2012 08:13:48 -0400 (EDT) From: John Baldwin To: Doug Ambrisko Date: Wed, 4 Apr 2012 08:04:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201204031637.q33GboNt040791@ambrisko.com> In-Reply-To: <201204031637.q33GboNt040791@ambrisko.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204040804.56040.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Apr 2012 08:13:48 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 12:13:49 -0000 On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: > John Baldwin writes: > | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: > | > Doug Ambrisko writes: > | > | John Baldwin writes: > | > | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: > | > | | > Sean Bruno writes: > | > | | > | Noting a failure to attach to the onboard IPMI controller with this > | dell > | > | | > | R815. Not sure what to start poking at and thought I'd though this > | over > | > | | > | here for comment. > | > | | > | > | > | | > | -bash-4.2$ dmesg |grep ipmi > | > | | > | ipmi0: KCS mode found at io 0xca8 on acpi > | > | | > | ipmi1: on isa0 > | > | | > | device_attach: ipmi1 attach returned 16 > | > | | > | ipmi1: on isa0 > | > | | > | device_attach: ipmi1 attach returned 16 > | > | | > | ipmi0: Timed out waiting for GET_DEVICE_ID > | > | | > > | > | | > I've run into this recently. A quick hack to fix it is: > | > | | > > | > | | > Index: ipmi.c > | > | | > =================================================================== > | > | | > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v > | > | | > retrieving revision 1.14 > | > | | > diff -u -p -r1.14 ipmi.c > | > | | > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 > | > | | > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 > | > | | > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) > | > | | > if (error == EWOULDBLOCK) { > | > | | > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); > | > | | > ipmi_free_request(req); > | > | | > - return; > | > | | > } else if (error) { > | > | | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); > | > | | > ipmi_free_request(req); > | > | | > > | > | | > The issue is that the wakeup doesn't actually wake up the msleep > | > | | > in ipmi_submit_driver_request. The error being reported is that > | > | | > the msleep timed out. This doesn't seem to be critical problem > | > | | > since after this things seemed to work work. I saw this on 9.X. > | > | | > Haven't seen it on 8.2. Not sure about -current. > | > | | > > | > | | > It doesn't happen on all machines. > | > | | > | > | | Hmm, are you seeing the KCS thread manage the request but the wakeup() > | is > | > | | lost? > | > | > | > | It was a couple of weeks ago that I played with it. I put printf's > | > | around the msleep and wakeup. I saw the wakeup called but the sleep > | > | not get it. I can try the test again later today. Right now my main > | > | work machine is recovering from a power outage. This was with 9.0 > | > | when I first saw it. This issue seems to only happen at boot time. > | > | If I kldload the module after the system is booted then it seems to work > | > | okay. The KCS part was working fine and got the data okay from the > | > | request. I haven't seen or heard any issues with 8.2. > | > > | > With -current I patched ipmi.c with: > | > Index: ipmi.c > | > =================================================================== > | > --- ipmi.c (revision 233806) > | > +++ ipmi.c (working copy) > | > @@ -523,7 +523,11 @@ > | > * waiter that we awaken. > | > */ > | > if (req->ir_owner == NULL) > | > +{ > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before wakeup > | %d\n",__FUNCTION__,__LINE__,ticks); > | > wakeup(req); > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after wakeup > | %d\n",__FUNCTION__,__LINE__,ticks); > | > +} > | > else { > | > dev = req->ir_owner; > | > TAILQ_INSERT_TAIL(&dev->ipmi_completed_requests, req, > | ir_link); > | > @@ -543,7 +547,11 @@ > | > IPMI_LOCK(sc); > | > error = sc->ipmi_enqueue_request(sc, req); > | > if (error == 0) > | > +{ > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before msleep > | %d\n",__FUNCTION__,__LINE__,ticks); > | > error = msleep(req, &sc->ipmi_lock, 0, "ipmireq", timo); > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after msleep > | %d\n",__FUNCTION__,__LINE__,ticks); > | > +} > | > if (error == 0) > | > error = req->ir_error; > | > IPMI_UNLOCK(sc); > | > @@ -695,8 +703,11 @@ > | > error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT); > | > if (error == EWOULDBLOCK) { > | > device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); > | > + printf("DJA\n"); > | > +/* > | > ipmi_free_request(req); > | > return; > | > +*/ > | > } else if (error) { > | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); > | > ipmi_free_request(req); > | > > | > and get > | > # dmesg | grep ipmi > | > ipmi0: KCS mode found at io 0xca8 on acpi > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 > | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201 > | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263 > | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323 > | > | Actually, can you compile with: > | > | options KTR > | options KTR_COMPILE=KTR_SCHED > | options KTR_MASK=KTR_SCHED > | > | and then add a temporary hack to ipmi.c to set ktr_mask to 0 after > | ipmi_submit_driver_request() returns in ipmi_startup()? You can > | then use 'ktrdump -ct' after boot to capture a log of what the scheduler > | did including if it timed out the sleep, etc. I think this would be > | useful for figuring out what went wrong. It does seem that it timed > | out after 3 seconds. > > Assuming I didn't mess up, the log should be at: > http://people.freebsd.org/~ambrisko/ipmi_ktr_dump.txt > again, I using ipmi(4) as module loaded via the loader. If you use "-ct" then you get a file you can feed into schedgraph. However, just reading the log, it seems that IRQ 20 keeps preempting the KCS worker thread preventing it from getting anything done. Also, there seem to be a lot of threads on CPU 0's runqueue waiting for a chance to run (load average of 12 or 13 the entire time). You can try just bumping up the max timeout from 3 seconds to higher perhaps. Not sure why IRQ 20 keeps firing though. It might be related to USB, so you could try fiddling with USB options in the BIOS perhaps, or disabling the USB drivers to see if that fixes IPMI. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 12:19:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74BA4106566C for ; Wed, 4 Apr 2012 12:19:44 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE9828FC1A for ; Wed, 4 Apr 2012 12:19:43 +0000 (UTC) Received: by lagv3 with SMTP id v3so422852lag.13 for ; Wed, 04 Apr 2012 05:19:42 -0700 (PDT) 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=r7sqU/jcFxxjPO5q834vvE1c5l3fW7uMZHxVLQ1xSHY=; b=T3PirQj/J1KsZiZdzeXOqhkpSjlpJV97yQLuRv0RtBiFl8yvLZYLD3vXHEdmcMg4C1 KHdJx/WY3Xr7p7LP8b0YPzzQs5gzGg+IfHxQO4RHXvBeaPyt0xoi+SQ/BsMQqdX1I79v +Qfv5L1h9x/GPyasweDEvHMaZRTsWHrBXH1fuu2dtsoRZH3TaVHVNEiP+bHl1QxYdjgC hBAQIv6fLKCDQNDlvNhY1hgKf0tt+j/JDeP/tcaS3Hw8fYfzSoaEmQNz5BhB9vhLsVy2 sJ5elNAcDUsMiEvtpl0pxZ22eCDSUmy8uuZNcROaOFfeVozbh2h/K+xR9veuLmgeq5lZ PCHw== MIME-Version: 1.0 Received: by 10.152.145.135 with SMTP id su7mr18545528lab.5.1333541982415; Wed, 04 Apr 2012 05:19:42 -0700 (PDT) Received: by 10.112.80.33 with HTTP; Wed, 4 Apr 2012 05:19:42 -0700 (PDT) In-Reply-To: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> Date: Wed, 4 Apr 2012 21:49:42 +0930 Message-ID: From: Matt Thyer To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 12:19:44 -0000 On 25 March 2012 22:26, Matt Thyer wrote: > > Does anyone know if and when this driver was merged from current to > 8-STABLE ? > > If I can work out what revision that occurred in I'll go back to just > before then to confirm if the problem exists. > In the -CURRENT list I've been told that the new driver was introduced into 8-STABLE at revision 230921. I reverted to that revision but the problem was still apparent. So I've now tried: - Previous BIOS - Updating the controller firmware from phase 7 to phase 11 - Going back to the old (pre LSI authored) mps driver But all to no avail. What has worked is to move the single SATA 3 (6 Gbps) drive (the other 7 drives are SATA 2) to the onboard SATA 2 Intel controller. So it seems that both the old and new mps driver have a problem with the Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS 6G) controller (flashed with -IT firmware). I'll continue this in the -CURRENT list in the thread about the new driver as that's where the main discussion has been. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 12:25:24 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 7CD7D106566B for ; Wed, 4 Apr 2012 12:25:24 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by mx1.freebsd.org (Postfix) with ESMTP id E42138FC12 for ; Wed, 4 Apr 2012 12:25:23 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKT3w9s5a0H/1GImdTeIjCQkxnolpboN/O@postini.com; Wed, 04 Apr 2012 05:25:24 PDT Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 08:30:39 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 08:25:22 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Wed, 4 Apr 2012 17:55:19 +0530 From: "Desai, Kashyap" To: Matt Thyer , Mike Tancsa Date: Wed, 4 Apr 2012 17:55:17 +0530 Thread-Topic: 157k interrupts per second causing 60% CPU load on idle system Thread-Index: Ac0SXYro77saM+9rTcWlILHX/KHPuAAACF0Q Message-ID: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" , "McConnell, Stephen" Subject: RE: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 12:25:24 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Matt Thyer > Sent: Wednesday, April 04, 2012 5:50 PM > To: Mike Tancsa > Cc: freebsd-stable@freebsd.org > Subject: Re: 157k interrupts per second causing 60% CPU load on idle > system >=20 > On 25 March 2012 22:26, Matt Thyer wrote: >=20 > > > > Does anyone know if and when this driver was merged from current to > > 8-STABLE ? > > > > If I can work out what revision that occurred in I'll go back to just > > before then to confirm if the problem exists. > > >=20 > In the -CURRENT list I've been told that the new driver was introduced > into > 8-STABLE at revision 230921. > I reverted to that revision but the problem was still apparent. >=20 > So I've now tried: >=20 > - Previous BIOS > - Updating the controller firmware from phase 7 to phase 11 > - Going back to the old (pre LSI authored) mps driver >=20 > But all to no avail. >=20 > What has worked is to move the single SATA 3 (6 Gbps) drive (the other 7 > drives are SATA 2) to the onboard SATA 2 Intel controller. >=20 > So it seems that both the old and new mps driver have a problem with the > Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS > 6G) controller (flashed with -IT firmware). >=20 > I'll continue this in the -CURRENT list in the thread about the new > driver > as that's where the main discussion has been. Mike,=20 Have your purchase LSI controller through Channel or OEM ? It would be a difficult for developers to help you without any support chan= nel invovoled ? If possible can you contact LSI support channel ? ~ Kashyap > _______________________________________________ > 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 Wed Apr 4 12:37:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D46FB106566C for ; Wed, 4 Apr 2012 12:37:40 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDF78FC14 for ; Wed, 4 Apr 2012 12:37:40 +0000 (UTC) Received: by lagv3 with SMTP id v3so450061lag.13 for ; Wed, 04 Apr 2012 05:37:39 -0700 (PDT) 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=oFBywp/qWA1PsCSl1XfLt9Rt+AHjm2GH1GKqN3n2Zmg=; b=GIpfNjey8pjwYI6pAx+r60hVvfTfmLhl9+UXq9p/QP0ODSy6IVzir017WBYbBtEwWr sHYgVngr97UpJrMmSlM9fPxqJ/A3ndYjTNy6evc3+sIZ+SB1Tiu6W3dQe13Tphf/hcnC 0zkRdXzCtagngUz3htbaY7rtGnq2q39tHq75mCUWWrxza3VOprO+pII3tN2fIjeNcMN+ EHkhnsPKP4R1tKTpojzcx1FLBqde3sPnslO8MnZ5Mf+s9NIBlOqIqBzxPzDQRlqnza0P VCqHsNaQNa67EDywOxVNbJV+/GLHaQuaryU4A1kVSZqyyTgN90rGjEgzYgDdD5xAEqPV e9eA== MIME-Version: 1.0 Received: by 10.152.112.68 with SMTP id io4mr18481492lab.40.1333543059259; Wed, 04 Apr 2012 05:37:39 -0700 (PDT) Received: by 10.112.80.33 with HTTP; Wed, 4 Apr 2012 05:37:39 -0700 (PDT) In-Reply-To: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> Date: Wed, 4 Apr 2012 22:07:39 +0930 Message-ID: From: Matt Thyer To: "Desai, Kashyap" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" , "McConnell, Stephen" Subject: Re: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 12:37:41 -0000 On 4 April 2012 21:55, Desai, Kashyap wrote: > Mike, > Have your purchase LSI controller through Channel or OEM ? > It would be a difficult for developers to help you without any support > channel invovoled ? > If possible can you contact LSI support channel ? > Kashyap, It's me, Matt, not Mike reporting this problem. I purchased the Super Micro card off eBay through a seller with good reputation. I've bought a couple of said cards through him now. I'm not sure why you are thinking the lack of middle men would be a problem. I hope that Super Micro & LSI would both be interested in a detailed report of a problem. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 12:46:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA44C106566B for ; Wed, 4 Apr 2012 12:46:13 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from psmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by mx1.freebsd.org (Postfix) with ESMTP id 44E218FC15 for ; Wed, 4 Apr 2012 12:46:13 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKT3xCjwra6QTUrlOemO0i8t7tNKN7u4Ih@postini.com; Wed, 04 Apr 2012 05:46:13 PDT Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 08:51:23 -0400 Received: from inbexch01.lsi.com (135.36.98.37) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 08:46:05 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Wed, 4 Apr 2012 18:16:03 +0530 From: "Desai, Kashyap" To: Matt Thyer Date: Wed, 4 Apr 2012 18:16:01 +0530 Thread-Topic: 157k interrupts per second causing 60% CPU load on idle system Thread-Index: Ac0SX7ynsS32OIBXQKGGah0rT2XZDAAAFAug Message-ID: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" , "McConnell, Stephen" Subject: RE: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 12:46:14 -0000 Matt, Sorry for addressing to wrong person.! I am working in Device Driver group and it difficult to track request comin= g through emails. We can solve those request through emails which are minor= /medium in complexity. There are some group in LSI which has expertise to root cause issue and pro= vide better support than developers. Sometimes issue can be non-driver issu= e (e.a Can be hw issue/fw issues etc.) and those issue need customer inter= action and may be sometimes reproduction. So I request to contact LSI support channel ( at least for complex issues) = to get better tracking and speed up resolution. ` Kashyap From: Matt Thyer [mailto:matt.thyer@gmail.com] Sent: Wednesday, April 04, 2012 6:08 PM To: Desai, Kashyap Cc: Mike Tancsa; freebsd-stable@freebsd.org; McConnell, Stephen Subject: Re: 157k interrupts per second causing 60% CPU load on idle system On 4 April 2012 21:55, Desai, Kashyap > wrote: Mike, Have your purchase LSI controller through Channel or OEM ? It would be a difficult for developers to help you without any support chan= nel invovoled ? If possible can you contact LSI support channel ? Kashyap, It's me, Matt, not Mike reporting this problem. I purchased the Super Micro card off eBay through a seller with good reputa= tion. I've bought a couple of said cards through him now. I'm not sure why you are thinking the lack of middle men would be a problem= . I hope that Super Micro & LSI would both be interested in a detailed report= of a problem. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 14:34:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 519731065678 for ; Wed, 4 Apr 2012 14:34:58 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 315418FC0C for ; Wed, 4 Apr 2012 14:34:58 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta04.emeryville.ca.mail.comcast.net with comcast id tpi11i0041smiN4A4qZsB0; Wed, 04 Apr 2012 14:33:52 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id tqZr1i0074NgCEG8gqZreo; Wed, 04 Apr 2012 14:33:52 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q34EXn5Y050880; Wed, 4 Apr 2012 08:33:49 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: jb In-Reply-To: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Apr 2012 08:33:49 -0600 Message-ID: <1333550029.1090.67.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 14:34:58 -0000 On Wed, 2012-04-04 at 08:38 +0000, jb wrote: > pobox.com> writes: > > > ... > > You can appeal to authority by saying the Gentoo Hardened developers said > > such-and-such all you want, but it would be more useful for you to be able > > to make specific technical arguments yourself. Saying "it could be a > > problem" or "in the wild there may be" isn't useful. A valid technical > > argument giving a mechanism for relocations to be exploited is all that > > is needed for you to prove your point. > > ... > > I have a question regarding security of FreeBSD kernel module loading and > relocation. > > According to KLDLOAD(8): > "...The kldload utility loads file.ko into the kernel using the kernel > linker. ..." > > So, kernel module is loaded: > # kldload /boot/kernel/foo.ko > > Here is my question: is foo.ko modified at this time ? Due to relocations ? > > The reason I ask about it is this Gentoo Hardened FAQ item: > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf > > "I keep getting the message: "error while loading shared libraries: cannot make > segment writable for relocation: Permission denied." What does this mean?" > > I understand this is about .so and does not apply directly to .ko . > > But of interest to me is this: > "... > Text relocations are a way in which references in the executable code to > addresses not known at link time are solved. Basically they just write > the appropriate address at runtime marking the code segment writable in order > to change the address then unmarking it. This can be a problem as an attacker > could try to exploit a bug when the text relocation happens in order to be able > to write arbitrary code in the text segment which would be executed. > ..." > > Now, let me apply the above quoted paragraph to .ko and ask my question again, > this time being more specific: > > are you doing any "marking" and "unmarking" of it at relocations and load time, > thus creating an attack window opportunity ? > > jb Even though you acknowledge it, your question seems to contradict an understanding of the concept that a .ko is not a shared library. The "marking and unmarking" you refer to would apply to pages that are shared among multiple processes and have to be relocated repeatedly into each process's address space. A kernel module is loaded and linked ONCE, at load time, into the kernel's address space. It is not shared and never needs to be relocated again into another address space. In other words, the paragraph you cite doesn't have any meaning in the context of a .ko, because a .ko isn't a userland shared library. It's also interesting to me to note that even in a userland shared library, whether there are text relocations scattered throughout the text segment or they're all gathered into one table the way PIC code works, the same number of relocations have to happen to link the library into a new address space. The only difference is whether many pages get touched because the relocations are scattered, or only a few pages because they're all clumped together. The PIC scheme is designed to maximize code sharing by eliminating the need to copy-on-write many modified pages. I wonder how it became associated with increased security? I don't see the increase. -- Ian From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 15:05: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 A914A1065679 for ; Wed, 4 Apr 2012 15:05: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 5A2C68FC14 for ; Wed, 4 Apr 2012 15:05:51 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFRmH-0001Gy-FJ for freebsd-stable@freebsd.org; Wed, 04 Apr 2012 17:05:41 +0200 Received: from np-19-75.prenet.pl ([np-19-75.prenet.pl]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 17:05:41 +0200 Received: from jb.1234abcd by np-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 17:05:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Wed, 4 Apr 2012 15:05:29 +0000 (UTC) Lines: 24 Message-ID: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.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:10.0.2) Gecko/20100101 Firefox/10.0.2) Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 15:05:51 -0000 Ian Lepore damnhippie.dyndns.org> writes: > ... > > But of interest to me is this: > > "... > > Text relocations are a way in which references in the executable code to > > addresses not known at link time are solved. Basically they just write > > the appropriate address at runtime marking the code segment writable in > > order to change the address then unmarking it. This can be a problem as > > an attacker could try to exploit a bug when the text relocation happens > > in order to be able to write arbitrary code in the text segment which > > would be executed. > > ..." > ... > A kernel module is loaded and linked > ONCE, at load time, into the kernel's address space. > ... >From the point of view of an attacker it does not matter whether kernel module is loaded and linked once only. That's enough to create a window of opportunity for interfering with relocation process and modifying text (code). jb From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 15:48: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 2A87E106566C for ; Wed, 4 Apr 2012 15:48:44 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBBC48FC0C for ; Wed, 4 Apr 2012 15:48:43 +0000 (UTC) Received: by vbmv11 with SMTP id v11so372369vbm.13 for ; Wed, 04 Apr 2012 08:48:43 -0700 (PDT) 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=/y0JFRVekYYqjgfOoU5gLv2KKLYwgxNrRXYdoyqiFgY=; b=DexFxp9ArrEzZnLnW4YyGKJmOojIp2MfNLlB1x1k3ZVGSV9G1gPynU9QaP78Y7VOGm dj+ufzsn+ZNY4PpUOZeOvez0Rdwu2pDnbN9ZlNyw8H2Boc4g5y1m9d0gmQO7DEnX2Zv2 FCXx0EVwHkMV1S84WSJ5A6IMJSxNeld4B0oEaeL2Qa+SVvKI0aX3YqM86LG/FRQkBf6T VN8obqzjOuMq1V0MGDuXBLJTPOgCXr8MoPFBscFpe9+8JAvQ2V2eubQwT1xY1GbsPBRu xxrqbtcI4GCBGDBGeBfWOSOcXX9J3g5ze1ezxamefA7OxESwvJa9+5G1rMfEPHPzV/oI KWRQ== MIME-Version: 1.0 Received: by 10.52.22.74 with SMTP id b10mr6834730vdf.47.1333554523115; Wed, 04 Apr 2012 08:48:43 -0700 (PDT) Received: by 10.220.180.198 with HTTP; Wed, 4 Apr 2012 08:48:42 -0700 (PDT) In-Reply-To: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> Date: Wed, 4 Apr 2012 08:48:42 -0700 Message-ID: From: Freddie Cash To: Matt Thyer Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 15:48:44 -0000 On Wed, Apr 4, 2012 at 5:19 AM, Matt Thyer wrote: > So it seems that both the old and new mps driver have a problem with the > Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS > 6G) controller (flashed with -IT firmware). I wouldn't say the driver has a problem with that specific drive. More that it might have a problem with a mixed SATA2/SATA3 setup. I have a 9-STABLE box with 24x WDC WD2002FAEX SATA3 (6 Gbps) drives attached to 3 SuperMicro AOC-USAS2-8Li controllers, using the new mps(4) driver without any issues. Was actually amazed yesterday when I say it doing writes just shy of 500 MBps to the ZFS pool, via zfs send/recv from another box. No issues with excessive interrupts. Using 10.0 firmware on the controllers. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 15:57:08 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 A4062106566B for ; Wed, 4 Apr 2012 15:57:08 +0000 (UTC) (envelope-from mpumford@mpcdata.com) Received: from owa.bsquare.com (vpn.bsquare.com [12.107.117.66]) by mx1.freebsd.org (Postfix) with ESMTP id 715A28FC18 for ; Wed, 4 Apr 2012 15:57:08 +0000 (UTC) Received: from [10.150.16.163] (81.2.99.171) by BREAL.camelot.bsquare.com (192.168.100.67) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 4 Apr 2012 08:57:02 -0700 Message-ID: <4F7C6F4B.1090205@mpcdata.com> Date: Wed, 4 Apr 2012 16:56:59 +0100 From: Mike Pumford User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120322 Firefox/12.0 SeaMonkey/2.9 MIME-Version: 1.0 CC: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [81.2.99.171] Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 15:57:08 -0000 jb wrote: >> From the point of view of an attacker it does not matter whether kernel module > is loaded and linked once only. That's enough to create a window of opportunity > for interfering with relocation process and modifying text (code). > Well yes but said attacker has to be able to modify KERNEL memory to do it. If they can do that worrying about module relocations is pointless as they already own the machine. Mike From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 15:58:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A9D106564A for ; Wed, 4 Apr 2012 15:58:17 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 383998FC0C for ; Wed, 4 Apr 2012 15:58:17 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta11.emeryville.ca.mail.comcast.net with comcast id tr9w1i0031smiN4ABryGHY; Wed, 04 Apr 2012 15:58:16 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id tryF1i00b4NgCEG8gryF51; Wed, 04 Apr 2012 15:58:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q34FwDRp050950; Wed, 4 Apr 2012 09:58:13 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: jb In-Reply-To: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Apr 2012 09:58:13 -0600 Message-ID: <1333555093.1090.81.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 15:58:17 -0000 On Wed, 2012-04-04 at 15:05 +0000, jb wrote: > Ian Lepore damnhippie.dyndns.org> writes: > > > ... > > > But of interest to me is this: > > > "... > > > Text relocations are a way in which references in the executable code to > > > addresses not known at link time are solved. Basically they just write > > > the appropriate address at runtime marking the code segment writable in > > > order to change the address then unmarking it. This can be a problem as > > > an attacker could try to exploit a bug when the text relocation happens > > > in order to be able to write arbitrary code in the text segment which > > > would be executed. > > > ..." > > ... > > A kernel module is loaded and linked > > ONCE, at load time, into the kernel's address space. > > ... > > >From the point of view of an attacker it does not matter whether kernel module > is loaded and linked once only. That's enough to create a window of opportunity > for interfering with relocation process and modifying text (code). > > jb Read again what I said. The same relocations would happen whether scattered through the text segment or gathered together in a single page. So the same window exists either way. But even more to the point: the memory has to be writable to initially populate it. The fact that it has to be changed as it is loaded doesn't in any way create an opportunity that doesn't already exist due to the pages being writable so that they can be loaded from disk. If there is some malicious in-kernel code (and it MUST be in-kernel code, because this is kernel memory, not mapped into any userland address space) it can already write to those pages because they're writable so that IO can happen. The pages are only visible to kernel code, and thus this hypothetical attack is being carried out by kernel code; if the pages weren't marked writable it would just make them writable, then write to them. If there is malicious in-kernel code that wants to do bad things, it doesn't have to wait for a .ko to get loaded to do the bad things. It's kernel code, it can do whatever it wants whenever it wants. This whole relocation question is just a big red herring. The kernel loader relocating a kernel module at load time does not open any opportunity for userland code to launch an attack on the memory pages into which the module gets loaded. -- Ian From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:04:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33DD0106564A for ; Wed, 4 Apr 2012 16:04:03 +0000 (UTC) (envelope-from efraindector@motumweb.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 E494F8FC08 for ; Wed, 4 Apr 2012 16:04:02 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so663530obb.13 for ; Wed, 04 Apr 2012 09:04:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:from:to:subject:date:organization:mime-version :content-type:x-priority:x-msmail-priority:importance:x-mailer :x-mimeole:x-gm-message-state; bh=o7lZeLllUwywzJDF6/FkVxQZwgkTFcpDYgi5zFddQLg=; b=YYu52KReLfxzfN5ykLZleKop6FbtyAIpn6k2I0WjrviyhNNBjTQ+hccx7FidgNYbhn frLUsSNYDNSTCN0ns6a+mtohxeP9nZ36KUcQAGMO40wOPJmhuzfjN/eP1GPGNBtgkbhv cwNjqo0+4tBXvEP97Z1mx1P1CxiH7+Cb36wIh0M4Rg1bLlHlxZGHxoRhmMhe/wIdnWgN zgEbyq7N4us5hS04oe3tRuXzxqIi7vH5A+A7qT6MSujGJS+sfwM8UG9MOGsTLnRFszwu ZH2ZUq/qL9hOkDzeI0Q/hfjstzt0e/UbGCuFczB7sFn9/YCm2bwUHtTLZeHRxXbWq7H5 EWuw== Received: by 10.182.127.20 with SMTP id nc20mr25303703obb.66.1333555442590; Wed, 04 Apr 2012 09:04:02 -0700 (PDT) Received: from CMOTUM25PC ([189.188.38.25]) by mx.google.com with ESMTPS id j10sm990092oba.4.2012.04.04.09.03.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 09:04:01 -0700 (PDT) Message-ID: From: =?iso-8859-1?Q?Efra=EDn_D=E9ctor?= To: Date: Wed, 4 Apr 2012 11:03:53 -0500 Organization: =?iso-8859-1?Q?HESA_T=E9cnica?= MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-Gm-Message-State: ALoCoQmcTrZ/szjI3a9qSpobsoiHdyM4xug8MZ1Ju+QU4bhVyTnkWOXCqiua/NHFdE5IB+Ba1zaU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Compatibility with the new XEON Processors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 16:04:03 -0000 Hello. Does anyone know if FreeBSD 8.2 and FreeBSD 9.1 are fully compatible = with this processor: Intel XEON E3 1270 ?. Thank you. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:07: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 DE89C106564A for ; Wed, 4 Apr 2012 16:07:50 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7FBE28FC15 for ; Wed, 4 Apr 2012 16:07:50 +0000 (UTC) Received: by vbmv11 with SMTP id v11so398023vbm.13 for ; Wed, 04 Apr 2012 09:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pK5X1giK7JfriXsAgAM1aM8XXrr9KBQIGOYOLxWHD7Y=; b=g9r8Fx/JRXz46/fowAYZ6nc42xKPkQ2q8GipbMJxyFLiqMRu3b362NSx+bWcvTSjpr WwqZU+ePo5PPCFx9/qV1v75JH4RpobreRdkVR3bGXYhHrRIEjTZ5Z3tBtpMJKY5b/r14 EJBF7Hs7Kg+SiAx2xR5KfzEoShFSsGwdw5ZeM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=pK5X1giK7JfriXsAgAM1aM8XXrr9KBQIGOYOLxWHD7Y=; b=BvzLNDBwxIRexgsFiIlKOiUViR+/7gIWSNTV/uU0LPOrZX03+NRn2+oDD2E/KkgEIp Lxx9VI4oGUXRSJLvHYZ1nBKg46NISLpD8O598Hc0OInA8JZBqqukPS3A5yUquEtjzDLa 1QfcMWLtskjRm3F95enmPoRYpFCoj+fk1nidyM0s5fA2QfmOYl76nuO0F5I3K8nPuir0 N4bWI2IRkhx4ilGiOcor9xzGNKOozKLRuYz5Q0u024trnj95yJoi6aifrS8b1zVepARj B6BMkoDDcJcowJJwrPiOviOfdL+GZV4bzP00gsvlUGorqipSn6bLA5WRfYIluzJfTUn0 caGA== MIME-Version: 1.0 Received: by 10.52.73.102 with SMTP id k6mr6841461vdv.57.1333555669909; Wed, 04 Apr 2012 09:07:49 -0700 (PDT) Received: by 10.220.180.199 with HTTP; Wed, 4 Apr 2012 09:07:49 -0700 (PDT) In-Reply-To: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> Date: Wed, 4 Apr 2012 09:07:49 -0700 Message-ID: From: Peter Wemm To: jb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnLHeDXdsIagh8hdzjnPCwJg6C9RM1nQIE7RvYDW6YsvmMcie8sjOR2Yw/uRBCffdrM3q50 Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 16:07:50 -0000 On Wed, Apr 4, 2012 at 1:38 AM, jb wrote: > =A0 pobox.com> writes: > >> ... >> You can appeal to authority by saying the Gentoo Hardened developers sai= d >> such-and-such all you want, but it would be more useful for you to be ab= le >> to make specific technical arguments yourself. Saying "it could be a >> problem" or "in the wild there may be" isn't useful. A valid technical >> argument giving a mechanism for relocations to be exploited is all that >> is needed for you to prove your point. >> ... > > I have a question regarding security of FreeBSD kernel module loading and > relocation. > > According to KLDLOAD(8): > "...The kldload utility loads file.ko into the kernel using the kernel > =A0 =A0 linker. ..." > > So, kernel module is loaded: > # kldload /boot/kernel/foo.ko > > Here is my question: is foo.ko modified at this time ? Due to relocations= ? > > The reason I ask about it is this Gentoo Hardened FAQ item: > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf > > "I keep getting the message: "error while loading shared libraries: canno= t make > segment writable for relocation: Permission denied." What does this mean?= " > > I understand this is about .so and does not apply directly to .ko . > > But of interest to me is this: > "... > Text relocations are a way in which references in the executable code to > addresses not known at link time are solved. Basically they just write > the appropriate address at runtime marking the code segment writable in o= rder > to change the address then unmarking it. This can be a problem as an atta= cker > could try to exploit a bug when the text relocation happens in order to b= e able > to write arbitrary code in the text segment which would be executed. > ..." > > Now, let me apply the above quoted paragraph to .ko and ask my question a= gain, > this time being more specific: > > are you doing any "marking" and "unmarking" of it at relocations and load= time, > thus creating an attack window opportunity ? In this particular case, no, there is no marking or unmarking. What happens is: kldload(2) syscall is performed with a pathname, in this case "/boot/kernel/foo.ko". The kernel locks the file. The kernel allocates a chunk of private, kernel-only data at a non deterministic address. The kernel *copies* the file from the file system into this allocated kernel-only memory. This isn't a mmap, its a read/memcpy type operation. The kernel unlocks the file. After the kernel has a private, non-shared copy of the file, it resolves outstanding symbols and relocations in its private, non-shared, non-user-accessible space. The kernel finally tells the user if the kldload() syscall was successful or not. ld.so is not involved, which is where those errors would come from. Nothing is shared, nothing is marked or unmarked. All of these operations happen outside of user visibility. We don't even have a way to report specific errors to the user, they're reported on the console. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:13:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB31106564A for ; Wed, 4 Apr 2012 16:13:51 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 37D1E8FC16 for ; Wed, 4 Apr 2012 16:13:51 +0000 (UTC) Received: by vbmv11 with SMTP id v11so405681vbm.13 for ; Wed, 04 Apr 2012 09:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ozNCM0IFoE7ltSsxtMxyMryon+L8QMYEjIUfDMklTA=; b=Ytkn09K5bQLRrhZtF2a39em2vFNnurFee4HPysw9h54OINY8mp+gK+B1AdC8Y9/dto KGMxZkpmPiYGnQem+oIilsnNrI5ap2xCs2PC8j7iNODSaHir0Rb3YlOpfXfInILCEVe8 S92ZnqXxoLAkBSPA89fek6nSBRkfh2lceK1wo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3ozNCM0IFoE7ltSsxtMxyMryon+L8QMYEjIUfDMklTA=; b=gDjANFJPRcyjSV3wOomTfQD1admVGKYSrSAG+gniNQbnV6dkgwe6ao9D7hzO7vHIXq TgXfs4IAZQCGQQUHs6cCtr+/30nk+ZS1GeanCDwbrBoGtMO0EAuM9n0rwNpIhma63xQl XKhf5xO0DzyxLzr/kIkp/Wh+vN7OqcrMXDfLqQREaRneXcV/3PwgECBhp/KlxDmxeBET 6rsm5PG/y49EGOxocb52XcBAxuHVVAOdOWmjTcof5L3cCqPkq91/SN9LnkzSc1sHtEce Ah0jqLRGMS0uTX9BI/AhOEu4HxeuKXfh9V+SLNwlRWQ8vjTHAyjA0nxRVKYu0iXoC+vr 6hYw== MIME-Version: 1.0 Received: by 10.52.17.239 with SMTP id r15mr6885383vdd.95.1333556030643; Wed, 04 Apr 2012 09:13:50 -0700 (PDT) Received: by 10.220.180.199 with HTTP; Wed, 4 Apr 2012 09:13:50 -0700 (PDT) In-Reply-To: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Date: Wed, 4 Apr 2012 09:13:50 -0700 Message-ID: From: Peter Wemm To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn5QCnIFrdVGFDfGfquQl5BXPGUrmKjciYKW0MF+IKKQxGzmlv8opYmlQgDrsOjYE8m3pz5 Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 16:13:51 -0000 On Wed, Apr 4, 2012 at 8:05 AM, jb wrote: > Ian Lepore damnhippie.dyndns.org> writes: > >> ... >> > But of interest to me is this: >> > "... >> > Text relocations are a way in which references in the executable code to >> > addresses not known at link time are solved. Basically they just write >> > the appropriate address at runtime marking the code segment writable in >> > order to change the address then unmarking it. This can be a problem as >> > an attacker could try to exploit a bug when the text relocation happens >> > in order to be able to write arbitrary code in the text segment which >> > would be executed. >> > ..." >> ... >> A kernel module is loaded and linked >> ONCE, at load time, into the kernel's address space. >> ... > > >From the point of view of an attacker it does not matter whether kernel module > is loaded and linked once only. That's enough to create a window of opportunity > for interfering with relocation process and modifying text (code). There is no way to interfere because it is done outside of user space entirely, **after** the file has been copied out of the file system. You can do whatever you like to the file, but it has no effect because all the relocation is done in a private kernel copy. In linux, the module tools do the linking and hand the resulting block of memory to the kernel. In freebsd, the module tools are third parties in the process. The copy is done while the vnode is locked. Any attempt to write to the file, or page fault via a mmap(MAP_SHARED) will sleep till the lock is released and the kernel has completed the copy of the contents. Once the lock is released, it doesn't matter what you do because the kernel is operating on a private, non-shared copy that you can't get anywhere near. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:24:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D71106564A; Wed, 4 Apr 2012 16:24:34 +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 C0ECA8FC15; Wed, 4 Apr 2012 16:24:33 +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; 04 Apr 2012 09:24:40 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q34GOXP3063507; Wed, 4 Apr 2012 09:24:33 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q34GOXvc063506; Wed, 4 Apr 2012 09:24:33 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201204041624.q34GOXvc063506@ambrisko.com> In-Reply-To: <201204040804.56040.jhb@freebsd.org> To: John Baldwin Date: Wed, 4 Apr 2012 09:24:33 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@freebsd.org Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 16:24:34 -0000 John Baldwin writes: | On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: | > John Baldwin writes: | > | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: | > | > Doug Ambrisko writes: | > | > | John Baldwin writes: | > | > | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: | > | > | | > Sean Bruno writes: | > | > | | > | Noting a failure to attach to the onboard IPMI controller with | this | > | dell | > | > | | > | R815. Not sure what to start poking at and thought I'd though | this | > | over | > | > | | > | here for comment. | > | > | | > | | > | > | | > | -bash-4.2$ dmesg |grep ipmi | > | > | | > | ipmi0: KCS mode found at io 0xca8 on acpi | > | > | | > | ipmi1: on isa0 | > | > | | > | device_attach: ipmi1 attach returned 16 | > | > | | > | ipmi1: on isa0 | > | > | | > | device_attach: ipmi1 attach returned 16 | > | > | | > | ipmi0: Timed out waiting for GET_DEVICE_ID | > | > | | > | > | > | | > I've run into this recently. A quick hack to fix it is: | > | > | | > | > | > | | > Index: ipmi.c | > | > | | > | =================================================================== | > | > | | > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v | > | > | | > retrieving revision 1.14 | > | > | | > diff -u -p -r1.14 ipmi.c | > | > | | > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 | > | > | | > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 | > | > | | > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) | > | > | | > if (error == EWOULDBLOCK) { | > | > | | > device_printf(dev, "Timed out waiting for | GET_DEVICE_ID\n"); | > | > | | > ipmi_free_request(req); | > | > | | > - return; | > | > | | > } else if (error) { | > | > | | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); | > | > | | > ipmi_free_request(req); | > | > | | > | > | > | | > The issue is that the wakeup doesn't actually wake up the msleep | > | > | | > in ipmi_submit_driver_request. The error being reported is that | > | > | | > the msleep timed out. This doesn't seem to be critical problem | > | > | | > since after this things seemed to work work. I saw this on 9.X. | > | > | | > Haven't seen it on 8.2. Not sure about -current. | > | > | | > | > | > | | > It doesn't happen on all machines. | > | > | | | > | > | | Hmm, are you seeing the KCS thread manage the request but the | wakeup() | > | is | > | > | | lost? | > | > | | > | > | It was a couple of weeks ago that I played with it. I put printf's | > | > | around the msleep and wakeup. I saw the wakeup called but the sleep | > | > | not get it. I can try the test again later today. Right now my main | > | > | work machine is recovering from a power outage. This was with 9.0 | > | > | when I first saw it. This issue seems to only happen at boot time. | > | > | If I kldload the module after the system is booted then it seems to | work | > | > | okay. The KCS part was working fine and got the data okay from the | > | > | request. I haven't seen or heard any issues with 8.2. | > | > | > | > With -current I patched ipmi.c with: | > | > Index: ipmi.c | > | > =================================================================== | > | > --- ipmi.c (revision 233806) | > | > +++ ipmi.c (working copy) | > | > @@ -523,7 +523,11 @@ | > | > * waiter that we awaken. | > | > */ | > | > if (req->ir_owner == NULL) | > | > +{ | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before wakeup | > | %d\n",__FUNCTION__,__LINE__,ticks); | > | > wakeup(req); | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after wakeup | > | %d\n",__FUNCTION__,__LINE__,ticks); | > | > +} | > | > else { | > | > dev = req->ir_owner; | > | > TAILQ_INSERT_TAIL(&dev->ipmi_completed_requests, req, | > | ir_link); | > | > @@ -543,7 +547,11 @@ | > | > IPMI_LOCK(sc); | > | > error = sc->ipmi_enqueue_request(sc, req); | > | > if (error == 0) | > | > +{ | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before msleep | > | %d\n",__FUNCTION__,__LINE__,ticks); | > | > error = msleep(req, &sc->ipmi_lock, 0, "ipmireq", timo); | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after msleep | > | %d\n",__FUNCTION__,__LINE__,ticks); | > | > +} | > | > if (error == 0) | > | > error = req->ir_error; | > | > IPMI_UNLOCK(sc); | > | > @@ -695,8 +703,11 @@ | > | > error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT); | > | > if (error == EWOULDBLOCK) { | > | > device_printf(dev, "Timed out waiting for | GET_DEVICE_ID\n"); | > | > + printf("DJA\n"); | > | > +/* | > | > ipmi_free_request(req); | > | > return; | > | > +*/ | > | > } else if (error) { | > | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); | > | > ipmi_free_request(req); | > | > | > | > and get | > | > # dmesg | grep ipmi | > | > ipmi0: KCS mode found at io 0xca8 on acpi | > | > ipmi1: on isa0 | > | > device_attach: ipmi1 attach returned 16 | > | > ipmi1: on isa0 | > | > device_attach: ipmi1 attach returned 16 | > | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 | > | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201 | > | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263 | > | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323 | > | | > | Actually, can you compile with: | > | | > | options KTR | > | options KTR_COMPILE=KTR_SCHED | > | options KTR_MASK=KTR_SCHED | > | | > | and then add a temporary hack to ipmi.c to set ktr_mask to 0 after | > | ipmi_submit_driver_request() returns in ipmi_startup()? You can | > | then use 'ktrdump -ct' after boot to capture a log of what the scheduler | > | did including if it timed out the sleep, etc. I think this would be | > | useful for figuring out what went wrong. It does seem that it timed | > | out after 3 seconds. | > | > Assuming I didn't mess up, the log should be at: | > http://people.freebsd.org/~ambrisko/ipmi_ktr_dump.txt | > again, I using ipmi(4) as module loaded via the loader. | | If you use "-ct" then you get a file you can feed into schedgraph. | However, just reading the log, it seems that IRQ 20 keeps preempting | the KCS worker thread preventing it from getting anything done. Also, | there seem to be a lot of threads on CPU 0's runqueue waiting for a | chance to run (load average of 12 or 13 the entire time). You can try | just bumping up the max timeout from 3 seconds to higher perhaps. Not | sure why IRQ 20 keeps firing though. It might be related to USB, so | you could try fiddling with USB options in the BIOS perhaps, or disabling | the USB drivers to see if that fixes IPMI. Tried without USB in kernel: http://people.freebsd.org/~ambrisko/ipmi_ktr_dump_no_usb.txt Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:25:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 016321065670 for ; Wed, 4 Apr 2012 16:25:49 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 99BA38FC1B for ; Wed, 4 Apr 2012 16:25:48 +0000 (UTC) Received: by vbmv11 with SMTP id v11so421744vbm.13 for ; Wed, 04 Apr 2012 09:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XcrsRa2POI4hcu78tJ1bupFQqY0+weX3Gigu8mM4x6k=; b=b7kcRFvYcbv/izuDktIphnFUqNaEUFtN9hvIeOqO3Uk5mzSnJt3RqLgUW0MWYdZJf6 mGxQm0QO7FONuTf4gnE5gVlrwNnJdiAMAPoqZExen2AuHfljuRoBO9NEEk+ROQ2TaK2K g+0jGGIsFz0vrcWmTn1blTBP8YIdtzjF81PNo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=XcrsRa2POI4hcu78tJ1bupFQqY0+weX3Gigu8mM4x6k=; b=I5HljkNPjNf8koIWKItf2KmzitMnOGJQWzsMVl0kodK2icnUg5x7gwm3HyEq1l56vQ NFIugpFQWbwqHl/eGPQ70xQWTtQJxa5dkGL6YdaZJhNxcmizADlWJY0lMhk35yzHdtH2 M2lb3nn740YwCZ49skY3K2BGSWc6mfv3WvvHFRBG/lo8PIYWrU1jWnzvhD6Rg0ysqcqm 0UuijfcpuvF+h2bL3p+r6TPi/PtJ62CuJex0J/Efse9DP9J+Tf+mNHHnlxwQc8HuZVSa gkEtcVBbnEfZzL4uk+I906lU7OkKfR3u25z7FiagKhsaLfrTqsVpdkjo7af5815DMYtp hs2w== MIME-Version: 1.0 Received: by 10.52.177.34 with SMTP id cn2mr6883010vdc.64.1333556748025; Wed, 04 Apr 2012 09:25:48 -0700 (PDT) Received: by 10.220.180.199 with HTTP; Wed, 4 Apr 2012 09:25:47 -0700 (PDT) In-Reply-To: <1333555093.1090.81.camel@revolution.hippie.lan> References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> <1333555093.1090.81.camel@revolution.hippie.lan> Date: Wed, 4 Apr 2012 09:25:47 -0700 Message-ID: From: Peter Wemm To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnultT+RdcZ9FpN4RP4iJNf8EFuPWaoYhQGcH3cATBjgt54R+2O8APqiON05K8M8JCFul9A Cc: freebsd-stable@freebsd.org, jb Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 16:25:49 -0000 On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore wrote: [..] > This whole relocation question is just a big red herring. =A0The kernel > loader relocating a kernel module at load time does not open any > opportunity for userland code to launch an attack on the memory pages > into which the module gets loaded. It is even more of a red herring because the basic assumption of why the relocation is a problem is invalid. In userland, a text relocation happens like this: mprotect(addr, PROT_READ|PROT_WRITE|PROT_EXEC, PAGE_SIZE); fixup_text_relocation() mprotect(addr, PROT_READ|PROT_EXEC) It's easy to see why this is something that you'd want to avoid. It causes a write fault, dirties an entire page, and leaves userland text writeable for a moment. Reducing these is worthwhile as a goal of hardening. The PaX hardening patches explicitly disable this mark/unmark phase in userland ld.so. In userland, a -fPIC cross-file relocation happens like this: fixup_readwrite_PLT_relocation() Note that the PLT is always read/write. If you look at certain tools that manage code injection you'll see that they intercept the PLT and can get away with it quite nicely. Having -fPIC relocations makes it a little easier because there's a single address to intercept. In the kernel, there is no distinction between text and data at all. It is read/write always, there is no write bit flipping, ever. A kernel text relocation on i386 looks like this: fixup_relocation(); A kernel text relocation with -fPIC on i386 looks like this: panic("reloc type not implemented") A kernel text relocation on amd64 looks like this: fixup_relocation(). Neither i386 or amd64 do -fPIC modules. There is no brief window that text is writeable, because it is always writeable by the kernel, as it comes from the kernel malloc pool(). --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 17:34:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFCD1065670 for ; Wed, 4 Apr 2012 17:34:31 +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 B18278FC08 for ; Wed, 4 Apr 2012 17:34:30 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFU6E-0002Me-TJ for freebsd-stable@freebsd.org; Wed, 04 Apr 2012 19:34:27 +0200 Received: from np-19-75.prenet.pl ([np-19-75.prenet.pl]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 19:34:26 +0200 Received: from jb.1234abcd by np-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 19:34:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Wed, 4 Apr 2012 17:34:12 +0000 (UTC) Lines: 21 Message-ID: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.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:10.0.2) Gecko/20100101 Firefox/10.0.2) Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 17:34:31 -0000 Peter Wemm wemm.org> writes: > ... > There is no way to interfere because it is done outside of user space > entirely, **after** the file has been copied out of the file system. > You can do whatever you like to the file, but it has no effect because > all the relocation is done in a private kernel copy. > ... What if attack code (broadly understood) is part of module code, and is based on either or both of: - hidden (as to meaning and reloc targets) arrangement of relocations needed - has an ability of (self) activation during load/link and *relocations* process already under the privilege of the kernel ? Is that possible at all ? Would there be any protection against it (except giving up relocations as an enabling vehicle) ? jb From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 17:40: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 A1EF3106567B for ; Wed, 4 Apr 2012 17:40:05 +0000 (UTC) (envelope-from lattera@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 506B88FC15 for ; Wed, 4 Apr 2012 17:40:05 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so792842obb.13 for ; Wed, 04 Apr 2012 10:40:05 -0700 (PDT) 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=wHnDk5Hmd2aDiRPRQoDDS/JeQNseIDwpG2Jx//kVNBM=; b=NDgw+8aUZFb5DWmKuq1dfoaMljp1PBC5zh+SyXgwatwXreHHjU9flnGt5irLy+4Y8E 7DjaPuaksib2FkxDJ8+0UV/m68cMOqK/D2In783Jvasx5LxpZa8hEZN79MxzsZxiaRIy hM1K5Dbdn0yJZ/fuXP1kAOfZK8dDqII4sxJw3h1mrnG3sTGWEPxi+U06xVdDj1CjqWyw n4Hb4guADCzzxddZpcCuKIdUsjSZyX/Wac1wMQzoJRWploTr1p/61D8mxpVYNyhsJ8Ky 1TwB1xkIqqWjvAathgRkFMgevXYOmNGG/dhXH7wKcrKPRLFqpQGzOLyxgFmfZtXy4F4B e3Sw== MIME-Version: 1.0 Received: by 10.182.48.66 with SMTP id j2mr5176835obn.72.1333561204899; Wed, 04 Apr 2012 10:40:04 -0700 (PDT) Received: by 10.182.19.161 with HTTP; Wed, 4 Apr 2012 10:40:04 -0700 (PDT) Received: by 10.182.19.161 with HTTP; Wed, 4 Apr 2012 10:40:04 -0700 (PDT) In-Reply-To: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Date: Wed, 4 Apr 2012 11:40:04 -0600 Message-ID: From: Shawn Webb To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 17:40:05 -0000 If there is malicious code in a kernel module, then discussions of relocations become moot. Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 4, 2012 11:35 AM, "jb" wrote: > Peter Wemm wemm.org> writes: > > > ... > > There is no way to interfere because it is done outside of user space > > entirely, **after** the file has been copied out of the file system. > > You can do whatever you like to the file, but it has no effect because > > all the relocation is done in a private kernel copy. > > ... > > What if attack code (broadly understood) is part of module code, and is > based > on either or both of: > - hidden (as to meaning and reloc targets) arrangement of relocations > needed > - has an ability of (self) activation during load/link and *relocations* > process > already under the privilege of the kernel ? > > Is that possible at all ? > Would there be any protection against it (except giving up relocations as > an enabling vehicle) ? > > jb > > > _______________________________________________ > 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 Wed Apr 4 17: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 A60321065672 for ; Wed, 4 Apr 2012 17:45:22 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFFF8FC12 for ; Wed, 4 Apr 2012 17:45:22 +0000 (UTC) Received: by ghrr20 with SMTP id r20so405975ghr.13 for ; Wed, 04 Apr 2012 10:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SEU3rXrLA6rnJbBOHTyRR+Fy1C7ZmVgE5hAjgOa2lvY=; b=XVWz+eutS/OEACN19jyuihrqthx9UYqPKrntFm4HijtF5zkZLZaGgcdey50hCcj/C+ zuqac+Bw9b8HkAUfDSJOmS6p4/YHcRIG03kFVdizLQEx4sgWHFSgLUMqldyE2Es9XCsb 81Tbq9Re8N+purHBH5VFvG+iWzuHfNvMfTw6Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SEU3rXrLA6rnJbBOHTyRR+Fy1C7ZmVgE5hAjgOa2lvY=; b=HHODxf8kbFwzG7WRu1ohL0GrboG2UBweJk7SQb5L3fkiLHUKIB/vTdwoN3JutGwhUH e/oMvHpbImbRrlpzM4BM/hnGmkqUcephXdTfeh9cvSRe7MTSr+ZQS/LTx5hGoczsHtDH deNdZ+K5Bds1wPTkGj/MmNzpifJZLuF8b7Yzr0vIGxJx4wyoP1qEVzKgTc4x7j3pEIeV d6UdqsS+MbM6+KNGJu9Q+ef3sn6Z/akvO+w/lBClpRxJt7L9emYducepqLyuPeUn29l0 2B/rIZgpUz9ryZk9/lohTx1kObCJN3nc9Cl0zMSVvhmSvH0yRpPn44aByAL0S5cFwyQP xOTA== MIME-Version: 1.0 Received: by 10.52.17.239 with SMTP id r15mr7070987vdd.95.1333561521671; Wed, 04 Apr 2012 10:45:21 -0700 (PDT) Received: by 10.220.180.199 with HTTP; Wed, 4 Apr 2012 10:45:21 -0700 (PDT) In-Reply-To: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Date: Wed, 4 Apr 2012 10:45:21 -0700 Message-ID: From: Peter Wemm To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlWnsq2d1euh6fyvep5HUWL9zYSHJUJb1BW8V897tD9gzTDcWHEM3L7gCOie5/PoWtFs3hZ Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 17:45:22 -0000 On Wed, Apr 4, 2012 at 10:34 AM, jb wrote: > Peter Wemm wemm.org> writes: > >> ... >> There is no way to interfere because it is done outside of user space >> entirely, **after** the file has been copied out of the file system. >> You can do whatever you like to the file, but it has no effect because >> all the relocation is done in a private kernel copy. >> ... > > What if attack code (broadly understood) is part of module code, and is based > on either or both of: > - hidden (as to meaning and reloc targets) arrangement of relocations needed > - has an ability of (self) activation during load/link and *relocations* process > already under the privilege of the kernel ? > > Is that possible at all ? > Would there be any protection against it (except giving up relocations as > an enabling vehicle) ? 1) If you can convince the superuser directly or indirectly to load a .ko file of your creation or under your control, it doesn't matter what the relocation state is. You already own the machine. 2) If you can write to kernel memory, you already own the machine, regardless of relocations. 3) There is no difference in any way between a text relocation and a non-text relocation inside kernel mode. 4) The user doesn't have any influence over the relocation process in any way except by #1 and #2, in which case relocations don't matter, because you already own the machine. 5) If you own the machine's kernel, you can hide anything you wish. Relocations are not a factor in this. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 18:02:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29729106566C for ; Wed, 4 Apr 2012 18:02:14 +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 CAB098FC12 for ; Wed, 4 Apr 2012 18:02:13 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFUX6-0001kl-9g for freebsd-stable@freebsd.org; Wed, 04 Apr 2012 20:02:12 +0200 Received: from np-19-75.prenet.pl ([np-19-75.prenet.pl]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 20:02:12 +0200 Received: from jb.1234abcd by np-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 20:02:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Wed, 4 Apr 2012 18:02:02 +0000 (UTC) Lines: 11 Message-ID: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.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:10.0.2) Gecko/20100101 Firefox/10.0.2) Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 18:02:14 -0000 Peter Wemm wemm.org> writes: > ... > 5) If you own the machine's kernel, you can hide anything you wish. > Relocations are not a factor in this. > OK. Thanks a lot guys for sharing your answers and time. It was quite interesting. jb From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 19:36:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7DFC1065672; Wed, 4 Apr 2012 19:36:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECDE8FC08; Wed, 4 Apr 2012 19:36:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A4BD5B95A; Wed, 4 Apr 2012 15:36:16 -0400 (EDT) From: John Baldwin To: Doug Ambrisko Date: Wed, 4 Apr 2012 14:47:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201204041624.q34GOXvc063506@ambrisko.com> In-Reply-To: <201204041624.q34GOXvc063506@ambrisko.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204041447.49398.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Apr 2012 15:36:16 -0400 (EDT) Cc: scottl@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2012 19:36:17 -0000 On Wednesday, April 04, 2012 12:24:33 pm Doug Ambrisko wrote: > John Baldwin writes: > | On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: > | > John Baldwin writes: > | > | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: > | > | > Doug Ambrisko writes: > | > | > | John Baldwin writes: > | > | > | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: > | > | > | | > Sean Bruno writes: > | > | > | | > | Noting a failure to attach to the onboard IPMI controller with > | this > | > | dell > | > | > | | > | R815. Not sure what to start poking at and thought I'd though > | this > | > | over > | > | > | | > | here for comment. > | > | > | | > | > | > | > | | > | -bash-4.2$ dmesg |grep ipmi > | > | > | | > | ipmi0: KCS mode found at io 0xca8 on acpi > | > | > | | > | ipmi1: on isa0 > | > | > | | > | device_attach: ipmi1 attach returned 16 > | > | > | | > | ipmi1: on isa0 > | > | > | | > | device_attach: ipmi1 attach returned 16 > | > | > | | > | ipmi0: Timed out waiting for GET_DEVICE_ID > | > | > | | > > | > | > | | > I've run into this recently. A quick hack to fix it is: > | > | > | | > > | > | > | | > Index: ipmi.c > | > | > | | > > | =================================================================== > | > | > | | > RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v > | > | > | | > retrieving revision 1.14 > | > | > | | > diff -u -p -r1.14 ipmi.c > | > | > | | > --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 > | > | > | | > +++ ipmi.c 31 Mar 2012 19:18:35 -0000 > | > | > | | > @@ -695,7 +695,6 @@ ipmi_startup(void *arg) > | > | > | | > if (error == EWOULDBLOCK) { > | > | > | | > device_printf(dev, "Timed out waiting for > | GET_DEVICE_ID\n"); > | > | > | | > ipmi_free_request(req); > | > | > | | > - return; > | > | > | | > } else if (error) { > | > | > | | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); > | > | > | | > ipmi_free_request(req); > | > | > | | > > | > | > | | > The issue is that the wakeup doesn't actually wake up the msleep > | > | > | | > in ipmi_submit_driver_request. The error being reported is that > | > | > | | > the msleep timed out. This doesn't seem to be critical problem > | > | > | | > since after this things seemed to work work. I saw this on 9.X. > | > | > | | > Haven't seen it on 8.2. Not sure about -current. > | > | > | | > > | > | > | | > It doesn't happen on all machines. > | > | > | | > | > | > | | Hmm, are you seeing the KCS thread manage the request but the > | wakeup() > | > | is > | > | > | | lost? > | > | > | > | > | > | It was a couple of weeks ago that I played with it. I put printf's > | > | > | around the msleep and wakeup. I saw the wakeup called but the sleep > | > | > | not get it. I can try the test again later today. Right now my main > | > | > | work machine is recovering from a power outage. This was with 9.0 > | > | > | when I first saw it. This issue seems to only happen at boot time. > | > | > | If I kldload the module after the system is booted then it seems to > | work > | > | > | okay. The KCS part was working fine and got the data okay from the > | > | > | request. I haven't seen or heard any issues with 8.2. > | > | > > | > | > With -current I patched ipmi.c with: > | > | > Index: ipmi.c > | > | > =================================================================== > | > | > --- ipmi.c (revision 233806) > | > | > +++ ipmi.c (working copy) > | > | > @@ -523,7 +523,11 @@ > | > | > * waiter that we awaken. > | > | > */ > | > | > if (req->ir_owner == NULL) > | > | > +{ > | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before wakeup > | > | %d\n",__FUNCTION__,__LINE__,ticks); > | > | > wakeup(req); > | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after wakeup > | > | %d\n",__FUNCTION__,__LINE__,ticks); > | > | > +} > | > | > else { > | > | > dev = req->ir_owner; > | > | > TAILQ_INSERT_TAIL(&dev->ipmi_completed_requests, req, > | > | ir_link); > | > | > @@ -543,7 +547,11 @@ > | > | > IPMI_LOCK(sc); > | > | > error = sc->ipmi_enqueue_request(sc, req); > | > | > if (error == 0) > | > | > +{ > | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d before msleep > | > | %d\n",__FUNCTION__,__LINE__,ticks); > | > | > error = msleep(req, &sc->ipmi_lock, 0, "ipmireq", timo); > | > | > +device_printf(sc->ipmi_dev, "DEBUG %s %d after msleep > | > | %d\n",__FUNCTION__,__LINE__,ticks); > | > | > +} > | > | > if (error == 0) > | > | > error = req->ir_error; > | > | > IPMI_UNLOCK(sc); > | > | > @@ -695,8 +703,11 @@ > | > | > error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT); > | > | > if (error == EWOULDBLOCK) { > | > | > device_printf(dev, "Timed out waiting for > | GET_DEVICE_ID\n"); > | > | > + printf("DJA\n"); > | > | > +/* > | > | > ipmi_free_request(req); > | > | > return; > | > | > +*/ > | > | > } else if (error) { > | > | > device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); > | > | > ipmi_free_request(req); > | > | > > | > | > and get > | > | > # dmesg | grep ipmi > | > | > ipmi0: KCS mode found at io 0xca8 on acpi > | > | > ipmi1: on isa0 > | > | > device_attach: ipmi1 attach returned 16 > | > | > ipmi1: on isa0 > | > | > device_attach: ipmi1 attach returned 16 > | > | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 > | > | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201 > | > | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263 > | > | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323 > | > | > | > | Actually, can you compile with: > | > | > | > | options KTR > | > | options KTR_COMPILE=KTR_SCHED > | > | options KTR_MASK=KTR_SCHED > | > | > | > | and then add a temporary hack to ipmi.c to set ktr_mask to 0 after > | > | ipmi_submit_driver_request() returns in ipmi_startup()? You can > | > | then use 'ktrdump -ct' after boot to capture a log of what the scheduler > | > | did including if it timed out the sleep, etc. I think this would be > | > | useful for figuring out what went wrong. It does seem that it timed > | > | out after 3 seconds. > | > > | > Assuming I didn't mess up, the log should be at: > | > http://people.freebsd.org/~ambrisko/ipmi_ktr_dump.txt > | > again, I using ipmi(4) as module loaded via the loader. > | > | If you use "-ct" then you get a file you can feed into schedgraph. > | However, just reading the log, it seems that IRQ 20 keeps preempting > | the KCS worker thread preventing it from getting anything done. Also, > | there seem to be a lot of threads on CPU 0's runqueue waiting for a > | chance to run (load average of 12 or 13 the entire time). You can try > | just bumping up the max timeout from 3 seconds to higher perhaps. Not > | sure why IRQ 20 keeps firing though. It might be related to USB, so > | you could try fiddling with USB options in the BIOS perhaps, or disabling > | the USB drivers to see if that fixes IPMI. > > Tried without USB in kernel: > http://people.freebsd.org/~ambrisko/ipmi_ktr_dump_no_usb.txt Hmm, it's still just running constantly (note that the idle thread is _never_ scheduled). The lion's share of the time seems to be spent in "xpt_thrd". Note that there are several places where nothing happens except that "xpt_thrd" runs constantly (spinning) during 10's of statclock ticks. I would maybe start debugging that to see what in the world it is doing. Maybe it is polling some hardware down in xpt_action() (i.e., xpt_action() for a single bus called down into a driver and it is just spinning using polling instead of sleeping and waiting for an interrupt). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 19:38: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 AE8CE1065670 for ; Wed, 4 Apr 2012 19:38:21 +0000 (UTC) (envelope-from access@gmail.com) Received: from dawggonedirty.com (secure-power.com [76.12.193.213]) by mx1.freebsd.org (Postfix) with ESMTP id 68C6D8FC14 for ; Wed, 4 Apr 2012 19:38:21 +0000 (UTC) Received: (qmail 5446 invoked by uid 48); 4 Apr 2012 14:34:43 -0500 Date: 4 Apr 2012 14:34:43 -0500 Message-ID: <20120404193443.5442.qmail@dawggonedirty.com> To: freebsd-stable@freebsd.org From: access@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Subject: Real Canned Butter - case X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: access@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:38:21 -0000 Name: Dear Friend, Email: access@gmail.com Dear Friend, How I Made 1 Million Pounds In Under 7 Years Without A Job! Congratulations: Get your $621 Commissions Now!!! It's So Simple That Even A Ten Year Old Could Learn This In Under 1 Hour!""It Doesn't Matter Where In The World You Are If You Have An Internet Connection & A PC You Can Claim Hundreds Of £Pounds For Just A Few Minutes Of Clicking A Mouse " Imagine waking up at 10am in the morning, having a quick look at your PC and finding the exact information you need to collect a quick $300 by lunchtime. You could take the afternoon off, play some golf, go shopping or spend some quality time with the family. Then do the same thing again in the evening, What a wonderful concept and you could be doing it today. Even during the boom years in any economy it's not possible to find a form of free income, BUT THIS IS EXACTLY THAT! and it will make you free money for the rest of your life. It's Easy To Make Money Everyday Even If You're Starting From Scratch With Zero Knowledge, Experience Or Budget!I'll Show You Exactly How. We've Start putting New 23 Members in YOUR TEAM for the April 1th-7th 2012 weekly commission cycle...and GROWING everyday earn by $100 up to $200 or more. IMPORTANT: JApril 07th 2012, 2010 is the Cut-Off day to lock in your position then faster you act the higher commission you will earn!!! Go Here To Secure not less than $621 commission Now and it still growing as many people joining under you. if you secure your position right away: The $803.85 commission will Arrive Through your Paypal or Credit Card ...Hurry this limited time, only 3 Positions are available Now. Once your Membership are set up, you will be able to earn $621 in less than 2 hours a day.I will show you how we do that and then I will help you through the process so that YOU SUCCEED! Date Commissions Send April 30, 2012 You will access your $621 in any ATM when you Join early and you follow instructions. http://bit.ly/HUfgGh TYPE DATE & TIME --- NEW MEMBERS --- COUNTRY P -- APRIL.03 @ 2:38 AM-----Adrian Cooper------------ United States P -- APRIL.03 @ 2:53 AM-----Cristoper Parker -------- United Kingdom P -- APRIL.03 @ 2:56 AM-----Mandene Armstrong-------- Germany M -- APRIL.03 @ 4:19 AM-----Gerbert Sindongpa-------- Singapore P -- APRIL.03 @ 4:28 AM-----Carlo Echevarria--------- Italy M -- APRIL.03 @ 6:01 AM-----lalaine ferguson--------- Australia P -- APRIL.03 @ 7:11 AM-----Rebecca Underwood-------- Hungary P -- APRIL.03 @ 7:39 AM-----Jericho Sanchez---------- Canada P -- APRIL.03 @ 9:42 AM-----Thomas Coolin------------ Sri Lanka M -- APRIL.03 @ 9:58 PM-----Grace Taylor------------- Russia P -- APRIL.03 @ 10:21 PM-----Gina Jonhson------------- New Zealand P -- APRIL.03 @ 11:24 PM-----Effren Christobal-------- Romania M -- APRIL.03 @ 11:33 PM-----Tracia Miller------------ Puerto Rico P -- APRIL.03 @ 11:41 PM-----Jane furlong------------- Potugal P -- APRIL.03 @ 11:47 PM-----Janice Pulbirds---------- United States P -- APRIL.03 @ 11:53 PM-----Shirley Roots------------ United States P -- APRIL.03 @ 1:45 AM --- Ryann Lambert ----------- Europe M -- APRIL.03 @ 12:34 AM --- Nick Gauci -------------- Calefornia M -- APRIL.03 @ 10:24 AM --- Don Riley --------------- Netherland P -- APRIL.03 @ 10:30 AM --- Lorne Whittaker --------- Swetzerland P -- APRIL.03 @ 02:14 AM --- Ashwani Vohra ----------- Brazil M -- APRIL.03 @ 2:34 AM --- Kevin Hunter ------------ United States P -- APRIL.03 @ 1:54 AM --- Charles James Mills ----- South Africa Therefore, you have a GUARANTEED $621 CommissionS every month from now on!. Earn $27 Per Process!Each $27 x 23 = $621 Commission will be yours...! Be Sure to Copy the link below & Paste into your browser and press enter: To Secure your $$621 commission! You will access your money in any ATM when you follow the instructions you receive. http://bit.ly/HUfgGh If you join Now, your membership automatic cover, And you can recieve bigger commissions waiting at the end of the month. Today its $621 For the start of the month of April if goes up daily until the end of the month. You must UPGRADE right away or before others do.... Caring for Your Success, Mark Falesaine Add to Calendar April 30 2012 http://www.internet-grocer.net/store/cart.php?m=product_detail&p=1351 From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 08:46:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203FE106566B for ; Thu, 5 Apr 2012 08:46:34 +0000 (UTC) (envelope-from nm.knife@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id A896A8FC0C for ; Thu, 5 Apr 2012 08:46:33 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1179543wgb.1 for ; Thu, 05 Apr 2012 01:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EYEgFDGzg8kQDFQXamPFZIzXLWxw5EEX8LqAuAc0NiY=; b=T9davo3N50QWK/d5dY8J0e2zPZklS2Y9DNr0n/ygBPC5rHFPrFim3A1bsVKd5rDe/D 7UnXrQlxbwVqwxAq+UCMvBKHmjv16BhUpXOVitOMmt51nn7jUVv6OZBGfpckOtXwglaY 9LgTP8mTgqfvl0iijSo6MOB14Qro4vH//4xt9odSrR8gvD6y3fRDksHrqKdJC5m2csgS NDZtGVbG4jv/VZ7qnuLlz68p3jOkXq2B6KbfCAB5KttVBB6MK/3MOKBq2c1fPfex09gY DbmvMVI9aqoV02xU4rg/C6/u7NIzN64PiqidSnxWUuuCofw4lsUoJ7EZvV5HbJLsakKS ngYg== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr2735214wib.15.1333615587278; Thu, 05 Apr 2012 01:46:27 -0700 (PDT) Received: by 10.227.58.68 with HTTP; Thu, 5 Apr 2012 01:46:27 -0700 (PDT) Date: Thu, 5 Apr 2012 01:46:27 -0700 Message-ID: From: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: lowest C-state changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 08:46:34 -0000 Hello all, I am using FreeBSD 9.0-STABLE with Konstantin's patch from March 22nd. Everything else is stock. However, after heavy load, or compiling, C-states go to C1 as lowest. I think once they pass the threshold, they don't go back. ThinkPad X220 i5 2520M with integrated Intel video In /etc/sysctl.conf dev.cpu.0.cx_lowest=C3 dev.cpu.1.cx_lowest=C3 dev.cpu.2.cx_lowest=C3 dev.cpu.0.cx_lowest=C3 In /etc/rc.conf powerd_enable="YES" powerd_flags="-a hiadaptive -b adaptive -i 85 -r 60 -p 100" However, once the cores go to C1, they stay there forever, unless I manually set them all back. Any idea on this? -- Lyubomir Grigorov (bgalakazam) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 08:52: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 2CC991065673 for ; Thu, 5 Apr 2012 08:52:16 +0000 (UTC) (envelope-from nm.knife@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id A94548FC12 for ; Thu, 5 Apr 2012 08:52:15 +0000 (UTC) Received: by wibhr17 with SMTP id hr17so1184861wib.1 for ; Thu, 05 Apr 2012 01:52:08 -0700 (PDT) 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 :content-type; bh=yz7YMNN+7lXsEFvXINOABD6+miD4X/xRAw2mQR3EYeA=; b=xJJT3WoTv4mDs2WxD+QMKeuCMqVhYFv8UqO9lnSKELy+O0SLFCUYvXIzkm65ra8Hq3 7760koXgcrKjOOuhyLOrzZRgS/DGLMYQXWmKkvlYHc4U6nHSfdJqtQLBqLzRaXfqD5eg 0IfoUQeEBjSkwA0ubDofva4ZNhtjPsRKMpHS1/SbW3Y8stRngyisbAc6zQDniLjGnKBy sA4QPcHphXdvMxmRKKynjCsIsKT3VfqoabQq88RAit5BHWGlAxoMvgu00FUDHG8OF8kU Gcbme0tx7h1x+i6H7Q0HyTQp/Jysis78hmAtck2Lg2eUe++9lCNy0z78Zq1zK/S9svlg bOLg== MIME-Version: 1.0 Received: by 10.180.78.40 with SMTP id y8mr10888425wiw.15.1333615928764; Thu, 05 Apr 2012 01:52:08 -0700 (PDT) Received: by 10.227.58.68 with HTTP; Thu, 5 Apr 2012 01:52:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 01:52:08 -0700 Message-ID: From: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lowest C-state changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 08:52:16 -0000 and last one is dev.cpu.3.cx_lowest=3DC3 btw... also to add, I never drop below 50C in X. Thus fan never goes to lowest spin speed. In console it's fine. =CD=E0 05 =E0=EF=F0=E8=EB 2012, 01:46, =CB=FE=E1=EE=EC=E8=F0 =C3=F0=E8=E3= =EE=F0=EE=E2 =ED=E0=EF=E8=F1=E0: > Hello all, I am using FreeBSD 9.0-STABLE with Konstantin's patch from > March 22nd. Everything else is stock. However, after heavy load, or > compiling, C-states go to C1 as lowest. I think once they pass the > threshold, they don't go back. > > ThinkPad X220 > i5 2520M with integrated Intel video > > In /etc/sysctl.conf > dev.cpu.0.cx_lowest=3DC3 > dev.cpu.1.cx_lowest=3DC3 > dev.cpu.2.cx_lowest=3DC3 > dev.cpu.0.cx_lowest=3DC3 > > In /etc/rc.conf > powerd_enable=3D"YES" > powerd_flags=3D"-a hiadaptive -b adaptive -i 85 -r 60 -p 100" > > However, once the cores go to C1, they stay there forever, unless I > manually set them all back. > > Any idea on this? > > -- > Lyubomir Grigorov (bgalakazam) > > --=20 Lyubomir Grigorov (bgalakazam) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 10:15:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED78C1065670 for ; Thu, 5 Apr 2012 10:15:40 +0000 (UTC) (envelope-from c.kworr@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 32CEE8FC0A for ; Thu, 5 Apr 2012 10:15:40 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1457736bkc.13 for ; Thu, 05 Apr 2012 03:15:39 -0700 (PDT) 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=1kSLpl13Lq6ejCfNX87Dtk0gDLxkLqmw/HCsLhF1eII=; b=WtgCoAcuO0g7Irk+DU9ho4TXUlOgzWO9EfvHP5XvAWxwqpgxNYRMdl/n5jjym6ip90 vxQ6C3zItABILnoybzi3OF3Yxzl8mH22LADmal5xBkN0jekv4rdAFieZtuclyfwKfccs p+SKgEYOHdoisA7aIluTE4iXIG9UpcLbg5hBc7dmC4KeDmbU4l1Tt9q9pCHTyCJp+XsR NJpWF7FHWsqSJ8dkRwKey0P1K+fyvOgPSsomR2rImaHjWs3IiyovKqC3FX/j6+wkxR9b IIxxM7/9c0RNd8wIT2SlUDlawXE2ZM8huReLFkbzKu5NQf8r0BNMBCWi8fPB7qsrqqCO leaA== Received: by 10.204.141.8 with SMTP id k8mr900418bku.24.1333620939199; Thu, 05 Apr 2012 03:15:39 -0700 (PDT) Received: from green.tandem.local (13-34-132-95.pool.ukrtel.net. [95.132.34.13]) by mx.google.com with ESMTPS id r8sm7766306bki.2.2012.04.05.03.15.36 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 03:15:37 -0700 (PDT) Message-ID: <4F7D70C7.60105@gmail.com> Date: Thu, 05 Apr 2012 13:15:35 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: =?UTF-8?B?0JvRjtCx0L7QvNC40YAg0JPRgNC40LPQvtGA0L7Qsg==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: lowest C-state changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 10:15:41 -0000 Любомир Григоров wrote: > Hello all, I am using FreeBSD 9.0-STABLE with Konstantin's patch from March > 22nd. Everything else is stock. However, after heavy load, or compiling, > C-states go to C1 as lowest. I think once they pass the threshold, they > don't go back. > > ThinkPad X220 > i5 2520M with integrated Intel video > > In /etc/sysctl.conf > dev.cpu.0.cx_lowest=C3 > dev.cpu.1.cx_lowest=C3 > dev.cpu.2.cx_lowest=C3 > dev.cpu.0.cx_lowest=C3 > > In /etc/rc.conf > powerd_enable="YES" > powerd_flags="-a hiadaptive -b adaptive -i 85 -r 60 -p 100" > > However, once the cores go to C1, they stay there forever, unless I > manually set them all back. > > Any idea on this? > Have you checked http://wiki.freebsd.org/TuningPowerConsumption? 1. For CX states to function correctly you better disable throttling and powerd. I also witnessed at least one machine that hitting any CX mode stops generate interrupts on APIC clock (I had to boot it with a mousee until I disabled APIC clocks). 2. You don't need to set each processor CX value, you only need to set: hw.acpi.cpu.cx_lowest=C3 All cpu's will inherit default profile. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 10:28:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26CC9106566B for ; Thu, 5 Apr 2012 10:28:50 +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 CC0888FC14 for ; Thu, 5 Apr 2012 10:28:49 +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=7FB1rU/uoARmKLNxsKzUgZidz0RjhW1Dq+RYUzNRdnY=; b=s2cyTDRtWKEJsDt7SL5cdk8fNJPo0pJs1T00VX6477cSJplVCZpoCDuUDSXOwUKe+nHPJaps9QFD4+pKqDmwF9poePeZjgbsd4d0xMWKsXJzPd5M1McP5C5hPgVcNo6OXfYLfXEp4g7SGrHtRxvQSjE4BJ5Jj6Exnw9pboPaZuQ=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm2.ukr.net with esmtpsa ID 1SFjvm-000Jdv-6R ; Thu, 05 Apr 2012 13:28:42 +0300 Date: Thu, 5 Apr 2012 13:28:41 +0300 From: Ivan Klymenko To: Volodymyr Kostyrko Message-ID: <20120405132841.3c14625f@nonamehost.> In-Reply-To: <4F7D70C7.60105@gmail.com> References: <4F7D70C7.60105@gmail.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?0JvRjtCx0L7QvNC40YAg0JPRgNC40LPQvtGA0L7Qsg==?= , freebsd-stable@freebsd.org Subject: Re: lowest C-state changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 10:28:50 -0000 =D0=92 Thu, 05 Apr 2012 13:15:35 +0300 Volodymyr Kostyrko =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > =D0=9B=D1=8E=D0=B1=D0=BE=D0=BC=D0=B8=D1=80 =D0=93=D1=80=D0=B8=D0=B3=D0=BE= =D1=80=D0=BE=D0=B2 wrote: > > Hello all, I am using FreeBSD 9.0-STABLE with Konstantin's patch > > from March 22nd. Everything else is stock. However, after heavy > > load, or compiling, C-states go to C1 as lowest. I think once they > > pass the threshold, they don't go back. > > > > ThinkPad X220 > > i5 2520M with integrated Intel video > > > > In /etc/sysctl.conf > > dev.cpu.0.cx_lowest=3DC3 > > dev.cpu.1.cx_lowest=3DC3 > > dev.cpu.2.cx_lowest=3DC3 > > dev.cpu.0.cx_lowest=3DC3 > > > > In /etc/rc.conf > > powerd_enable=3D"YES" > > powerd_flags=3D"-a hiadaptive -b adaptive -i 85 -r 60 -p 100" > > > > However, once the cores go to C1, they stay there forever, unless I > > manually set them all back. > > > > Any idea on this? > > >=20 > Have you checked http://wiki.freebsd.org/TuningPowerConsumption? >=20 > 1. For CX states to function correctly you better disable throttling > and powerd. I also witnessed at least one machine that hitting any CX > mode stops generate interrupts on APIC clock (I had to boot it with a > mousee until I disabled APIC clocks). >=20 > 2. You don't need to set each processor CX value, you only need to > set: >=20 > hw.acpi.cpu.cx_lowest=3DC3 >=20 > All cpu's will inherit default profile. >=20 First need to see what state the processor supports the current system sysctl -a | grep cx_ From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 11:05: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 EFE60106567A for ; Thu, 5 Apr 2012 11:05:58 +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 A033F8FC1A for ; Thu, 5 Apr 2012 11:05:58 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFkVg-0003pV-0w for freebsd-stable@freebsd.org; Thu, 05 Apr 2012 13:05:48 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2012 13:05:48 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2012 13:05:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 05 Apr 2012 13:05:33 +0200 Lines: 29 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF6C3B50852E1D19DD97CBBF" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: X-Enigmail-Version: 1.3.5 Subject: Re: Compatibility with the new XEON Processors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 11:05:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBF6C3B50852E1D19DD97CBBF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/04/2012 18:03, Efra=C3=ADn D=C3=A9ctor wrote: > Hello. >=20 > Does anyone know if FreeBSD 8.2 and FreeBSD 9.1 are fully compatible wi= th this processor: Intel XEON E3 1270 ?. Yes. --------------enigBF6C3B50852E1D19DD97CBBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk99fH0ACgkQldnAQVacBcgIMACfRVWg/Ld+Sd/s2+LlhCKhd38n 8N8AoLiOWor/xIwzylHPXJPD9njY2gCa =Tfki -----END PGP SIGNATURE----- --------------enigBF6C3B50852E1D19DD97CBBF-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 17:10:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C55DF106566B for ; Thu, 5 Apr 2012 17:10:47 +0000 (UTC) (envelope-from nm.knife@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2468FC0A for ; Thu, 5 Apr 2012 17:10:47 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1516143wgb.31 for ; Thu, 05 Apr 2012 10:10:46 -0700 (PDT) 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=Mq9iGX0TNVxD43bgY4cjD4n9obKgADW60C4H962qlNI=; b=ehGA2p6p4NLsCQbYEX6USTLC4a9i55PwphpzZRmPs8J7tSV+G7uusRcmIVA93GtNK2 BLKz1+wGF7oLgm0HnNBt2yoMU98gYC6M7OoXSSmSQQbePsYAzcNtdCWPDzrHOeqFcOnK RVy1t4WNpclsZ7sXQe2s+b2zOTgxOH5J45hQpsc60cR9+JGIWMXfyAnAEC6EJYycenxT +YFZ97YKDw4zUQfA7Y1QRDSwcaMrgrJmeIMWXPnHBR4aEyV4c+vozFR+SLX/WR0Fg3d+ s8dKiNUDoy0l3brEQotQ4ZLS+Zh+OFfWpw7paJqMeUGdJWMOy9uFzqDhH0eJGM88TqdW mdmA== MIME-Version: 1.0 Received: by 10.180.86.132 with SMTP id p4mr6628618wiz.15.1333645831674; Thu, 05 Apr 2012 10:10:31 -0700 (PDT) Received: by 10.227.58.68 with HTTP; Thu, 5 Apr 2012 10:10:30 -0700 (PDT) In-Reply-To: <4f7d73db.96e7d80a.509c.2afaSMTPIN_ADDED@mx.google.com> References: <4F7D70C7.60105@gmail.com> <4f7d73db.96e7d80a.509c.2afaSMTPIN_ADDED@mx.google.com> Date: Thu, 5 Apr 2012 10:10:30 -0700 Message-ID: From: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= To: Ivan Klymenko , Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: lowest C-state changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 17:10:47 -0000 > Have you checked http://wiki.freebsd.org/TuningPowerConsumption? I have. It was kind of confusing and didn't know about: > 1. For CX states to function correctly you better disable throttling > and powerd. I also witnessed at least one machine that hitting any CX > mode stops generate interrupts on APIC clock (I had to boot it with a > mousee until I disabled APIC clocks). So do you recommend I use throttling or C3? I think C3 runs slightly cooler. I can't tell since I don't drop under 50C in X. Fan increases at 60C and drops me back. > 2. You don't need to set each processor CX value, you only need to > set: > > hw.acpi.cpu.cx_lowest=C3 > > All cpu's will inherit default profile. > Thanks. > First need to see what state the processor supports the current > system >sysctl -a | grep cx_ This is before heavy load while it still remembers the C3: hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1 C2/80 C3/109 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.89% 0.77% 98.32% last 47us dev.cpu.1.cx_supported: C1/1 C2/80 C3/109 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 3.30% 3.18% 93.50% last 3852us dev.cpu.2.cx_supported: C1/1 C2/80 C3/109 dev.cpu.2.cx_lowest: C3 dev.cpu.2.cx_usage: 2.95% 1.42% 95.61% last 293us dev.cpu.3.cx_supported: C1/1 C2/80 C3/109 dev.cpu.3.cx_lowest: C3 dev.cpu.3.cx_usage: 2.73% 1.55% 95.71% last 8471us After lowest becomes C1, all 4 cores are 100% C1. So I have to manually set back, or disable powerd or C states. I prefer powerd, tbh, so please recommend what I should use. Cheers. -- Lyubomir Grigorov (bgalakazam) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 17:31:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 507911065672 for ; Thu, 5 Apr 2012 17:31:12 +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 009158FC0A for ; Thu, 5 Apr 2012 17:31:11 +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=y7PIKNYjv9rx76zA9hwYOk2Wxd4MTlqRb2PS4aRpwJU=; b=DeoWfFrhO6nvlQs85+4Qq43wGkidxxhCTveQIJhnpEODVORTUwXoPcuad87Me2Mid497aLXqKI5izP3OXW1nr2zKvggtwNGvV6C89VI8vIqTgXO6z1OocTF9h8NOn21Nzl10z/Pp88Vcp+HIYwrF1lWyci61E+kEPzc+YXbxi8I=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm2.ukr.net with esmtpsa ID 1SFqWb-000HDc-SB ; Thu, 05 Apr 2012 20:31:09 +0300 Date: Thu, 5 Apr 2012 20:31:07 +0300 From: Ivan Klymenko To: =?UTF-8?B?0JvRjtCx0L7QvNC40YAg0JPRgNC40LPQvtGA0L7Qsg==?= Message-ID: <20120405203107.60cb3b79@nonamehost.> In-Reply-To: References: <4F7D70C7.60105@gmail.com> <4f7d73db.96e7d80a.509c.2afaSMTPIN_ADDED@mx.google.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Volodymyr Kostyrko , freebsd-stable@freebsd.org Subject: Re: lowest C-state changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 17:31:12 -0000 =D0=92 Thu, 5 Apr 2012 10:10:30 -0700 =D0=9B=D1=8E=D0=B1=D0=BE=D0=BC=D0=B8=D1=80 =D0=93=D1=80=D0=B8=D0=B3=D0=BE= =D1=80=D0=BE=D0=B2 =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Have you checked http://wiki.freebsd.org/TuningPowerConsumption? > I have. It was kind of confusing and didn't know about: > > 1. For CX states to function correctly you better disable throttling > > and powerd. I also witnessed at least one machine that hitting any > > CX mode stops generate interrupts on APIC clock (I had to boot it > > with a mousee until I disabled APIC clocks). > So do you recommend I use throttling or C3? I think C3 runs slightly > cooler. I can't tell since I don't drop under 50C in X. Fan increases > at 60C and drops me back. >=20 > > 2. You don't need to set each processor CX value, you only need to > > set: > > > > hw.acpi.cpu.cx_lowest=3DC3 > > > > All cpu's will inherit default profile. > > > Thanks. >=20 > > First need to see what state the processor supports the current > > system > >sysctl -a | grep cx_ > This is before heavy load while it still remembers the C3: >=20 > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/1 C2/80 C3/109 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.89% 0.77% 98.32% last 47us > dev.cpu.1.cx_supported: C1/1 C2/80 C3/109 > dev.cpu.1.cx_lowest: C3 > dev.cpu.1.cx_usage: 3.30% 3.18% 93.50% last 3852us > dev.cpu.2.cx_supported: C1/1 C2/80 C3/109 > dev.cpu.2.cx_lowest: C3 > dev.cpu.2.cx_usage: 2.95% 1.42% 95.61% last 293us > dev.cpu.3.cx_supported: C1/1 C2/80 C3/109 > dev.cpu.3.cx_lowest: C3 > dev.cpu.3.cx_usage: 2.73% 1.55% 95.71% last 8471us >=20 > After lowest becomes C1, all 4 cores are 100% C1. So I have to > manually set back, or disable powerd or C states. I prefer powerd, > tbh, so please recommend what I should use. >=20 > Cheers. >=20 sysctl hw.acpi.acline - changes its value when disconnecting the power supply to the laptop? From owner-freebsd-stable@FreeBSD.ORG Thu Apr 5 17:47: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 5882E106566B for ; Thu, 5 Apr 2012 17:47:09 +0000 (UTC) (envelope-from c.kworr@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 C9A648FC0A for ; Thu, 5 Apr 2012 17:47:08 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1922810bkc.13 for ; Thu, 05 Apr 2012 10:47:07 -0700 (PDT) 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=qYShBwWpsvXcwMfsXlD00IY4rfZ273ts8z5oWspBmjk=; b=VR2OFXRcy4eAyD3C/Em2zkxPsPHMf5T/4LeVQVs85NAasQXTXxP/1e4CLxd83mv5vR GAksXKqi6Xub7XqIki3x7/ZQ/wEqJIT77AGYuEbSEihC+Kh2xll+j11LCipZk+wem2/H iFCPcyeAr327T1MbCm4l7VV1SfZcQZysRRB/Sh44eCBHAknnunPzC/8zu3VQ7EGxt9x5 B4Z8Ikc+6cjm54nBSxO+ulj+QitOKByS//VwsVVP10WHMJh8I5I+UWxem5lG9P1yeJUs CALDQM0p8wzyf42gKHjNOj2YR6uCOlTs+Tr27iXLIRVWMRUotuBy2eYWYKYI1ZPXZ8D6 ILvw== Received: by 10.204.151.89 with SMTP id b25mr1509453bkw.18.1333648027573; Thu, 05 Apr 2012 10:47:07 -0700 (PDT) Received: from limbo.lan ([195.225.157.86]) by mx.google.com with ESMTPS id cy11sm10138116bkb.7.2012.04.05.10.47.04 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 10:47:06 -0700 (PDT) Message-ID: <4F7DDA96.4010305@gmail.com> Date: Thu, 05 Apr 2012 20:47:02 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: =?UTF-8?B?0JvRjtCx0L7QvNC40YAg0JPRgNC40LPQvtGA0L7Qsg==?= References: <4F7D70C7.60105@gmail.com> <4f7d73db.96e7d80a.509c.2afaSMTPIN_ADDED@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Ivan Klymenko , freebsd-stable@freebsd.org Subject: Re: lowest C-state changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2012 17:47:09 -0000 =D0=9B=D1=8E=D0=B1=D0=BE=D0=BC=D0=B8=D1=80 =D0=93=D1=80=D0=B8=D0=B3=D0=BE= =D1=80=D0=BE=D0=B2 wrote: > > Have you checked http://wiki.freebsd.org/TuningPowerConsumption? > I have. It was kind of confusing and didn't know about: > > 1. For CX states to function correctly you better disable throttling= > > and powerd. I also witnessed at least one machine that hitting any C= X > > mode stops generate interrupts on APIC clock (I had to boot it with = a > > mousee until I disabled APIC clocks). > So do you recommend I use throttling or C3? I think C3 runs slightly > cooler. I can't tell since I don't drop under 50C in X. Fan increases a= t > 60C and drops me back. I wouldn't dare to recommend any particular configuration. Most times=20 throttling is safer and with CX states you can get cooler. But both of=20 them doesn't play nice together. If you want higher cooling you can try=20 to disable throttling (and you will not need powerd as powerd takes care = of frequencies) and enable CX but you will need to test everything=20 thoroughly as unepected bugs can show up. Remember, the default way=20 isn't the better one, just the safer one. > > First need to see what state the processor supports the current > > system > >sysctl -a | grep cx_ > This is before heavy load while it still remembers the C3: It's just about ability to set C3 or any other particular state. Some=20 processors show only C1 state as available. For example: > sysctl hw.model hw.model: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > sysctl dev.cpu | grep cx dev.cpu.0.cx_supported: C1/1 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 293us dev.cpu.1.cx_supported: C1/1 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 15us Setting lower CX on this machine results in: # sysctl hw.acpi.cpu.cx_lowest=3DC3 hw.acpi.cpu.cx_lowest: C1 sysctl: hw.acpi.cpu.cx_lowest: Invalid argument --=20 Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 6 07:48:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC63D106564A for ; Fri, 6 Apr 2012 07:48:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 606228FC15 for ; Fri, 6 Apr 2012 07:48:15 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SG3u1-000Ian-Te for freebsd-stable@freebsd.org; Fri, 06 Apr 2012 10:48:14 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Apr 2012 10:48:13 +0300 From: Daniel Braniss Message-ID: Subject: 8.3-PRERELEASE and ATA_CAM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Apr 2012 07:48:15 -0000 with the latest svn, I can't compile kernel with options ATA_CAM: ... linking kernel.debug ata-disk.o(.text+0x93): In function `ad_init': /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to `ata_setmode' ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: undefined reference to `ata_wc' ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: undefined reference to `ata_controlcmd' ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: undefined reference to `ata_controlcmd' ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: undefined reference to `ata_controlcmd' ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: undefined reference to `ata_controlcmd' ata-disk.o(.text+0x21a): In function `ad_shutdown': /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to `ata_controlcmd' ata-disk.o(.text+0x45c): In function `ad_detach': /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to `ata_fail_requests' ... danny From owner-freebsd-stable@FreeBSD.ORG Fri Apr 6 10:17:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B1B0106564A; Fri, 6 Apr 2012 10:17:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 332578FC08; Fri, 6 Apr 2012 10:17:18 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so337090wib.13 for ; Fri, 06 Apr 2012 03:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Dwa2bmPA5hjiEWgEEyjsap/2xtyLmQ9+f0sEE+s3PuM=; b=0G3RfwEKkxSlBM56X5uDqtAlhMNESgvGnPCl0sdXALBUibxz0E1wxQvVZuDhzmdQDY I4W74lil0wRTydcuIpeHXFfdAmTbsFJTh2am70Zk7PZJxL8rGjmqi2dDS9dcJkCzJxiF PoYjFSwFcnchOaFAOGOYbpqA58G5U+IGas+te2QwqkCU9upMRKdOLDMswDojERUHwHyY Ok70QbnJ443PDmApv7oaaHAz8HZHzBFOeUV6kNbjZj3WduI07Y4+ujUaorkrcOes3ODz Jg02Q3cbJ/xvNZ+mynCynzt3gupYMQgw8s2rYaOahwRRpLLKK/4BUY5JE8MV/nXbUX4f uhog== Received: by 10.180.101.230 with SMTP id fj6mr18667536wib.13.1333707436263; Fri, 06 Apr 2012 03:17:16 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id o2sm8494973wiv.11.2012.04.06.03.17.13 (version=SSLv3 cipher=OTHER); Fri, 06 Apr 2012 03:17:14 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F7EC2A8.3000001@FreeBSD.org> Date: Fri, 06 Apr 2012 13:17:12 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Baldwin References: <201204041624.q34GOXvc063506@ambrisko.com> <201204041447.49398.jhb@freebsd.org> In-Reply-To: <201204041447.49398.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, scottl@freebsd.org Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Apr 2012 10:17:19 -0000 On 04/04/12 21:47, John Baldwin wrote: > On Wednesday, April 04, 2012 12:24:33 pm Doug Ambrisko wrote: >> John Baldwin writes: >> | On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: >> |> John Baldwin writes: >> |> | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: >> |> |> Doug Ambrisko writes: >> |> |> | John Baldwin writes: >> |> |> | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: >> |> |> | |> Sean Bruno writes: >> |> |> | |> | Noting a failure to attach to the onboard IPMI controller > with >> | this >> |> | dell >> |> |> | |> | R815. Not sure what to start poking at and thought I'd > though >> | this >> |> | over >> |> |> | |> | here for comment. >> |> |> | |> | >> |> |> | |> | -bash-4.2$ dmesg |grep ipmi >> |> |> | |> | ipmi0: KCS mode found at io 0xca8 on acpi >> |> |> | |> | ipmi1: on isa0 >> |> |> | |> | device_attach: ipmi1 attach returned 16 >> |> |> | |> | ipmi1: on isa0 >> |> |> | |> | device_attach: ipmi1 attach returned 16 >> |> |> | |> | ipmi0: Timed out waiting for GET_DEVICE_ID >> |> |> | |> >> |> |> | |> I've run into this recently. A quick hack to fix it is: >> |> |> | |> >> |> |> | |> Index: ipmi.c >> |> |> | |> >> | =================================================================== >> |> |> | |> RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v >> |> |> | |> retrieving revision 1.14 >> |> |> | |> diff -u -p -r1.14 ipmi.c >> |> |> | |> --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 >> |> |> | |> +++ ipmi.c 31 Mar 2012 19:18:35 -0000 >> |> |> | |> @@ -695,7 +695,6 @@ ipmi_startup(void *arg) >> |> |> | |> if (error == EWOULDBLOCK) { >> |> |> | |> device_printf(dev, "Timed out waiting for >> | GET_DEVICE_ID\n"); >> |> |> | |> ipmi_free_request(req); >> |> |> | |> - return; >> |> |> | |> } else if (error) { >> |> |> | |> device_printf(dev, "Failed GET_DEVICE_ID: %d\n", > error); >> |> |> | |> ipmi_free_request(req); >> |> |> | |> >> |> |> | |> The issue is that the wakeup doesn't actually wake up the > msleep >> |> |> | |> in ipmi_submit_driver_request. The error being reported is > that >> |> |> | |> the msleep timed out. This doesn't seem to be critical > problem >> |> |> | |> since after this things seemed to work work. I saw this on > 9.X. >> |> |> | |> Haven't seen it on 8.2. Not sure about -current. >> |> |> | |> >> |> |> | |> It doesn't happen on all machines. >> |> |> | | >> |> |> | | Hmm, are you seeing the KCS thread manage the request but the >> | wakeup() >> |> | is >> |> |> | | lost? >> |> |> | >> |> |> | It was a couple of weeks ago that I played with it. I put > printf's >> |> |> | around the msleep and wakeup. I saw the wakeup called but the > sleep >> |> |> | not get it. I can try the test again later today. Right now my > main >> |> |> | work machine is recovering from a power outage. This was with 9.0 >> |> |> | when I first saw it. This issue seems to only happen at boot > time. >> |> |> | If I kldload the module after the system is booted then it seems > to >> | work >> |> |> | okay. The KCS part was working fine and got the data okay from > the >> |> |> | request. I haven't seen or heard any issues with 8.2. >> |> |> >> |> |> With -current I patched ipmi.c with: >> |> |> Index: ipmi.c >> |> |> =================================================================== >> |> |> --- ipmi.c (revision 233806) >> |> |> +++ ipmi.c (working copy) >> |> |> @@ -523,7 +523,11 @@ >> |> |> * waiter that we awaken. >> |> |> */ >> |> |> if (req->ir_owner == NULL) >> |> |> +{ >> |> |> +device_printf(sc->ipmi_dev, "DEBUG %s %d before wakeup >> |> | %d\n",__FUNCTION__,__LINE__,ticks); >> |> |> wakeup(req); >> |> |> +device_printf(sc->ipmi_dev, "DEBUG %s %d after wakeup >> |> | %d\n",__FUNCTION__,__LINE__,ticks); >> |> |> +} >> |> |> else { >> |> |> dev = req->ir_owner; >> |> |> TAILQ_INSERT_TAIL(&dev->ipmi_completed_requests, > req, >> |> | ir_link); >> |> |> @@ -543,7 +547,11 @@ >> |> |> IPMI_LOCK(sc); >> |> |> error = sc->ipmi_enqueue_request(sc, req); >> |> |> if (error == 0) >> |> |> +{ >> |> |> +device_printf(sc->ipmi_dev, "DEBUG %s %d before msleep >> |> | %d\n",__FUNCTION__,__LINE__,ticks); >> |> |> error = msleep(req,&sc->ipmi_lock, 0, "ipmireq", > timo); >> |> |> +device_printf(sc->ipmi_dev, "DEBUG %s %d after msleep >> |> | %d\n",__FUNCTION__,__LINE__,ticks); >> |> |> +} >> |> |> if (error == 0) >> |> |> error = req->ir_error; >> |> |> IPMI_UNLOCK(sc); >> |> |> @@ -695,8 +703,11 @@ >> |> |> error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT); >> |> |> if (error == EWOULDBLOCK) { >> |> |> device_printf(dev, "Timed out waiting for >> | GET_DEVICE_ID\n"); >> |> |> + printf("DJA\n"); >> |> |> +/* >> |> |> ipmi_free_request(req); >> |> |> return; >> |> |> +*/ >> |> |> } else if (error) { >> |> |> device_printf(dev, "Failed GET_DEVICE_ID: %d\n", > error); >> |> |> ipmi_free_request(req); >> |> |> >> |> |> and get >> |> |> # dmesg | grep ipmi >> |> |> ipmi0: KCS mode found at io 0xca8 on acpi >> |> |> ipmi1: on isa0 >> |> |> device_attach: ipmi1 attach returned 16 >> |> |> ipmi1: on isa0 >> |> |> device_attach: ipmi1 attach returned 16 >> |> |> ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 >> |> |> ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201 >> |> |> ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263 >> |> |> ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323 >> |> | >> |> | Actually, can you compile with: >> |> | >> |> | options KTR >> |> | options KTR_COMPILE=KTR_SCHED >> |> | options KTR_MASK=KTR_SCHED >> |> | >> |> | and then add a temporary hack to ipmi.c to set ktr_mask to 0 after >> |> | ipmi_submit_driver_request() returns in ipmi_startup()? You can >> |> | then use 'ktrdump -ct' after boot to capture a log of what the > scheduler >> |> | did including if it timed out the sleep, etc. I think this would be >> |> | useful for figuring out what went wrong. It does seem that it timed >> |> | out after 3 seconds. >> |> >> |> Assuming I didn't mess up, the log should be at: >> |> http://people.freebsd.org/~ambrisko/ipmi_ktr_dump.txt >> |> again, I using ipmi(4) as module loaded via the loader. >> | >> | If you use "-ct" then you get a file you can feed into schedgraph. >> | However, just reading the log, it seems that IRQ 20 keeps preempting >> | the KCS worker thread preventing it from getting anything done. Also, >> | there seem to be a lot of threads on CPU 0's runqueue waiting for a >> | chance to run (load average of 12 or 13 the entire time). You can try >> | just bumping up the max timeout from 3 seconds to higher perhaps. Not >> | sure why IRQ 20 keeps firing though. It might be related to USB, so >> | you could try fiddling with USB options in the BIOS perhaps, or disabling >> | the USB drivers to see if that fixes IPMI. >> >> Tried without USB in kernel: >> http://people.freebsd.org/~ambrisko/ipmi_ktr_dump_no_usb.txt > > Hmm, it's still just running constantly (note that the idle thread is > _never_ scheduled). The lion's share of the time seems to be spent in > "xpt_thrd". Note that there are several places where nothing happens except > that "xpt_thrd" runs constantly (spinning) during 10's of statclock ticks. I > would maybe start debugging that to see what in the world it is doing. Maybe > it is polling some hardware down in xpt_action() (i.e., xpt_action() for a > single bus called down into a driver and it is just spinning using polling > instead of sleeping and waiting for an interrupt). "xpt_thrd" is a bus scanner thread. It is scheduled by CAM for every bus on attach and by controller driver on hot-plug events. For some controllers it may be quite CPU-hungry. For example, for legacy ATA controllers, where bus reset may take many seconds of hardware polling, while devices just spinning up. For ahci(4) it was improved about year ago to not use polling when possible, but it still may loop for some time if controller is not responding on reset. What mfi(4), mentioned in log, does during scanning, I am not sure. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Apr 6 17:12:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85EC1106566B; Fri, 6 Apr 2012 17:12:27 +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 4CB4B8FC08; Fri, 6 Apr 2012 17:12:27 +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 Apr 2012 10:12:27 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q36HCKn1033409; Fri, 6 Apr 2012 10:12:20 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q36HCKJP033408; Fri, 6 Apr 2012 10:12:20 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201204061712.q36HCKJP033408@ambrisko.com> In-Reply-To: <4F7EC2A8.3000001@FreeBSD.org> To: Alexander Motin Date: Fri, 6 Apr 2012 10:12:20 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@FreeBSD.org, sbruno@FreeBSD.org, scottl@FreeBSD.org, John Baldwin Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Apr 2012 17:12:27 -0000 Alexander Motin writes: [ Charset ISO-8859-1 unsupported, converting... ] | On 04/04/12 21:47, John Baldwin wrote: | > On Wednesday, April 04, 2012 12:24:33 pm Doug Ambrisko wrote: | >> John Baldwin writes: | >> | On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: | >> |> John Baldwin writes: | >> |> | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: | >> |> |> Doug Ambrisko writes: | >> |> |> | John Baldwin writes: | >> |> |> | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: | >> |> |> | |> Sean Bruno writes: | >> |> |> | |> | Noting a failure to attach to the onboard IPMI controller | > with | >> | this | >> |> | dell | >> |> |> | |> | R815. Not sure what to start poking at and thought I'd | > though | >> | this | >> |> | over | >> |> |> | |> | here for comment. | >> |> |> | |> | | >> |> |> | |> | -bash-4.2$ dmesg |grep ipmi | >> |> |> | |> | ipmi0: KCS mode found at io 0xca8 on acpi | >> |> |> | |> | ipmi1: on isa0 | >> |> |> | |> | device_attach: ipmi1 attach returned 16 | >> |> |> | |> | ipmi1: on isa0 | >> |> |> | |> | device_attach: ipmi1 attach returned 16 | >> |> |> | |> | ipmi0: Timed out waiting for GET_DEVICE_ID | >> |> |> | |> | >> |> |> | |> I've run into this recently. A quick hack to fix it is: | >> |> |> | |> | >> |> |> | |> Index: ipmi.c | >> |> |> | |> [snip] | >> | If you use "-ct" then you get a file you can feed into schedgraph. | >> | However, just reading the log, it seems that IRQ 20 keeps preempting | >> | the KCS worker thread preventing it from getting anything done. Also, | >> | there seem to be a lot of threads on CPU 0's runqueue waiting for a | >> | chance to run (load average of 12 or 13 the entire time). You can try | >> | just bumping up the max timeout from 3 seconds to higher perhaps. Not | >> | sure why IRQ 20 keeps firing though. It might be related to USB, so | >> | you could try fiddling with USB options in the BIOS perhaps, or disabling | >> | the USB drivers to see if that fixes IPMI. | >> | >> Tried without USB in kernel: | >> http://people.freebsd.org/~ambrisko/ipmi_ktr_dump_no_usb.txt | > | > Hmm, it's still just running constantly (note that the idle thread is | > _never_ scheduled). The lion's share of the time seems to be spent in | > "xpt_thrd". Note that there are several places where nothing happens except | > that "xpt_thrd" runs constantly (spinning) during 10's of statclock ticks. I | > would maybe start debugging that to see what in the world it is doing. Maybe | > it is polling some hardware down in xpt_action() (i.e., xpt_action() for a | > single bus called down into a driver and it is just spinning using polling | > instead of sleeping and waiting for an interrupt). | | "xpt_thrd" is a bus scanner thread. It is scheduled by CAM for every bus | on attach and by controller driver on hot-plug events. For some | controllers it may be quite CPU-hungry. For example, for legacy ATA | controllers, where bus reset may take many seconds of hardware polling, | while devices just spinning up. For ahci(4) it was improved about year | ago to not use polling when possible, but it still may loop for some | time if controller is not responding on reset. What mfi(4), mentioned in | log, does during scanning, I am not sure. I thought that mfi(4) could be an issue. There are some ata controllers with nothing attached. I built a GENERIC with USB and mfi commented out and then the timeout issue went away: ipmi0: KCS mode found at io 0xca8 on acpi ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 1 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 2211 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 2272 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 2332 ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 Without mfi and with USB and it had issues: ipmi0: KCS mode found at io 0xca8 on acpi ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 ipmi0: Timed out waiting for GET_DEVICE_ID ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 I can post more ktrdump traces if needed. A 1U Dell machine without mfi also has this problem. As John mentioned it might be good to bump up the timeout from 3s to 6s. I did that with the USB no mfi kernel and that passed: % dmesg | grep ipmi ipmi0: KCS mode found at io 0xca8 on acpi ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 So maybe we need to agressively bump up the timeout. I put a timeout since I didn't want the system to hang. Anyone have a good idea of a timeout. I thought I tried 6s initially and it had issues but then the machine I was playing with had 3 mfi cards and various disks hanging off it. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 6 17:17:08 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 C56311065670 for ; Fri, 6 Apr 2012 17:17:08 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5A19A8FC0C for ; Fri, 6 Apr 2012 17:17:08 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q36HGiTH009210; Fri, 6 Apr 2012 19:16:44 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q36HGinT009209; Fri, 6 Apr 2012 19:16:44 +0200 (CEST) (envelope-from marius) Date: Fri, 6 Apr 2012 19:16:44 +0200 From: Marius Strobl To: Daniel Braniss Message-ID: <20120406171644.GA9162@alchemy.franken.de> References: 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-stable@freebsd.org Subject: Re: 8.3-PRERELEASE and ATA_CAM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Apr 2012 17:17:08 -0000 On Fri, Apr 06, 2012 at 10:48:13AM +0300, Daniel Braniss wrote: > with the latest svn, I can't compile kernel with options ATA_CAM: > > ... > linking kernel.debug > ata-disk.o(.text+0x93): In function `ad_init': > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to > `ata_setmode' > ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: undefined > reference to `ata_wc' > ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x21a): In function `ad_shutdown': > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to > `ata_controlcmd' > ata-disk.o(.text+0x45c): In function `ad_detach': > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to > `ata_fail_requests' > ... > You seem to be using a mutually exclusive set of ata(4) options and devices (previously, this erroneously wasn't a bug). When including options ATA_CAM you do _not_ want to also include any of the following devices: device atapicam device atadisk device ataraid device atapicd device atapifd device atapist Instead you need the corresponding driver from the following set: device scbus device ch device da device sa device cd device pass Marius From owner-freebsd-stable@FreeBSD.ORG Fri Apr 6 17:27: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 AD000106566C; Fri, 6 Apr 2012 17:27:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A8D1F8FC16; Fri, 6 Apr 2012 17:27:14 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2356743wgb.31 for ; Fri, 06 Apr 2012 10:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mGd+H0YuOPYDvcyBZXm1HUlKyvFWf4DabLoYAsf2MmI=; b=Yw1bRoPcxNEkfi227OlqBgA7nVdpkeTlKQGq3mhL/8FD6fIObr8ehNDI4wa6I3wrQ8 7blX0D9A1c7t0qJfQpL+dEz4NHAqdtqmi9z3L1tx5lukjx7oEmV9trY0/wtXVvP66Zi9 4YQLGyvyJQz/dSZd5DIjmtOAispf1jO7oRD2toQoUKDhPL8emAgyafqL3OOOKrdryVE0 phKX7OnHyVZwG/HMd806l1BXRtdRO2yVftjGaiZpp9uz0X7cX+JJCdkk4r/e0O7XSY6i +uVKXpkYsDfdihAeNw3U0lk/SnxgBfCJ+VYWlApbKZq97oOXSKHw49xUZHcoDE1PKQqQ N2Rw== Received: by 10.216.136.157 with SMTP id w29mr4407578wei.23.1333733233839; Fri, 06 Apr 2012 10:27:13 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id l5sm8142205wia.11.2012.04.06.10.27.12 (version=SSLv3 cipher=OTHER); Fri, 06 Apr 2012 10:27:13 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F7F276F.6080409@FreeBSD.org> Date: Fri, 06 Apr 2012 20:27:11 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Doug Ambrisko References: <201204061712.q36HCKJP033408@ambrisko.com> In-Reply-To: <201204061712.q36HCKJP033408@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scottl@FreeBSD.org, sbruno@FreeBSD.org, freebsd-stable@FreeBSD.org, John Baldwin Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Apr 2012 17:27:15 -0000 On 04/06/12 20:12, Doug Ambrisko wrote: > Alexander Motin writes: > [ Charset ISO-8859-1 unsupported, converting... ] > | On 04/04/12 21:47, John Baldwin wrote: > |> On Wednesday, April 04, 2012 12:24:33 pm Doug Ambrisko wrote: > |>> John Baldwin writes: > |>> | On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: > |>> |> John Baldwin writes: > |>> |> | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: > |>> |> |> Doug Ambrisko writes: > |>> |> |> | John Baldwin writes: > |>> |> |> | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: > |>> |> |> | |> Sean Bruno writes: > |>> |> |> | |> | Noting a failure to attach to the onboard IPMI controller > |> with > |>> | this > |>> |> | dell > |>> |> |> | |> | R815. Not sure what to start poking at and thought I'd > |> though > |>> | this > |>> |> | over > |>> |> |> | |> | here for comment. > |>> |> |> | |> | > |>> |> |> | |> | -bash-4.2$ dmesg |grep ipmi > |>> |> |> | |> | ipmi0: KCS mode found at io 0xca8 on acpi > |>> |> |> | |> | ipmi1: on isa0 > |>> |> |> | |> | device_attach: ipmi1 attach returned 16 > |>> |> |> | |> | ipmi1: on isa0 > |>> |> |> | |> | device_attach: ipmi1 attach returned 16 > |>> |> |> | |> | ipmi0: Timed out waiting for GET_DEVICE_ID > |>> |> |> | |> > |>> |> |> | |> I've run into this recently. A quick hack to fix it is: > |>> |> |> | |> > |>> |> |> | |> Index: ipmi.c > |>> |> |> | |> > [snip] > |>> | If you use "-ct" then you get a file you can feed into schedgraph. > |>> | However, just reading the log, it seems that IRQ 20 keeps preempting > |>> | the KCS worker thread preventing it from getting anything done. Also, > |>> | there seem to be a lot of threads on CPU 0's runqueue waiting for a > |>> | chance to run (load average of 12 or 13 the entire time). You can try > |>> | just bumping up the max timeout from 3 seconds to higher perhaps. Not > |>> | sure why IRQ 20 keeps firing though. It might be related to USB, so > |>> | you could try fiddling with USB options in the BIOS perhaps, or disabling > |>> | the USB drivers to see if that fixes IPMI. > |>> > |>> Tried without USB in kernel: > |>> http://people.freebsd.org/~ambrisko/ipmi_ktr_dump_no_usb.txt > |> > |> Hmm, it's still just running constantly (note that the idle thread is > |> _never_ scheduled). The lion's share of the time seems to be spent in > |> "xpt_thrd". Note that there are several places where nothing happens except > |> that "xpt_thrd" runs constantly (spinning) during 10's of statclock ticks. I > |> would maybe start debugging that to see what in the world it is doing. Maybe > |> it is polling some hardware down in xpt_action() (i.e., xpt_action() for a > |> single bus called down into a driver and it is just spinning using polling > |> instead of sleeping and waiting for an interrupt). > | > | "xpt_thrd" is a bus scanner thread. It is scheduled by CAM for every bus > | on attach and by controller driver on hot-plug events. For some > | controllers it may be quite CPU-hungry. For example, for legacy ATA > | controllers, where bus reset may take many seconds of hardware polling, > | while devices just spinning up. For ahci(4) it was improved about year > | ago to not use polling when possible, but it still may loop for some > | time if controller is not responding on reset. What mfi(4), mentioned in > | log, does during scanning, I am not sure. > > I thought that mfi(4) could be an issue. There are some ata controllers > with nothing attached. I built a GENERIC with USB and mfi commented out > and then the timeout issue went away: > ipmi0: KCS mode found at io 0xca8 on acpi > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 1 > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 2211 > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 2272 > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 2332 > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 > > Without mfi and with USB and it had issues: > ipmi0: KCS mode found at io 0xca8 on acpi > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 > ipmi0: Timed out waiting for GET_DEVICE_ID > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 > > I can post more ktrdump traces if needed. A 1U Dell machine without > mfi also has this problem. As John mentioned it might be good to > bump up the timeout from 3s to 6s. I did that with the USB no mfi > kernel and that passed: > > % dmesg | grep ipmi > ipmi0: KCS mode found at io 0xca8 on acpi > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 > > So maybe we need to agressively bump up the timeout. I put a > timeout since I didn't want the system to hang. Anyone have a > good idea of a timeout. I thought I tried 6s initially and it > had issues but then the machine I was playing with had 3 mfi > cards and various disks hanging off it. I have no idea about IPMI timeout to propose, but can't that check be remade opposite: if response received -- use it, otherwise -- check error value? Obviously it is not IPMI problem that CPU is busy, but ability to work in those conditions would be a bonus. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Apr 6 18:01:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E16A4106566B; Fri, 6 Apr 2012 18:01:15 +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 9A6C48FC12; Fri, 6 Apr 2012 18:01:15 +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 Apr 2012 11:01:22 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q36I1FK7041178; Fri, 6 Apr 2012 11:01:15 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q36I1FVw041177; Fri, 6 Apr 2012 11:01:15 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201204061801.q36I1FVw041177@ambrisko.com> In-Reply-To: <4F7F276F.6080409@FreeBSD.org> To: Alexander Motin Date: Fri, 6 Apr 2012 11:01:15 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@FreeBSD.org, sbruno@FreeBSD.org, scottl@FreeBSD.org, John Baldwin Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Apr 2012 18:01:16 -0000 Alexander Motin writes: | On 04/06/12 20:12, Doug Ambrisko wrote: | > Alexander Motin writes: | > | On 04/04/12 21:47, John Baldwin wrote: | > |> On Wednesday, April 04, 2012 12:24:33 pm Doug Ambrisko wrote: | > |>> John Baldwin writes: | > |>> | On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: | > |>> |> John Baldwin writes: | > |>> |> | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: | > |>> |> |> Doug Ambrisko writes: | > |>> |> |> | John Baldwin writes: | > |>> |> |> | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: | > |>> |> |> | |> Sean Bruno writes: | > |>> |> |> | |> | Noting a failure to attach to the onboard IPMI controller | > |> with | > |>> | this | > |>> |> | dell | > |>> |> |> | |> | R815. Not sure what to start poking at and thought I'd | > |> though | > |>> | this | > |>> |> | over | > |>> |> |> | |> | here for comment. | > |>> |> |> | |> | | > |>> |> |> | |> | -bash-4.2$ dmesg |grep ipmi | > |>> |> |> | |> | ipmi0: KCS mode found at io 0xca8 on acpi | > |>> |> |> | |> | ipmi1: on isa0 | > |>> |> |> | |> | device_attach: ipmi1 attach returned 16 | > |>> |> |> | |> | ipmi1: on isa0 | > |>> |> |> | |> | device_attach: ipmi1 attach returned 16 | > |>> |> |> | |> | ipmi0: Timed out waiting for GET_DEVICE_ID | > |>> |> |> | |> | > |>> |> |> | |> I've run into this recently. A quick hack to fix it is: | > |>> |> |> | |> | > |>> |> |> | |> Index: ipmi.c | > |>> |> |> | |> | > [snip] | > |>> | If you use "-ct" then you get a file you can feed into schedgraph. | > |>> | However, just reading the log, it seems that IRQ 20 keeps preempting | > |>> | the KCS worker thread preventing it from getting anything done. Also, | > |>> | there seem to be a lot of threads on CPU 0's runqueue waiting for a | > |>> | chance to run (load average of 12 or 13 the entire time). You can try | > |>> | just bumping up the max timeout from 3 seconds to higher perhaps. Not | > |>> | sure why IRQ 20 keeps firing though. It might be related to USB, so | > |>> | you could try fiddling with USB options in the BIOS perhaps, or disabling | > |>> | the USB drivers to see if that fixes IPMI. | > |>> | > |>> Tried without USB in kernel: | > |>> http://people.freebsd.org/~ambrisko/ipmi_ktr_dump_no_usb.txt | > |> | > |> Hmm, it's still just running constantly (note that the idle thread is | > |> _never_ scheduled). The lion's share of the time seems to be spent in | > |> "xpt_thrd". Note that there are several places where nothing happens except | > |> that "xpt_thrd" runs constantly (spinning) during 10's of statclock ticks. I | > |> would maybe start debugging that to see what in the world it is doing. Maybe | > |> it is polling some hardware down in xpt_action() (i.e., xpt_action() for a | > |> single bus called down into a driver and it is just spinning using polling | > |> instead of sleeping and waiting for an interrupt). | > | | > | "xpt_thrd" is a bus scanner thread. It is scheduled by CAM for every bus | > | on attach and by controller driver on hot-plug events. For some | > | controllers it may be quite CPU-hungry. For example, for legacy ATA | > | controllers, where bus reset may take many seconds of hardware polling, | > | while devices just spinning up. For ahci(4) it was improved about year | > | ago to not use polling when possible, but it still may loop for some | > | time if controller is not responding on reset. What mfi(4), mentioned in | > | log, does during scanning, I am not sure. | > | > I thought that mfi(4) could be an issue. There are some ata controllers | > with nothing attached. I built a GENERIC with USB and mfi commented out | > and then the timeout issue went away: | > ipmi0: KCS mode found at io 0xca8 on acpi | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 1 | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 2211 | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 2272 | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 2332 | > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 | > | > Without mfi and with USB and it had issues: | > ipmi0: KCS mode found at io 0xca8 on acpi | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 | > ipmi0: Timed out waiting for GET_DEVICE_ID | > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 | > | > I can post more ktrdump traces if needed. A 1U Dell machine without | > mfi also has this problem. As John mentioned it might be good to | > bump up the timeout from 3s to 6s. I did that with the USB no mfi | > kernel and that passed: | > | > % dmesg | grep ipmi | > ipmi0: KCS mode found at io 0xca8 on acpi | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi1: on isa0 | > device_attach: ipmi1 attach returned 16 | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 | > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 | > | > So maybe we need to agressively bump up the timeout. I put a | > timeout since I didn't want the system to hang. Anyone have a | > good idea of a timeout. I thought I tried 6s initially and it | > had issues but then the machine I was playing with had 3 mfi | > cards and various disks hanging off it. | | I have no idea about IPMI timeout to propose, but can't that check be | remade opposite: if response received -- use it, otherwise -- check | error value? Obviously it is not IPMI problem that CPU is busy, but | ability to work in those conditions would be a bonus. In theory, that is what it is supposed to be doing. However, it seems like the entire system is busy such that when the IPMI task notifies the thread it is complete the thread even though might have got the wakeup fails due to sleeping for to long. If this is indeed the case I can work around this by setting a "completion" variable and then check that instead of erroring out on the timeout failure of msleep. It just seems strange to put in code that effectively, says if the CPU is to slow to do anything to complete in the required time but did complete successfully don't treat that as an error! Increasing the timeout shouldn't have any negative impact in boot times and is just a safety measure. I think we already know the HW should be okay at this time. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 7 01:25:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EB89106566B for ; Sat, 7 Apr 2012 01:25:55 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by mx1.freebsd.org (Postfix) with ESMTP id A87308FC0C for ; Sat, 7 Apr 2012 01:25:54 +0000 (UTC) Received: from nschwcmgw07p ([61.9.190.167]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20120407012547.PHTD2821.nschwmtas05p.mx.bigpond.com@nschwcmgw07p>; Sat, 7 Apr 2012 01:25:47 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.112.105]) by nschwcmgw07p with BigPond Outbound id upRm1i0022GVmci01pRms2; Sat, 07 Apr 2012 01:25:47 +0000 X-Authority-Analysis: v=2.0 cv=ZuNv2qHG c=1 sm=1 a=0GO/22z+lHYfckWJ4naYnw==:17 a=uQTO-rxiXm8A:10 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=K0jY3d95y0xq4u52dFIA:9 a=CjuIK1q_8ugA:10 a=0GO/22z+lHYfckWJ4naYnw==:117 Received: from white (white.hs [10.0.5.2]) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id q371Oi1k053906 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Apr 2012 11:24:44 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Marius Strobl'" References: <20120406171644.GA9162@alchemy.franken.de> Date: Sat, 7 Apr 2012 11:24:44 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20120406171644.GA9162@alchemy.franken.de> Thread-Index: Ac0UGV/x74H9CUbgQWCvNFv1cyf74gAQpreQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org Subject: RE: 8.3-PRERELEASE and ATA_CAM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 01:25:55 -0000 Marius, Perhaps this mutual exclusivity issue between ATA_CAM with atapicam and friends, should be mentioned in UPDATING as I'm sure the same question will recur. Thank-you for your guidance resolving the same issue that I had in 9.0 Stable. Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 7 05:02:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 251E81065672 for ; Sat, 7 Apr 2012 05:02:00 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A63658FC12 for ; Sat, 7 Apr 2012 05:01:59 +0000 (UTC) Received: by wern13 with SMTP id n13so2274855wer.13 for ; Fri, 06 Apr 2012 22:01:53 -0700 (PDT) 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=ZbmmMpvo+q6e5OIBcuR36OT7sis4ThofEiWUJUUzGYM=; b=gw6f8Q8nC1D8dpxiYBdc449BeKL6p6DsEdTef8krUUpUeEn0AzTTXK5z5f42kKPA3n VoGzKgeTaB2HB3VZOkk4GSh6568yt4DkdINTKoD6hEJN8ChKvCia7oKy99YlYyv02Fd4 nY+wlma1ZHZncq6ABmfPKbO+ycVOazhETWUyOABrxL/E4X5HTMeF5m0/pzerWx2+AZXQ LRVlb33OLHYRnczwWX3BSJQCXdESvAhxhP1keFGMf9g2VHKr1aH/UVKFE/WVn2UE7WWx kzuoueeWVUJk7+qJIER6ZfCHkj5byZFMLAMkhmYx5iE2Pc59Z7SMEGn3eMNPBzP21qeA JS2w== MIME-Version: 1.0 Received: by 10.216.132.229 with SMTP id o79mr203486wei.64.1333774913139; Fri, 06 Apr 2012 22:01:53 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 6 Apr 2012 22:01:53 -0700 (PDT) In-Reply-To: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> Date: Sat, 7 Apr 2012 14:31:53 +0930 Message-ID: From: Matt Thyer To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 05:02:00 -0000 On 5 April 2012 01:18, Freddie Cash wrote: > On Wed, Apr 4, 2012 at 5:19 AM, Matt Thyer wrote: > > So it seems that both the old and new mps driver have a problem with the > > Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS > > 6G) controller (flashed with -IT firmware). > > I wouldn't say the driver has a problem with that specific drive. > More that it might have a problem with a mixed SATA2/SATA3 setup. > > Sorry, that's what I meant to say but it now seems that the 157K interrupts per second is probably not due to the SuperMicro AOC-USAS2-L8i. Since moving the SATA 3 disk to the onboard Intel SATA 2 controller I'm no longer having that disk evicted from the raidz2 pool with write errors and I thought that the high interrupt rate issue had also been solved but it's back again. This is on 8-STABLE at revision 230921 (before the new driver hit 8-STABLE). So now I need to go back to trying to determine what the cause is. I'll stop posting in this thread as I don't think it's anything to do with either the old or new version of this driver. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 7 05:08:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26C7A106566B for ; Sat, 7 Apr 2012 05:08:45 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A76278FC0C for ; Sat, 7 Apr 2012 05:08:44 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2654462wgb.31 for ; Fri, 06 Apr 2012 22:08:43 -0700 (PDT) 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=w55uABsLGooFu130tLQA3YldRCiBUqBZghWNFuEpBQM=; b=dj3jKAvBDu7OeSM9bWtKSnaLdU5YPQ0XFcgHwOQoEpCqQ9jvevS3OR0ELBtc+c3KHq F/QT+saKAEGfYJZ2Kv9PrmlAiTDwsc1xqTsWxTgc67+9IasVdeYZZrBX/VGMW7+tz04p iiKmHG6vwlG5jZwrR6nvdFUfdOjFcZ+OohBhTe+zad+FmogFjB16zYounfWpo/+F7akg gOwdhFm13yuHK2qge1NZoe5k0kG+xoWH1HFH44FwpgQbjjWl33/6i8Lx4LB74ZmYpLnv wQse+kvI4CazvSwyTtBdHbJEHUFnfKlrhJi81lCt9PsipqAVMyhKrlAY63NENK8PyGoO OUZg== MIME-Version: 1.0 Received: by 10.216.132.229 with SMTP id o79mr210949wei.64.1333775323639; Fri, 06 Apr 2012 22:08:43 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 6 Apr 2012 22:08:43 -0700 (PDT) In-Reply-To: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> Date: Sat, 7 Apr 2012 14:38:43 +0930 Message-ID: From: Matt Thyer To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 05:08:46 -0000 On 7 April 2012 14:31, Matt Thyer wrote: > On 5 April 2012 01:18, Freddie Cash wrote: > >> On Wed, Apr 4, 2012 at 5:19 AM, Matt Thyer wrote: >> > So it seems that both the old and new mps driver have a problem with the >> > Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS >> > 6G) controller (flashed with -IT firmware). >> >> I wouldn't say the driver has a problem with that specific drive. >> More that it might have a problem with a mixed SATA2/SATA3 setup. >> >> Sorry, that's what I meant to say but it now seems that the 157K > interrupts per second is probably not due to the SuperMicro AOC-USAS2-L8i. > > Since moving the SATA 3 disk to the onboard Intel SATA 2 controller I'm no > longer having that disk evicted from the raidz2 pool with write errors and > I thought that the high interrupt rate issue had also been solved but it's > back again. > > This is on 8-STABLE at revision 230921 (before the new driver hit > 8-STABLE). > > So now I need to go back to trying to determine what the cause is. > > I'll stop posting in this thread as I don't think it's anything to do with > either the old or new version of this driver. > Oops... wrong thread I thought I was replying in -CURRENT. So on to the root cause. vmstat -i has shown that the issue was on irq 16. Unfortunately there seems to be a lot of things on irq 16: $ dmesg | grep "irq 16" pcib1: irq 16 at device 1.0 on pci0 mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdfffff,0xfbd80000-0xfbdbffff irq 16 at device 0.0 on pci1 vgapci0: port 0xff00-0xff07 mem 0xfb400000-0xfb7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pcib3: irq 16 at device 28.4 on pci0 atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 pcib1: irq 16 at device 1.0 on pci0 mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdfffff,0xfbd80000-0xfbdbffff irq 16 at device 0.0 on pci1 vgapci0: port 0xff00-0xff07 mem 0xfb400000-0xfb7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pcib3: irq 16 at device 28.4 on pci0 atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 Any idea how to isolate which bit of hardware could be triggering the interrupts ? Unfortunately the only device I could remove would be the SuperMicro AOC-USAS2-L8i (so yes I could eliminate that). My biggest problem right now is not knowing how to trigger the issue. At this stage I'm going to upgrade to 9-STABLE and see if it returns. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 7 07:53:41 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 83212106566B for ; Sat, 7 Apr 2012 07:53:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 380FA8FC1A for ; Sat, 7 Apr 2012 07:53:41 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SGQSp-0003Lv-DK; Sat, 07 Apr 2012 10:53:39 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Marius Strobl In-reply-to: <20120406171644.GA9162@alchemy.franken.de> References: <20120406171644.GA9162@alchemy.franken.de> Comments: In-reply-to Marius Strobl message dated "Fri, 06 Apr 2012 19:16:44 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Apr 2012 10:53:39 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: 8.3-PRERELEASE and ATA_CAM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 07:53:41 -0000 > On Fri, Apr 06, 2012 at 10:48:13AM +0300, Daniel Braniss wrote: > > with the latest svn, I can't compile kernel with options ATA_CAM: > > > > ... > > linking kernel.debug > > ata-disk.o(.text+0x93): In function `ad_init': > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to > > `ata_setmode' > > ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: undefined > > reference to `ata_wc' > > ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: undefined > > reference to `ata_controlcmd' > > ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: undefined > > reference to `ata_controlcmd' > > ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: undefined > > reference to `ata_controlcmd' > > ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: undefined > > reference to `ata_controlcmd' > > ata-disk.o(.text+0x21a): In function `ad_shutdown': > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to > > `ata_controlcmd' > > ata-disk.o(.text+0x45c): In function `ad_detach': > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to > > `ata_fail_requests' > > ... > > > > You seem to be using a mutually exclusive set of ata(4) options and > devices (previously, this erroneously wasn't a bug). When including > options ATA_CAM you do _not_ want to also include any of the following > devices: > device atapicam > device atadisk > device ataraid > device atapicd > device atapifd > device atapist > > Instead you need the corresponding driver from the following set: > device scbus > device ch > device da > device sa > device cd > device pass > > Marius > they are included by GENERIC, which i include, bummer. what about ATA_STATIC_ID, I guess that is also a nono? thanks, danny From owner-freebsd-stable@FreeBSD.ORG Sat Apr 7 11:52: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 41D26106566B for ; Sat, 7 Apr 2012 11:52:37 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id CE3548FC0C for ; Sat, 7 Apr 2012 11:52:36 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q37Bq6S9012750; Sat, 7 Apr 2012 13:52:06 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q37Bq5PA012749; Sat, 7 Apr 2012 13:52:05 +0200 (CEST) (envelope-from marius) Date: Sat, 7 Apr 2012 13:52:05 +0200 From: Marius Strobl To: Daniel Braniss Message-ID: <20120407115205.GW93449@alchemy.franken.de> References: <20120406171644.GA9162@alchemy.franken.de> 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-stable@freebsd.org Subject: Re: 8.3-PRERELEASE and ATA_CAM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 11:52:37 -0000 On Sat, Apr 07, 2012 at 10:53:39AM +0300, Daniel Braniss wrote: > > On Fri, Apr 06, 2012 at 10:48:13AM +0300, Daniel Braniss wrote: > > > with the latest svn, I can't compile kernel with options ATA_CAM: > > > > > > ... > > > linking kernel.debug > > > ata-disk.o(.text+0x93): In function `ad_init': > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to > > > `ata_setmode' > > > ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: undefined > > > reference to `ata_wc' > > > ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x21a): In function `ad_shutdown': > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to > > > `ata_controlcmd' > > > ata-disk.o(.text+0x45c): In function `ad_detach': > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to > > > `ata_fail_requests' > > > ... > > > > > > > You seem to be using a mutually exclusive set of ata(4) options and > > devices (previously, this erroneously wasn't a bug). When including > > options ATA_CAM you do _not_ want to also include any of the following > > devices: > > device atapicam > > device atadisk > > device ataraid > > device atapicd > > device atapifd > > device atapist > > > > Instead you need the corresponding driver from the following set: > > device scbus > > device ch > > device da > > device sa > > device cd > > device pass > > > > Marius > > > they are included by GENERIC, which i include, bummer. It should work to include GENERIC but disable the "old" devices via "nodevice atadisk" etc. in your custom kernel configuration file. > what about ATA_STATIC_ID, I guess that is also a nono? No, ATA_STATIC_ID is still available with ATA_CAM, in this case it's purpose is a bit different though; when present, it provides /dev/adX symbolic links to the /dev/adaY device nodes, trying to mimic the non-ATA_CAM numbering for /dev/adX. If you've already updated your /etc/fstab etc. to use /dev/adaY instead, you don't need ATA_STATIC_ID though. Marius From owner-freebsd-stable@FreeBSD.ORG Sat Apr 7 12:30: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 679341065675 for ; Sat, 7 Apr 2012 12:30:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id E63948FC1C for ; Sat, 7 Apr 2012 12:30:22 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q37CTrwB012879; Sat, 7 Apr 2012 14:29:53 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q37CTrNn012878; Sat, 7 Apr 2012 14:29:53 +0200 (CEST) (envelope-from marius) Date: Sat, 7 Apr 2012 14:29:53 +0200 From: Marius Strobl To: Daniel Braniss Message-ID: <20120407122953.GA12840@alchemy.franken.de> References: <20120406171644.GA9162@alchemy.franken.de> <20120407115205.GW93449@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120407115205.GW93449@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8.3-PRERELEASE and ATA_CAM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 12:30:23 -0000 On Sat, Apr 07, 2012 at 01:52:05PM +0200, Marius Strobl wrote: > On Sat, Apr 07, 2012 at 10:53:39AM +0300, Daniel Braniss wrote: > > > On Fri, Apr 06, 2012 at 10:48:13AM +0300, Daniel Braniss wrote: > > > > with the latest svn, I can't compile kernel with options ATA_CAM: > > > > > > > > ... > > > > linking kernel.debug > > > > ata-disk.o(.text+0x93): In function `ad_init': > > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to > > > > `ata_setmode' > > > > ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: undefined > > > > reference to `ata_wc' > > > > ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x21a): In function `ad_shutdown': > > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to > > > > `ata_controlcmd' > > > > ata-disk.o(.text+0x45c): In function `ad_detach': > > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to > > > > `ata_fail_requests' > > > > ... > > > > > > > > > > You seem to be using a mutually exclusive set of ata(4) options and > > > devices (previously, this erroneously wasn't a bug). When including > > > options ATA_CAM you do _not_ want to also include any of the following > > > devices: > > > device atapicam > > > device atadisk > > > device ataraid > > > device atapicd > > > device atapifd > > > device atapist > > > > > > Instead you need the corresponding driver from the following set: > > > device scbus > > > device ch > > > device da > > > device sa > > > device cd > > > device pass > > > > > > Marius > > > > > they are included by GENERIC, which i include, bummer. > > It should work to include GENERIC but disable the "old" devices via > "nodevice atadisk" etc. in your custom kernel configuration file. > > > what about ATA_STATIC_ID, I guess that is also a nono? > > No, ATA_STATIC_ID is still available with ATA_CAM, in this case it's > purpose is a bit different though; when present, it provides /dev/adX > symbolic links to the /dev/adaY device nodes, trying to mimic the > non-ATA_CAM numbering for /dev/adX. If you've already updated your > /etc/fstab etc. to use /dev/adaY instead, you don't need ATA_STATIC_ID > though. > Sorry, I've just checked the source and the code for ATA_STATIC_ID with ATA_CAM actually is only present in FreeBSD 9 and 10. With FreeBSD 8 ATA_STATIC_ID in combination with ATA_CAM just does nothing, but also doesn't pose any problem either. Marius