From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 07:23:24 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9835E106566C for ; Sun, 31 Jul 2011 07:23:24 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 305E38FC12 for ; Sun, 31 Jul 2011 07:23:23 +0000 (UTC) Received: by wyg24 with SMTP id 24so1277708wyg.13 for ; Sun, 31 Jul 2011 00:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=x9IRUBIoGo7LoUdzSv/uru8Ff9rS0F/XXGqelKUdygA=; b=DPVSyId3MrrwRCJ5Y4qXEWN43ZfJA1B57UONFpiVje0Iua6v4xuqYkNDPLC/s/3V0T i1Jq67spEJvcnJ9gQtoJUI5bsjwAmXFTe2CzGKNBjYTYkGtW/KZswaXEP5Qx5NuP09M9 hUci3FcwADj37oGcRTBgbq9xn4TCGUGhTe6W0= MIME-Version: 1.0 Received: by 10.227.13.77 with SMTP id b13mr4167491wba.54.1312097002744; Sun, 31 Jul 2011 00:23:22 -0700 (PDT) Received: by 10.216.164.71 with HTTP; Sun, 31 Jul 2011 00:23:22 -0700 (PDT) Date: Sun, 31 Jul 2011 17:23:22 +1000 Message-ID: From: Stephen Hocking To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Best GB Nic for 8.2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 07:23:24 -0000 Hi all, Am currently using an onboard GB nic, on my main fileserver (8.2 64bit, AMD, 8GB mem) which is seen as nfe0 (Nvidia, basically). Is there a better one available? I have a one lane PCIe slot and any number of PCI slots available. Stephen From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 09:03:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6801106564A for ; Sun, 31 Jul 2011 09:03:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 81B3F8FC08 for ; Sun, 31 Jul 2011 09:03:53 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0017A46B0C; Sun, 31 Jul 2011 05:03:52 -0400 (EDT) Date: Sun, 31 Jul 2011 10:03:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: James Jones In-Reply-To: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> Message-ID: References: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-hackers@freebsd.org" Subject: Re: MIPS toolchain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 09:03:53 -0000 On Fri, 29 Jul 2011, James Jones wrote: > Does anyone have a prebuilt MIPS tool chain? For FreeBSD-related MIPS work, I generally use the FreeBSD "toolchain" target followed by the "buildenv" environment, but that requires first building a cross-toolchain using TARGET_ARCH and TARGET. However, the result is a pretty sane compiler, linker, etc, setup for the MIPS of your choice (we tend to use mips64eb). We also use the MIPS-provided SDE toolchain for Linux at the CL, but that appears to be out of maintenance, and I haven't found its bug density to be any lower, really, than the even more ageing FreeBSD versions of the tools. In fact, there are some toolchain bugs I'm running into that manifest only in the SDE toolchain and not the FreeBSD toolchain. (Mind you, Philip has commented that in building Uboot for MIPS, he's found FreeBSD bugs that don't appear in the SDE toolchain, so mileage varies). We're greatly looking forward to MIPS support for LLVM, which currently appears very premature indeed. Someone from MIPS appears to be contributing to it, however, and we (cl.cam.ac.uk) hope to provide some implementation support for that effort in the immediate future. Robert From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 11:46:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7296C1065672; Sun, 31 Jul 2011 11:46:04 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D21458FC0C; Sun, 31 Jul 2011 11:46:03 +0000 (UTC) Received: by wwe6 with SMTP id 6so4679448wwe.31 for ; Sun, 31 Jul 2011 04:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=unO+XKNcGdxQTNWdA/7cjZuAcWEYwHbI8q8+eYVpht0=; b=t1+3kpjPS+7tAQNEt2tItrnjgjyKaWf3XEtURLYw1m40tvrwarhRhpaGmiHBDfsU1g KLGd0H8ukN/4f6ulr/oJcuX2lzh8LeOd7t2LeQc1LeVuhgC2esfPymI902flYKSHqLWV cNxE3GrU3kIjwOXbHOcPMKM0Gn87vrOMoj2dQ= MIME-Version: 1.0 Received: by 10.227.195.197 with SMTP id ed5mr4794709wbb.104.1312111342518; Sun, 31 Jul 2011 04:22:22 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.186.11 with HTTP; Sun, 31 Jul 2011 04:22:22 -0700 (PDT) In-Reply-To: References: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> Date: Sun, 31 Jul 2011 16:52:22 +0530 X-Google-Sender-Auth: tnX2P4xC5fYsj1BhXrtsxJeBebs Message-ID: From: "Jayachandran C." To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , James Jones Subject: Re: MIPS toolchain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 11:46:04 -0000 On Sun, Jul 31, 2011 at 2:33 PM, Robert Watson wrote: > > On Fri, 29 Jul 2011, James Jones wrote: > >> Does anyone have a prebuilt MIPS tool chain? > > For FreeBSD-related MIPS work, I generally use the FreeBSD "toolchain" > target followed by the "buildenv" environment, but that requires first > building a cross-toolchain using TARGET_ARCH and TARGET. =A0However, the > result is a pretty sane compiler, linker, etc, setup for the MIPS of your > choice (we tend to use mips64eb). > > We also use the MIPS-provided SDE toolchain for Linux at the CL, but that > appears to be out of maintenance, and I haven't found its bug density to = be > any lower, really, than the even more ageing FreeBSD versions of the tool= s. Yes, the FreeBSD MIPS tool-chain is pretty good in both the cross compile and native compile setup. For Linux, the CodeSourcery G++ Lite version of GCC is pretty good and easy to setup, if you want a relatively newer version. > In fact, there are some toolchain bugs I'm running into that manifest onl= y > in the SDE toolchain and not the FreeBSD toolchain. =A0(Mind you, Philip = has > commented that in building Uboot for MIPS, he's found FreeBSD bugs that > don't appear in the SDE toolchain, so mileage varies). Any idea what the bugs where? If there are fixes that can be backported without license issues, we take take a look at this. > We're greatly looking forward to MIPS support for LLVM, which currently > appears very premature indeed. =A0Someone from MIPS appears to be contrib= uting > to it, however, and we (cl.cam.ac.uk) hope to provide some implementation > support for that effort in the immediate future. JC. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 13:05:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B6DA106564A for ; Sun, 31 Jul 2011 13:05:07 +0000 (UTC) (envelope-from james@freedomnet.co.nz) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 491128FC15 for ; Sun, 31 Jul 2011 13:05:06 +0000 (UTC) Received: by vxg33 with SMTP id 33so5057092vxg.13 for ; Sun, 31 Jul 2011 06:05:06 -0700 (PDT) Received: by 10.52.173.45 with SMTP id bh13mr54442vdc.3.1312117506422; Sun, 31 Jul 2011 06:05:06 -0700 (PDT) Received: from [192.168.1.4] (pool-108-7-70-195.bstnma.fios.verizon.net [108.7.70.195]) by mx.google.com with ESMTPS id ca9sm826672vdc.27.2011.07.31.06.05.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 06:05:05 -0700 (PDT) References: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <01E9E7A6-8043-4E8E-9F06-1818F67CB0C1@freedomnet.co.nz> X-Mailer: iPhone Mail (9A5220p) From: James Jones Date: Sun, 31 Jul 2011 09:05:00 -0400 To: Robert Watson Cc: "freebsd-hackers@freebsd.org" Subject: Re: MIPS toolchain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 13:05:07 -0000 Could you provide steps for building cross tool chain. I have not done it so= long. I have tried many different versions of howtos but all have fallen sh= ort or I am not understanding. I need a toolchain for target 'mips-unknown-e= lf'.=20 Sent from my iPhone On Jul 31, 2011, at 5:03 AM, Robert Watson wrote: >=20 > On Fri, 29 Jul 2011, James Jones wrote: >=20 >> Does anyone have a prebuilt MIPS tool chain? >=20 > For FreeBSD-related MIPS work, I generally use the FreeBSD "toolchain" tar= get followed by the "buildenv" environment, but that requires first building= a cross-toolchain using TARGET_ARCH and TARGET. However, the result is a p= retty sane compiler, linker, etc, setup for the MIPS of your choice (we tend= to use mips64eb). >=20 > We also use the MIPS-provided SDE toolchain for Linux at the CL, but that a= ppears to be out of maintenance, and I haven't found its bug density to be a= ny lower, really, than the even more ageing FreeBSD versions of the tools. I= n fact, there are some toolchain bugs I'm running into that manifest only in= the SDE toolchain and not the FreeBSD toolchain. (Mind you, Philip has com= mented that in building Uboot for MIPS, he's found FreeBSD bugs that don't a= ppear in the SDE toolchain, so mileage varies). >=20 > We're greatly looking forward to MIPS support for LLVM, which currently ap= pears very premature indeed. Someone from MIPS appears to be contributing t= o it, however, and we (cl.cam.ac.uk) hope to provide some implementation sup= port for that effort in the immediate future. >=20 > Robert From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 14:37:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9252106564A for ; Sun, 31 Jul 2011 14:37:38 +0000 (UTC) (envelope-from kuku@kukulies.org) Received: from kukulies.org (mail.kukulies.org [78.47.239.221]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4BA8FC08 for ; Sun, 31 Jul 2011 14:37:37 +0000 (UTC) Received: by kukulies.org (Postfix, from userid 5001) id 417011AC003; Sun, 31 Jul 2011 16:20:25 +0200 (CEST) Received: from [192.168.2.102] (pC19EB8FB.dip.t-dialin.net [193.158.184.251]) by kukulies.org (Postfix) with ESMTPSA id 0F94B1AC002 for ; Sun, 31 Jul 2011 16:20:22 +0200 (CEST) Message-ID: <4E356498.40001@kukulies.org> Date: Sun, 31 Jul 2011 16:20:08 +0200 From: "Christoph P.U. Kukulies" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: invalid argument in select() when peer socket is in FD_SET X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 14:37:38 -0000 I posted this on freebsd-questions also but maybe the expert density isn't that high as here in "hackers". Since I think it may be a design or implementation issue in FreeBSDs' select(), I'm posting it here as well, hoping to get an experts' answer. I have written a small server to test TCP/IP roundtrip times of the packets in a proprietary protocol and while compiling and running this server on different platforms (Windows 7/cygwin, UbuntuLinux, FreeBSD 8.0 Release), I found that the server produces an error when the listening socket (on which the accept() is performed) is also member of the select() fd_set. On the other platforms the program works without error, just under FreeBSD I'm getting this "invalid argument" error. Comments appreciated (despite comments about the error checking logic Here is the code: /* testsrv.c */ /* gcc -o testsrv testsrv.c */ /* */ #include #include #include #include #include #include #include #include #include #define USEDBUFSIZ 60 #define MAX_HOSTNAME 256 #define MAXFDS 256 #define CLRBUF memset(buf,0,sizeof(buf)) #define max(a,b) (((a) > (b)) ? (a) : (b)) static unsigned char buf[256]; int array_of_fds[MAXFDS]; static fd_set clientfds; #define SOCKET int void *memset(void *, int, size_t); int enter (int); int remov (int); int invalidip (char *); void exit (int); int getv (int, unsigned char *, int); int getfds (); int main(int argc, char **argv) { int nfds; static fd_set readfds; SOCKET ListenSocket, newsockfd; struct sockaddr_in cli_addr; struct sockaddr_in service; struct hostent *thisHost; int bOptVal = 0; int bOptLen = sizeof(int); char hostname[256]; char *host_addr; struct in_addr addr = {0}; char *ip; u_short port; int iResult = 0; int i , n, m, clilen, dummy, connect = 0; struct timeval tv; /*---------------------------------------*/ /* Create a listening socket */ ListenSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (ListenSocket == -1) { perror("socket creation"); return 1; } else printf("ListenSocket=%d\n", ListenSocket); /*-----------------------------------------*/ /* Bind the socket to the local IP address */ /* and port 3210 */ port = 3210; if (gethostname(hostname, 256)) perror("gethostname failed\n"), exit(3); printf("%s\n", hostname), fflush(stdout); thisHost = gethostbyname(hostname); ip = inet_ntoa(*(struct in_addr *)(*thisHost->h_addr_list)); if (argc == 2) { host_addr = argv[1]; service.sin_addr.s_addr = inet_addr(host_addr); thisHost = gethostbyaddr((const char *)&service.sin_addr.s_addr, sizeof(service.sin_addr.s_addr), AF_INET); if (thisHost == 0) printf("host unknown\n"), exit(3); if (invalidip(host_addr)) printf("invalid IP\n"), exit(4); } else { service.sin_addr.s_addr = inet_addr(ip); } service.sin_port = htons(port); service.sin_family = AF_INET; iResult = bind(ListenSocket, (struct sockaddr *)&service, sizeof(service)); if (iResult == -1) { perror("bind"); shutdown(ListenSocket, SHUT_RDWR); return 1; } listen(ListenSocket, SOMAXCONN); printf("SOMAXCONN=%d %d\n", SOMAXCONN, FD_SETSIZE); /* all sockets are put into an own array_of_fs */ /* in the while() loop below the FD_SET id used by looping through the */ /* array_of_fds to fill the readfds array in the select() */ enter(ListenSocket); /* * Wait for connect */ tv.tv_sec = 0; tv.tv_usec = 5000000; /* 5 seconds */ printf("Server %s listening on port %d\n", thisHost->h_name, port); memset((void *)array_of_fds, 0, (size_t) MAXFDS * sizeof(*array_of_fds)); nfds = ListenSocket + 1; while (1) { FD_ZERO(&readfds); FD_SET(ListenSocket, &readfds); for (i = 0; i < MAXFDS; i++) { if (array_of_fds[i]) { nfds = max(nfds, array_of_fds[i]) + 1; FD_SET(array_of_fds[i], &readfds); } } n = select(nfds, &readfds, (fd_set *) NULL, /* not interested in write */ (fd_set *) NULL, /* ...or exceptions */ &tv); /* timeout */ switch (n) { case 1: clilen = sizeof(cli_addr); /* first test if a new client has connected */ if (FD_ISSET(ListenSocket, &readfds)) { newsockfd = accept(ListenSocket, (struct sockaddr *)&cli_addr, &clilen); if (enter(newsockfd)) /* socket of new connection is entered*/ printf("\n%d.connect! ", ++connect), fflush(stdout); else printf("too many connections"), exit(1); sprintf(buf, "ENTERED %d of %d", 1, 10); send(newsockfd, buf, USEDBUFSIZ, 0); /* send to the client*/ } else { for (i = 0; i < MAXFDS; i++) { int s; if (FD_ISSET((s = array_of_fds[i]), &readfds)) { m = getv(s, buf, USEDBUFSIZ); if (m <= 0) { shutdown(s, SHUT_RDWR); if (remov(s) == -1) printf("error on remove(s)\n", s), fflush(stdout ); goto done; } else { printf("*"); fflush(stdout); CLRBUF; /* now send some data to the client */ sprintf(buf, "XX-123456789-XX-xx : 0x0600, 0x99999999, \"NNNNN\""); m = send(s, buf, USEDBUFSIZ, 0); if (m < 0 || m != USEDBUFSIZ) { perror("cannot send\n"); } CLRBUF; sprintf(buf, "END"); m = send(s, buf, USEDBUFSIZ, 0); if (m < 0 || m != USEDBUFSIZ) { perror("cannot send\n"); } } /* else */ } /* if FD_ISSET */ } /* for */ break; case 0: break; case -1: perror("select"); exit(2); default: printf("more than one descriptor ready!\n"); fflush(stdout); exit(4); break; } /* switch */ } /* while */ } done: shutdown(ListenSocket, SHUT_RDWR); return 0; } /* main */ int getv(int fd, unsigned char *buf, int count) { int m , got = 0; int i = 0; while (got < count) { m = recv(fd, buf + got, count - got, 0); if (m == count) return m; if (m > 0) got = got + m; if (m == 0) return (0); if (m < 0) { return -1; } } return -1; } int enter(int i) { int k = 0; while (array_of_fds[k++]); if (k > MAXFDS - 1) return -1; k--; array_of_fds[k] = i; return i; } int remov(s) { int k; for (k = 0; k < MAXFDS; k++) if (array_of_fds[k] == s) { array_of_fds[k] = 0; return k; } return -1; } /* * this code taken from code for validating IPv4 address taken from article * in http://bytes.com/topic/c/answers/212174-code-validating-ipv4-address */ #define INVALID -1 #define VALID 0 int invalidip(char *ipadd) { unsigned b1, b2, b3, b4; unsigned char c; if (sscanf(ipadd, "%3u.%3u.%3u.%3u%c", &b1, &b2, &b3, &b4, &c) != 4) return INVALID; if ((b1 | b2 | b3 | b4) > 255) return INVALID; if (strspn(ipadd, "0123456789.") < strlen(ipadd)) return INVALID; return VALID; } _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 15:45:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68C5F106566B for ; Sun, 31 Jul 2011 15:45:13 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 097B38FC1B for ; Sun, 31 Jul 2011 15:45:13 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id D778A1DD6DF; Sun, 31 Jul 2011 17:45:11 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id CC89B1742A; Sun, 31 Jul 2011 17:45:11 +0200 (CEST) Date: Sun, 31 Jul 2011 17:45:11 +0200 From: Jilles Tjoelker To: "Christoph P.U. Kukulies" Message-ID: <20110731154511.GB66652@stack.nl> References: <4E356498.40001@kukulies.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E356498.40001@kukulies.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: invalid argument in select() when peer socket is in FD_SET X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 15:45:13 -0000 On Sun, Jul 31, 2011 at 04:20:08PM +0200, Christoph P.U. Kukulies wrote: > I posted this on freebsd-questions also but maybe the expert density > isn't that high as here in "hackers". > Since I think it may be a design or implementation issue in FreeBSDs' > select(), I'm posting it here as well, > hoping to get an experts' answer. > I have written a small server to test TCP/IP roundtrip times of the > packets in a proprietary protocol and while > compiling and running this server on different platforms (Windows > 7/cygwin, UbuntuLinux, FreeBSD 8.0 Release), I found > that the server produces an error when the listening socket (on which > the accept() is performed) is also > member of the select() fd_set. > On the other platforms the program works without error, just under > FreeBSD I'm getting this "invalid argument" error. > Comments appreciated (despite comments about the error checking logic > [snip] > tv.tv_sec = 0; > tv.tv_usec = 5000000; /* 5 seconds */ > [snip] > n = select(nfds, &readfds, > (fd_set *) NULL, /* not interested in write */ > (fd_set *) NULL, /* ...or exceptions */ > &tv); /* timeout */ The number of microseconds in a struct timeval must be nonnegative and less than one million (likewise, the number of nanoseconds in a struct timespec must be nonnegative and less than 1000 million). FreeBSD checks this strictly in most functions. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 16:19:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32AE3106566B for ; Sun, 31 Jul 2011 16:19:45 +0000 (UTC) (envelope-from kuku@kukulies.org) Received: from kukulies.org (mail.kukulies.org [78.47.239.221]) by mx1.freebsd.org (Postfix) with ESMTP id EA4BA8FC12 for ; Sun, 31 Jul 2011 16:19:44 +0000 (UTC) Received: by kukulies.org (Postfix, from userid 5001) id 3B5FB1AC003; Sun, 31 Jul 2011 18:19:44 +0200 (CEST) Received: from [192.168.2.102] (p4FD5EB53.dip.t-dialin.net [79.213.235.83]) by kukulies.org (Postfix) with ESMTPSA id 0F7271AC002; Sun, 31 Jul 2011 18:19:41 +0200 (CEST) Message-ID: <4E358095.9040606@kukulies.org> Date: Sun, 31 Jul 2011 18:19:33 +0200 From: "Christoph P.U. Kukulies" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <4E356498.40001@kukulies.org> <20110731154511.GB66652@stack.nl> In-Reply-To: <20110731154511.GB66652@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: invalid argument in select() when peer socket is in FD_SET X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 16:19:45 -0000 Am 31.07.2011 17:45, schrieb Jilles Tjoelker: > On Sun, Jul 31, 2011 at 04:20:08PM +0200, Christoph P.U. Kukulies wrote: >> I posted this on freebsd-questions also but maybe the expert density >> isn't that high as here in "hackers". >> Since I think it may be a design or implementation issue in FreeBSDs' >> select(), I'm posting it here as well, >> hoping to get an experts' answer. >> I have written a small server to test TCP/IP roundtrip times of the >> packets in a proprietary protocol and while >> compiling and running this server on different platforms (Windows >> 7/cygwin, UbuntuLinux, FreeBSD 8.0 Release), I found >> that the server produces an error when the listening socket (on which >> the accept() is performed) is also >> member of the select() fd_set. >> On the other platforms the program works without error, just under >> FreeBSD I'm getting this "invalid argument" error. >> Comments appreciated (despite comments about the error checking logic >> [snip] >> tv.tv_sec = 0; >> tv.tv_usec = 5000000; /* 5 seconds */ >> [snip] >> n = select(nfds,&readfds, >> (fd_set *) NULL, /* not interested in write */ >> (fd_set *) NULL, /* ...or exceptions */ >> &tv); /* timeout */ > The number of microseconds in a struct timeval must be nonnegative and > less than one million (likewise, the number of nanoseconds in a struct > timespec must be nonnegative and less than 1000 million). > > FreeBSD checks this strictly in most functions. Ah, thanks. That's another plus for FreeBSD. Somehow I have been mislead during the development of the sample server that it escaped to me, that the timestruct was the culprit. Thanks again. saved me a lot of headaches. -- Christoph From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 16:56:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71665106566B; Sun, 31 Jul 2011 16:56:52 +0000 (UTC) (envelope-from rmh.aybabtu@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 234098FC13; Sun, 31 Jul 2011 16:56:51 +0000 (UTC) Received: by iyb11 with SMTP id 11so7905178iyb.13 for ; Sun, 31 Jul 2011 09:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NWO80SjmZZSPIMROas6yBi33M2SMIO+WpA8pVnjUfnU=; b=S8Uw0ZcxMpdDKqS7om3O2sXVJ1850yCCwh3lmdG1rgyZc5cypZ2fB21c4qHQjxG+nS 24qfieyAofaQWywtRr+znErCoZ3voaqEVYuaQirjmBS/RUucpYc6Twvy0YhqjaFBaL+A 7D7GXtbuAvUr0tF7qMQbvsXxQnnlft2oudevs= MIME-Version: 1.0 Received: by 10.43.134.8 with SMTP id ia8mr2619458icc.113.1312131411463; Sun, 31 Jul 2011 09:56:51 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.129 with HTTP; Sun, 31 Jul 2011 09:56:51 -0700 (PDT) In-Reply-To: <20110730173239.GA17489@deviant.kiev.zoral.com.ua> References: <20110730173239.GA17489@deviant.kiev.zoral.com.ua> Date: Sun, 31 Jul 2011 18:56:51 +0200 X-Google-Sender-Auth: 5oFJhEx2NZuct0Wc6nq60MU-O_o Message-ID: From: Robert Millan To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Ed Maste Subject: Re: kern/159281: [PATCH] Linux-like /proc/swaps for linprocfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 16:56:52 -0000 2011/7/30 Kostik Belousov : > Second, my proposal contains a flaw. Namely, if some swap device was removed > between calls to swap_info and swap_devname calls, we get mangled list. Ok, I see that you fixed this by unifying those functions. > The third problem, which is not fixed, and which I do not want to handle, > is that the swap devices list can be changed between calls to swap_devname(), > changing device indexes and thus making the output mangled. You say you don't want to handle this, but AFAICT from the patch you already did. Or did I miss something? > Should the swap device name be separated from 'unknown' word by > space or by tab ? Linux' /proc/swaps prints spaces after the first column and tabs for the rest. I think it's better to do the same just in case, but I don't think it's relevant either way. > I updated your patch, hopefully fixing the issues. Do you have comments > or objections ? No. Thanks for fixing those problems. -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 19:30:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC75E1065670; Sun, 31 Jul 2011 19:30:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EE2C58FC12; Sun, 31 Jul 2011 19:30:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6VJUHZU064743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Jul 2011 22:30:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6VJUH04022401; Sun, 31 Jul 2011 22:30:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6VJUH1R022400; Sun, 31 Jul 2011 22:30:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Jul 2011 22:30:17 +0300 From: Kostik Belousov To: Robert Millan Message-ID: <20110731193017.GR17489@deviant.kiev.zoral.com.ua> References: <20110730173239.GA17489@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bQyVjumYeq8yaMqA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Ed Maste , bde@freebsd.org Subject: Re: kern/159281: [PATCH] Linux-like /proc/swaps for linprocfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 19:30:26 -0000 --bQyVjumYeq8yaMqA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 31, 2011 at 06:56:51PM +0200, Robert Millan wrote: > 2011/7/30 Kostik Belousov : > > Second, my proposal contains a flaw. Namely, if some swap device was re= moved > > between calls to swap_info and swap_devname calls, we get mangled list. >=20 > Ok, I see that you fixed this by unifying those functions. Rather, by gathering both pieces of information without dropping the protection of sw_dev_mtx. >=20 > > The third problem, which is not fixed, and which I do not want to handl= e, > > is that the swap devices list can be changed between calls to swap_devn= ame(), > > changing device indexes and thus making the output mangled. >=20 > You say you don't want to handle this, but AFAICT from the patch you > already did. Or did I miss something? Since sw_dev_mtx is dropped and reacquired between each iteration of the loop, some swap device may be removed meantime. At least, the output will show the same device twice. Hm, the swapoff/swapon routines are half-protected by the Giant, taking the Giant around the loop prevents the swap device list changes. >=20 > > Should the swap device name be separated from 'unknown' word by > > space or by tab ? >=20 > Linux' /proc/swaps prints spaces after the first column and tabs for > the rest. I think it's better to do the same just in case, but I > don't think it's relevant either way. Right, I added a comment to not have this broken by somebody in future. >=20 > > I updated your patch, hopefully fixing the issues. Do you have comments > > or objections ? >=20 > No. Thanks for fixing those problems. Below is the hopefully final patch after Bruce Evans' comments incorporated. If nobody speaks, I will send this to re tomorrow. diff --git a/sys/compat/linprocfs/linprocfs.c b/sys/compat/linprocfs/linpro= cfs.c index 692c5a3..8832d3d 100644 --- a/sys/compat/linprocfs/linprocfs.c +++ b/sys/compat/linprocfs/linprocfs.c @@ -502,6 +502,33 @@ linprocfs_dostat(PFS_FILL_ARGS) return (0); } =20 +static int +linprocfs_doswaps(PFS_FILL_ARGS) +{ + struct xswdev xsw; + uintmax_t total, used; + int n; + char devname[SPECNAMELEN + 1]; + + sbuf_printf(sb, "Filename\t\t\t\tType\t\tSize\tUsed\tPriority\n"); + mtx_lock(&Giant); + for (n =3D 0; ; n++) { + if (swap_dev_info(n, &xsw, devname, sizeof(devname)) !=3D 0) + break; + total =3D (uintmax_t)xsw.xsw_nblks * PAGE_SIZE / 1024; + used =3D (uintmax_t)xsw.xsw_used * PAGE_SIZE / 1024; + + /* + * The space and not tab after the device name is on + * purpose. Linux does so. + */ + sbuf_printf(sb, "/dev/%-34s unknown\t\t%jd\t%jd\t-1\n", + devname, total, used); + } + mtx_unlock(&Giant); + return (0); +} + /* * Filler function for proc/uptime */ @@ -1490,6 +1517,8 @@ linprocfs_init(PFS_INIT_ARGS) NULL, NULL, NULL, 0); pfs_create_file(root, "stat", &linprocfs_dostat, NULL, NULL, NULL, PFS_RD); + pfs_create_file(root, "swaps", &linprocfs_doswaps, + NULL, NULL, NULL, PFS_RD); pfs_create_file(root, "uptime", &linprocfs_douptime, NULL, NULL, NULL, PFS_RD); pfs_create_file(root, "version", &linprocfs_doversion, diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c index f421e4f..9a818e7 100644 --- a/sys/vm/swap_pager.c +++ b/sys/vm/swap_pager.c @@ -2365,35 +2365,53 @@ swap_pager_status(int *total, int *used) mtx_unlock(&sw_dev_mtx); } =20 -static int -sysctl_vm_swap_info(SYSCTL_HANDLER_ARGS) +int +swap_dev_info(int name, struct xswdev *xs, char *devname, size_t len) { - int *name =3D (int *)arg1; - int error, n; - struct xswdev xs; struct swdevt *sp; - - if (arg2 !=3D 1) /* name length */ - return (EINVAL); + char *tmp_devname; + int error, n; =20 n =3D 0; + error =3D ENOENT; mtx_lock(&sw_dev_mtx); TAILQ_FOREACH(sp, &swtailq, sw_list) { - if (n =3D=3D *name) { - mtx_unlock(&sw_dev_mtx); - xs.xsw_version =3D XSWDEV_VERSION; - xs.xsw_dev =3D sp->sw_dev; - xs.xsw_flags =3D sp->sw_flags; - xs.xsw_nblks =3D sp->sw_nblks; - xs.xsw_used =3D sp->sw_used; - - error =3D SYSCTL_OUT(req, &xs, sizeof(xs)); - return (error); + if (n !=3D name) { + n++; + continue; + } + xs->xsw_version =3D XSWDEV_VERSION; + xs->xsw_dev =3D sp->sw_dev; + xs->xsw_flags =3D sp->sw_flags; + xs->xsw_nblks =3D sp->sw_nblks; + xs->xsw_used =3D sp->sw_used; + if (devname !=3D NULL) { + if (vn_isdisk(sp->sw_vp, NULL)) + tmp_devname =3D sp->sw_vp->v_rdev->si_name; + else + tmp_devname =3D "[file]"; + strncpy(devname, tmp_devname, len); } - n++; + error =3D 0; + break; } mtx_unlock(&sw_dev_mtx); - return (ENOENT); + return (error); +} + +static int +sysctl_vm_swap_info(SYSCTL_HANDLER_ARGS) +{ + struct xswdev xs; + int error; + + if (arg2 !=3D 1) /* name length */ + return (EINVAL); + error =3D swap_dev_info(*(int *)arg1, &xs, NULL, 0); + if (error !=3D 0) + return (error); + error =3D SYSCTL_OUT(req, &xs, sizeof(xs)); + return (error); } =20 SYSCTL_INT(_vm, OID_AUTO, nswapdev, CTLFLAG_RD, &nswapdev, 0, diff --git a/sys/vm/swap_pager.h b/sys/vm/swap_pager.h index c3366e8..5c716d9 100644 --- a/sys/vm/swap_pager.h +++ b/sys/vm/swap_pager.h @@ -75,7 +75,8 @@ struct swdevt { extern int swap_pager_full; extern int swap_pager_avail; =20 -struct swdevt; +struct xswdev; +int swap_dev_info(int name, struct xswdev *xs, char *devname, size_t len); void swap_pager_copy(vm_object_t, vm_object_t, vm_pindex_t, int); void swap_pager_freespace(vm_object_t, vm_pindex_t, vm_size_t); void swap_pager_swap_init(void); --bQyVjumYeq8yaMqA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk41rUgACgkQC3+MBN1Mb4jcCgCbBopXf7BBTgF9YQQNo+1rPhQV g7EAoJTlQnYCyX0NfmREKoqOj+AxQM2J =waeg -----END PGP SIGNATURE----- --bQyVjumYeq8yaMqA-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 22:42:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DB1A106566B; Sun, 31 Jul 2011 22:42:10 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2886A8FC0C; Sun, 31 Jul 2011 22:42:10 +0000 (UTC) Received: from host182.msm.che.vodafone (unknown [212.183.128.47]) by cyrus.watson.org (Postfix) with ESMTPSA id A6A1546B09; Sun, 31 Jul 2011 18:41:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Sun, 31 Jul 2011 23:41:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <01C0A915-F2AC-4FD7-9196-5613CC91E27D@freebsd.org> References: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> To: Jayachandran C. X-Mailer: Apple Mail (2.1084) Cc: "freebsd-hackers@freebsd.org" , James Jones Subject: Re: MIPS toolchain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 22:42:10 -0000 On 31 Jul 2011, at 12:22, Jayachandran C. wrote: >> In fact, there are some toolchain bugs I'm running into that manifest = only >> in the SDE toolchain and not the FreeBSD toolchain. (Mind you, = Philip has >> commented that in building Uboot for MIPS, he's found FreeBSD bugs = that >> don't appear in the SDE toolchain, so mileage varies). >=20 > Any idea what the bugs where? If there are fixes that can be > backported without license issues, we take take a look at this. I'm on travel currently, so don't have my notes on this with me, but as = I recall they were primarily in some combination of as and ld. A few = that come to mind off-hand: (1) .noat appears not always to work: you sometimes get sequences that = use $at without warnings from the assembler (this might be more SDE than = the FreeBSD version of as, my recollection is a bit hazy -- I know the = FreeBSD version appeared more correct in my experimentation than SDE in = this regard) (2) If you try to disable generation of divide by zero checks for ddiv = (for example) by using --no-break and --no-trap, you end up with both = break and trap instrumentation rather than neither (if I recall); later = FSF versions appear to support a --argument of some sort that completely = disables this, but both the FreeBSD and SDE versions seem not to include = it (3) ld's -o binary gives very mixed results; objcopy with a binary = output type seems to consistently work (4) I haven't yet spotted a way to prevent generation of madd/msub = instructions when using a 64-bit MIPS architecture, although there were = a moderate number of MIPS systems built that implement a 64-bit ISA = without madd/msub (but I've not dug deeply yet, so have probably simply = missed an arch option). (5) I find it annoying, although perhaps it is a feature, that objdump = -s generates MIPS register names without prefixed $ symbols, so can't be = fed straight back into as :-). Changing the output syntax would probably = confuse other stuff at this point, however. I'll dig in a bit more when I get back to the office later this week and = try to come up with a more reproducible description (and confirmation) = of each. I'm not sure any of these is the source of the problems Philip = has experienced with Uboot. Robert= From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 00:58:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E6DB106564A for ; Mon, 1 Aug 2011 00:58:12 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30F088FC13 for ; Mon, 1 Aug 2011 00:58:11 +0000 (UTC) Received: by yxl31 with SMTP id 31so3711147yxl.13 for ; Sun, 31 Jul 2011 17:58:11 -0700 (PDT) Received: by 10.101.213.18 with SMTP id p18mr2735009anq.98.1312158518671; Sun, 31 Jul 2011 17:28:38 -0700 (PDT) Received: from papi.localnet ([177.17.4.208]) by mx.google.com with ESMTPS id g8sm2746955and.0.2011.07.31.17.28.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 17:28:38 -0700 (PDT) From: Mario Lobo To: FreeBSD Questions Date: Sun, 31 Jul 2011 21:28:29 -0300 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201107312128.29322.lobo@bsd.com.br> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 00:58:12 -0000 Hi to all In my desktop machine, I had an AM2+ ASROCK mobo with Phenom II 955 BE that= =20 showed each core temperature perfectly under FBSD 8-STABLE, via=20 dev.cpu.x.temp. amdtemp.ko loaded. Unfortunately this Mobo died and only found AM3 boards for which my phenom = 955=20 doesn't fit. So I got an ASUS M4A88T-V EVO with a Phenom II 975 BE.=20 =46unny thing. An AM3 phenom II fits on an AM2 board but an AM3 board doesn= 't=20 accept an AM2/AM2+ phenom II :(. Anyway, now, under the very same system, it shows 0 degrees on dev.cpu.x.te= mp=20 for all cores. I've been looking through k8temp and amdtemp src code. I am definitely not= =20 sure of this but I believe something might have happened to those: =46rom k8temp.h K10_THERM_REG 0xa4=20 K10_THERMTRIP_REG 0xe4 K10_CURTMP(val) (((val) >> 21) & 0xfff) K10_THERMTRIP(val) ((val >> 1) & 1) =46rom amdtemp.c /* * Register control (K8 family) */ #define AMDTEMP_REG0F 0xe4 #define AMDTEMP_REG_SELSENSOR 0x40 #define AMDTEMP_REG_SELCORE 0x04 /* * Register control (K10 & K11) family */ #define AMDTEMP_REG 0xa4 Output of k8temp -dn: CPUID: Vendor: AuthenticAMD, 0x100f43: Model=3D04 Family=3Df+1 Stepping=3D3 Advanced Power Management=3D0x1f9 Temperature sensor: Yes Frequency ID control: No Voltage ID control: No THERMTRIP support: Yes HW Thermal control: Yes SW Thermal control: Yes 100MHz multipliers: Yes HW P-State control: Yes TSC Invariant: Yes Temp=3Dc0fef ThermTrip=3D1fc00c30 0 I keep a small win7 partition to test little things like this and see if th= e=20 same thing happens there, and it doesn't, so I concluded that the sensors a= re=20 there and are working. One thing is worth noting though. I have used a free gadget that shows=20 activity/temp for each core. It worked fine with the previous MB/CPU.That A= LSO=20 stopped working with this new MB. Like FBSD, it shows 0 degrees for any cor= e=20 too, although it correctly displays each core load. The only windows tool that correctly shows the temperature are the ASUS too= ls=20 that came with the mobo. Other than that, everything is working fine! The only thing I had to fix wa= s=20 the fstab ada location. I know this is not a big thing but I got accustomed to keeping an eye on th= ose=20 temperatures. I have googled for a few days now searching for Thermal register address or= =20 offsets for the Phenom II 975 BE, or anything related to this problem and=20 found nothing. Every search on AMD site was fruitless. I could not find a=20 single bit of tech info on this processor there, or any other tech info for= =20 that matter. Would any one have any pointers/clues/suggestions on this? Thanks, =2D-=20 Mario Lobo http://www.mallavoodoo.com.br =46reeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 02:07:16 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86217106566B for ; Mon, 1 Aug 2011 02:07:16 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 01AFB8FC0C for ; Mon, 1 Aug 2011 02:07:15 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p71276g6012843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2011 11:37:12 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Mon, 1 Aug 2011 11:37:06 +0930 Content-Transfer-Encoding: 7bit Message-Id: References: To: Stephen Hocking X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: -4.164 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: hackers@freebsd.org Subject: Re: Best GB Nic for 8.2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 02:07:16 -0000 On 31/07/2011, at 16:53, Stephen Hocking wrote: > Am currently using an onboard GB nic, on my main fileserver (8.2 > 64bit, AMD, 8GB mem) which is seen as nfe0 (Nvidia, basically). Is > there a better one available? I have a one lane PCIe slot and any > number of PCI slots available. Any Intel one. They come in both PCI and PCIe forms. I have a.. Intel 82574L Gigabit Ethernet Controller (82574L) (that's the chip in it anyway, I can't remember the model number) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 04:34:26 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB79D1065674 for ; Mon, 1 Aug 2011 04:34:26 +0000 (UTC) (envelope-from bvgastel@bitpowder.com) Received: from smtp10.mail.sp.isp-net.nl (smtp10.mail.sp.isp-net.nl [217.149.192.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6C40E8FC12 for ; Mon, 1 Aug 2011 04:34:25 +0000 (UTC) Received: from bitpowder.com by smtp10.mail.sp.isp-net.nl via 28-53-223.ftth.xms.internl.net [85.223.53.28] with ESMTP for id p6VJxoWM017730 (8.13.2/2.04); Sun, 31 Jul 2011 21:59:50 +0200 (MEST) Received: from [10.0.42.5] (shell [10.0.42.20]) by bitpowder.com (Postfix) with ESMTPA id A3CC11112001 for ; Sun, 31 Jul 2011 20:00:53 +0000 (UTC) From: Bernard van Gastel Content-Type: multipart/signed; boundary="Apple-Mail=_195B80BE-B7A7-412D-BE16-7032DBFD4732"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 31 Jul 2011 21:59:48 +0200 Message-Id: To: hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Language-Detected: en X-Spam-Scanned: InterNLnet Mail Scan System V2.03 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: eliminating a syscall on accept()+ioctl() combo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 04:34:26 -0000 --Apple-Mail=_195B80BE-B7A7-412D-BE16-7032DBFD4732 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I want to reduce the number of syscalls for my networking application. = The app handles incoming connections with the 'accept()' system call. Is = there a way to specify to accept() that the newly created file = descriptors should be non-blocking (FIONBIO)? This will avoid an ioctl() = after the accept(). Thanks! With regards, Bernard= --Apple-Mail=_195B80BE-B7A7-412D-BE16-7032DBFD4732-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 06:34:40 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13215106564A for ; Mon, 1 Aug 2011 06:34:40 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C54A8FC13 for ; Mon, 1 Aug 2011 06:34:39 +0000 (UTC) Received: by fxe4 with SMTP id 4so5849964fxe.13 for ; Sun, 31 Jul 2011 23:34:38 -0700 (PDT) Received: by 10.223.159.8 with SMTP id h8mr5928686fax.3.1312179069162; Sun, 31 Jul 2011 23:11:09 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id x13sm2670948fah.29.2011.07.31.23.11.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 23:11:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Vlad Galu In-Reply-To: Date: Mon, 1 Aug 2011 08:11:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E99FCF5-66DF-422E-B2FE-28547AF916A7@dudu.ro> References: To: Bernard van Gastel X-Mailer: Apple Mail (2.1244.3) Cc: hackers@freebsd.org Subject: Re: eliminating a syscall on accept()+ioctl() combo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 06:34:40 -0000 On Jul 31, 2011, at 9:59 PM, Bernard van Gastel wrote: > Hi all, >=20 > I want to reduce the number of syscalls for my networking application. = The app handles incoming connections with the 'accept()' system call. Is = there a way to specify to accept() that the newly created file = descriptors should be non-blocking (FIONBIO)? This will avoid an ioctl() = after the accept(). Thanks! >=20 > With regards, > Bernard Hi Bernard, You can make your listening socket non-blocking. Newly created file = descriptors will inherit that property. However, that will require you = to select()/poll()/kqueue() for that descriptor as well, instead of = simply blocking in accept(). HTH Vlad= From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 14:14:43 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D074B1065675 for ; Mon, 1 Aug 2011 14:14:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EDFF18FC12 for ; Mon, 1 Aug 2011 14:14:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA27720; Mon, 01 Aug 2011 17:14:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E36B4CF.3060308@FreeBSD.org> Date: Mon, 01 Aug 2011 17:14:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Mario Lobo References: <201107312128.29322.lobo@bsd.com.br> In-Reply-To: <201107312128.29322.lobo@bsd.com.br> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@FreeBSD.org, FreeBSD Questions Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:14:44 -0000 on 01/08/2011 03:28 Mario Lobo said the following: > Hi to all > > In my desktop machine, I had an AM2+ ASROCK mobo with Phenom II 955 BE that > showed each core temperature perfectly under FBSD 8-STABLE, via > dev.cpu.x.temp. amdtemp.ko loaded. > > Unfortunately this Mobo died and only found AM3 boards for which my phenom 955 > doesn't fit. So I got an ASUS M4A88T-V EVO with a Phenom II 975 BE. > > Funny thing. An AM3 phenom II fits on an AM2 board but an AM3 board doesn't > accept an AM2/AM2+ phenom II :(. > > Anyway, now, under the very same system, it shows 0 degrees on dev.cpu.x.temp > for all cores. Sorry, I've got lost in all the config changes. So what system do you have now? Can please also provide CPU-related information from dmesg? > I've been looking through k8temp and amdtemp src code. I am definitely not > sure of this but I believe something might have happened to those: > > From k8temp.h > > K10_THERM_REG 0xa4 > K10_THERMTRIP_REG 0xe4 > K10_CURTMP(val) (((val) >> 21) & 0xfff) > K10_THERMTRIP(val) ((val >> 1) & 1) > > From amdtemp.c > > /* > * Register control (K8 family) > */ > #define AMDTEMP_REG0F 0xe4 > #define AMDTEMP_REG_SELSENSOR 0x40 > #define AMDTEMP_REG_SELCORE 0x04 > > /* > * Register control (K10 & K11) family > */ > #define AMDTEMP_REG 0xa4 > > > Output of k8temp -dn: > > CPUID: Vendor: AuthenticAMD, 0x100f43: Model=04 Family=f+1 Stepping=3 > Advanced Power Management=0x1f9 > Temperature sensor: Yes > Frequency ID control: No > Voltage ID control: No > THERMTRIP support: Yes > HW Thermal control: Yes > SW Thermal control: Yes > 100MHz multipliers: Yes > HW P-State control: Yes > TSC Invariant: Yes > Temp=c0fef > ThermTrip=1fc00c30 > 0 > > I keep a small win7 partition to test little things like this and see if the > same thing happens there, and it doesn't, so I concluded that the sensors are > there and are working. > > One thing is worth noting though. I have used a free gadget that shows > activity/temp for each core. It worked fine with the previous MB/CPU.That ALSO > stopped working with this new MB. Like FBSD, it shows 0 degrees for any core > too, although it correctly displays each core load. Most likely that gadget just re-uses OS-provided information. > The only windows tool that correctly shows the temperature are the ASUS tools > that came with the mobo. > > Other than that, everything is working fine! The only thing I had to fix was > the fstab ada location. > > I know this is not a big thing but I got accustomed to keeping an eye on those > temperatures. > > I have googled for a few days now searching for Thermal register address or > offsets for the Phenom II 975 BE, or anything related to this problem and > found nothing. Every search on AMD site was fruitless. I could not find a > single bit of tech info on this processor there, or any other tech info for > that matter. http://support.amd.com/us/Processor_TechDocs/31116.pdf > Would any one have any pointers/clues/suggestions on this? I would try to add some printfs (or used dtrace - whichever is easier for you) to see what's going on. Or you can even use pciconf to directly sneak a peek at what's reported by the hardware, e.g.: # pciconf -r pci0:0:24:3 0xa4 1c881880 You can read the BKDG to see how to interpret the value - search for F3xA4. See F3xE4 for offset calculation. Hopefully you should be able to see if hardware reports sane value and how the amdtemp ends up reporting 0°C. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 16:24:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B31FC106564A; Mon, 1 Aug 2011 16:24:07 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Mon, 1 Aug 2011 12:23:48 -0400 User-Agent: KMail/1.6.2 References: <201107312128.29322.lobo@bsd.com.br> <4E36B4CF.3060308@FreeBSD.org> In-Reply-To: <4E36B4CF.3060308@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_bMtNOs9uQI1kw+C" Message-Id: <201108011223.55772.jkim@FreeBSD.org> Cc: Mario Lobo , freebsd-questions@freebsd.org, Andriy Gapon Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:24:09 -0000 --Boundary-00=_bMtNOs9uQI1kw+C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline On Monday 01 August 2011 10:14 am, Andriy Gapon wrote: > on 01/08/2011 03:28 Mario Lobo said the following: > > Hi to all > > > > In my desktop machine, I had an AM2+ ASROCK mobo with Phenom II > > 955 BE that showed each core temperature perfectly under FBSD > > 8-STABLE, via dev.cpu.x.temp. amdtemp.ko loaded. > > > > Unfortunately this Mobo died and only found AM3 boards for which > > my phenom 955 doesn't fit. So I got an ASUS M4A88T-V EVO with a > > Phenom II 975 BE. > > > > Funny thing. An AM3 phenom II fits on an AM2 board but an AM3 > > board doesn't accept an AM2/AM2+ phenom II :(. > > > > Anyway, now, under the very same system, it shows 0 degrees on > > dev.cpu.x.temp for all cores. > > Sorry, I've got lost in all the config changes. So what system do > you have now? Can please also provide CPU-related information from > dmesg? > > > I've been looking through k8temp and amdtemp src code. I am > > definitely not sure of this but I believe something might have > > happened to those: > > > > From k8temp.h > > > > K10_THERM_REG 0xa4 > > K10_THERMTRIP_REG 0xe4 > > K10_CURTMP(val) (((val) >> 21) & 0xfff) > > K10_THERMTRIP(val) ((val >> 1) & 1) > > > > From amdtemp.c > > > > /* > > * Register control (K8 family) > > */ > > #define AMDTEMP_REG0F 0xe4 > > #define AMDTEMP_REG_SELSENSOR 0x40 > > #define AMDTEMP_REG_SELCORE 0x04 > > > > /* > > * Register control (K10 & K11) family > > */ > > #define AMDTEMP_REG 0xa4 > > > > > > Output of k8temp -dn: > > > > CPUID: Vendor: AuthenticAMD, 0x100f43: Model=04 Family=f+1 > > Stepping=3 Advanced Power Management=0x1f9 > > Temperature sensor: Yes > > Frequency ID control: No > > Voltage ID control: No > > THERMTRIP support: Yes > > HW Thermal control: Yes > > SW Thermal control: Yes > > 100MHz multipliers: Yes > > HW P-State control: Yes > > TSC Invariant: Yes > > Temp=c0fef > > ThermTrip=1fc00c30 > > 0 > > > > I keep a small win7 partition to test little things like this and > > see if the same thing happens there, and it doesn't, so I > > concluded that the sensors are there and are working. > > > > One thing is worth noting though. I have used a free gadget that > > shows activity/temp for each core. It worked fine with the > > previous MB/CPU.That ALSO stopped working with this new MB. Like > > FBSD, it shows 0 degrees for any core too, although it correctly > > displays each core load. > > Most likely that gadget just re-uses OS-provided information. > > > The only windows tool that correctly shows the temperature are > > the ASUS tools that came with the mobo. > > > > Other than that, everything is working fine! The only thing I had > > to fix was the fstab ada location. > > > > I know this is not a big thing but I got accustomed to keeping an > > eye on those temperatures. > > > > I have googled for a few days now searching for Thermal register > > address or offsets for the Phenom II 975 BE, or anything related > > to this problem and found nothing. Every search on AMD site was > > fruitless. I could not find a single bit of tech info on this > > processor there, or any other tech info for that matter. > > http://support.amd.com/us/Processor_TechDocs/31116.pdf > > > Would any one have any pointers/clues/suggestions on this? > > I would try to add some printfs (or used dtrace - whichever is > easier for you) to see what's going on. Or you can even use > pciconf to directly sneak a peek at what's reported by the > hardware, e.g.: > # pciconf -r pci0:0:24:3 0xa4 > 1c881880 > > You can read the BKDG to see how to interpret the value - search > for F3xA4. See F3xE4 for offset calculation. > > Hopefully you should be able to see if hardware reports sane value > and how the amdtemp ends up reporting 0�C. I gave up the DiodeOffset recently because a lot of BIOSes do not set any meaningful values. Instead, I added a tunable for that. Please see the attached patch, which is also available from here: http://people.freebsd.org/~jkim/amdtemp.diff Jung-uk Kim --Boundary-00=_bMtNOs9uQI1kw+C Content-Type: text/plain; charset="utf-8"; name="amdtemp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="amdtemp.diff" Index: share/man/man4/amdtemp.4 =================================================================== --- share/man/man4/amdtemp.4 (revision 221788) +++ share/man/man4/amdtemp.4 (working copy) @@ -25,12 +25,14 @@ .\" .\" $FreeBSD$ .\" -.Dd April 8, 2008 +.Dd May 11, 2011 .Dt AMDTEMP 4 .Os .Sh NAME .Nm amdtemp -.Nd device driver for AMD K8, K10 and K11 on-die digital thermal sensor +.Nd device driver for +.Tn AMD +processor on-die digital thermal sensor .Sh SYNOPSIS To compile this driver into the kernel, place the following line in your @@ -49,22 +51,48 @@ amdtemp_load="YES" The .Nm driver provides support for the on-die digital thermal sensor present -in AMD K8, K10 and K11 processors. +in +.Tn AMD +Family 0Fh, 10h, 11h, 12h, and 14h processors. .Pp -For the K8 family, the +For Family 0Fh processors, the .Nm -driver reports each core's temperature through a sysctl node in the -corresponding CPU devices's sysctl tree, named -.Va dev.amdtemp.%d.sensor{0,1}.core{0,1} . +driver reports each core's temperature through sysctl nodes, named +.Va dev.amdtemp.%d.core{0,1}.sensor{0,1} . The driver also creates .Va dev.cpu.%d.temperature -displaying the maximum temperature of the two sensors -located in each CPU core. +in the corresponding CPU device's sysctl tree, displaying the maximum +temperature of the two sensors located in each CPU core. .Pp -For the K10 and K11 families, the driver creates +For Family 10h, 11h, 12h, and 14h processors, the driver reports each +package's temperature through a sysctl node, named +.Va dev.amdtemp.%d.core0.sensor0 . +The driver also creates .Va dev.cpu.%d.temperature -with the temperature of each core. +in the corresponding CPU device's sysctl tree, displaying the temperature +of the shared sensor located in each CPU package. +.Sh LOADER TUNABLES +The following tunable can be set at the +.Xr loader 8 +prompt before booting the kernel, or stored in +.Xr loader.conf 5 . +.Bl -tag -width indent +.It Va hw.amdtemp.force_enable +.El +Set to a non-zero value to force enabling the driver for Family 10h Socket +AM2+ and Socket F package processors. +.Sh SYSCTL VARIABLES +The following variable is available as both +.Xr sysctl 8 +variable and +.Xr loader 8 +tunable: +.Bl -tag -width indent +.It Va dev.amdtemp.%d.sensor_offset +.El +Add the given offset to the temperature of the sensor. Default is 0. .Sh SEE ALSO +.Xr loader 8 , .Xr sysctl 8 .Sh HISTORY The @@ -74,6 +102,19 @@ driver first appeared in .Sh AUTHORS .An Rui Paulo Aq rpaulo@FreeBSD.org .An Norikatsu Shigemura Aq nork@FreeBSD.org -.Sh BUGS -AMD K9 is not supported because temperature reporting has been replaced -by Maltese. +.An Jung-uk Kim Aq jkim@FreeBSD.org +.Sh CAVEATS +For Family 10h and later processors, +.Do +(the reported temperature) is a non-physical temperature measured on +an arbitrary scale and it does not represent an actual physical +temperature like die or case temperature. Instead, it specifies +the processor temperature relative to the point at which the system +must supply the maximum cooling for the processor's specified maximum +case temperature and maximum thermal power dissipation +.Dc +according to +.Rs +.%T BIOS and Kernel Developer's Guide (BKDG) for AMD Processors +.%U http://developer.amd.com/documentation/guides/Pages/default.aspx +.Re Index: sys/dev/amdtemp/amdtemp.c =================================================================== --- sys/dev/amdtemp/amdtemp.c (revision 221788) +++ sys/dev/amdtemp/amdtemp.c (working copy) @@ -1,7 +1,7 @@ /*- * Copyright (c) 2008, 2009 Rui Paulo * Copyright (c) 2009 Norikatsu Shigemura - * Copyright (c) 2009 Jung-uk Kim + * Copyright (c) 2009-2011 Jung-uk Kim * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -27,7 +27,7 @@ */ /* - * Driver for the AMD CPU on-die thermal sensors for Family 0Fh/10h/11h procs. + * Driver for the AMD CPU on-die thermal sensors. * Initially based on the k8temp Linux driver. */ @@ -42,17 +42,23 @@ __FBSDID("$FreeBSD$"); #include #include -#include #include #include #include +static int amdtemp_force_enable; +TUNABLE_INT("hw.amdtemp.force_enable", &amdtemp_force_enable); +SYSCTL_NODE(_hw, OID_AUTO, amdtemp, CTLFLAG_RD, 0, "amdtemp driver parameters"); +SYSCTL_INT(_hw_amdtemp, OID_AUTO, force_enable, CTLFLAG_RDTUN, + &amdtemp_force_enable, 0, + "Force enabling on Family 10h Socket AM2+ and F package processors"); + typedef enum { - SENSOR0_CORE0, - SENSOR0_CORE1, - SENSOR1_CORE0, - SENSOR1_CORE1, + CORE0_SENSOR0, + CORE0_SENSOR1, + CORE1_SENSOR0, + CORE1_SENSOR1, CORE0, CORE1 } amdsensor_t; @@ -62,11 +68,10 @@ struct amdtemp_softc { int sc_ncores; int sc_ntemps; int sc_flags; -#define AMDTEMP_FLAG_DO_QUIRK 0x01 /* DiodeOffset may be incorrect. */ -#define AMDTEMP_FLAG_DO_ZERO 0x02 /* DiodeOffset starts from 0C. */ -#define AMDTEMP_FLAG_DO_SIGN 0x04 /* DiodeOffsetSignBit is present. */ -#define AMDTEMP_FLAG_CS_SWAP 0x08 /* ThermSenseCoreSel is inverted. */ -#define AMDTEMP_FLAG_CT_10BIT 0x10 /* CurTmp is 10-bit wide. */ +#define AMDTEMP_FLAG_CS_SWAP 0x01 /* ThermSenseCoreSel is inverted. */ +#define AMDTEMP_FLAG_CT_10BIT 0x02 /* CurTmp is 10-bit wide. */ +#define AMDTEMP_FLAG_ALT_OFFSET 0x04 /* CurTmp starts at -28C. */ + int32_t sc_offset; int32_t (*sc_gettemp)(device_t, amdsensor_t); struct sysctl_oid *sc_sysctl_cpu[MAXCPU]; struct intr_config_hook sc_ich; @@ -76,6 +81,7 @@ struct amdtemp_softc { #define DEVICEID_AMD_MISC0F 0x1103 #define DEVICEID_AMD_MISC10 0x1203 #define DEVICEID_AMD_MISC11 0x1303 +#define DEVICEID_AMD_MISC14 0x1703 static struct amdtemp_product { uint16_t amdtemp_vendorid; @@ -84,11 +90,12 @@ static struct amdtemp_product { { VENDORID_AMD, DEVICEID_AMD_MISC0F }, { VENDORID_AMD, DEVICEID_AMD_MISC10 }, { VENDORID_AMD, DEVICEID_AMD_MISC11 }, + { VENDORID_AMD, DEVICEID_AMD_MISC14 }, { 0, 0 } }; /* - * Reported Temperature Control Register (Family 10h/11h only) + * Reported Temperature Control Register */ #define AMDTEMP_REPTMP_CTRL 0xa4 @@ -100,6 +107,12 @@ static struct amdtemp_product { #define AMDTEMP_TTSR_SELSENSOR 0x40 /* Family 0Fh only */ /* + * DRAM Configuration High Register + */ +#define AMDTEMP_DRAM_CONF_HIGH 0x94 /* Function 2 */ +#define AMDTEMP_DRAM_MODE_DDR3 0x0100 + +/* * CPU Family/Model Register */ #define AMDTEMP_CPUID 0xfc @@ -117,6 +130,9 @@ static int32_t amdtemp_gettemp0f(device_t dev, amd static int32_t amdtemp_gettemp(device_t dev, amdsensor_t sensor); static int amdtemp_sysctl(SYSCTL_HANDLER_ARGS); +/* XXX */ +extern uint32_t pci_cfgregread(int, int, int, int, int); + static device_method_t amdtemp_methods[] = { /* Device interface */ DEVMETHOD(device_identify, amdtemp_identify), @@ -173,6 +189,7 @@ amdtemp_identify(driver_t *driver, device_t parent static int amdtemp_probe(device_t dev) { + u_int regs[4]; uint32_t family, model; if (resource_disabled("amdtemp", 0)) @@ -188,7 +205,30 @@ amdtemp_probe(device_t dev) return (ENXIO); break; case 0x10: + if (amdtemp_force_enable) + break; + /* + * Erratum 319 Inaccurate Temperature Measurement + * + * http://support.amd.com/us/Processor_TechDocs/41322.pdf + */ + do_cpuid(0x80000001, regs); + switch ((regs[1] >> 28) & 0xf) { + case 0: /* Socket F */ + return (ENXIO); + case 1: /* Socket AM2+ or AM3 */ + if ((pci_cfgregread(pci_get_bus(dev), + pci_get_slot(dev), 2, AMDTEMP_DRAM_CONF_HIGH, 2) & + AMDTEMP_DRAM_MODE_DDR3) != 0 || model > 0x04 || + (model == 0x04 && (cpu_id & CPUID_STEPPING) >= 3)) + break; + /* XXX 00100F42h (RB-C2) exists in both formats. */ + return (ENXIO); + } + break; case 0x11: + case 0x12: + case 0x14: break; default: return (ENXIO); @@ -201,22 +241,14 @@ amdtemp_probe(device_t dev) static int amdtemp_attach(device_t dev) { + char tn[32]; struct amdtemp_softc *sc = device_get_softc(dev); struct sysctl_ctx_list *sysctlctx; struct sysctl_oid *sysctlnode; - uint32_t regs[4]; uint32_t cpuid, family, model; + int unit; /* - * Errata #154: Incorect Diode Offset - */ - if (cpu_id == 0x20f32) { - do_cpuid(0x80000001, regs); - if ((regs[1] & 0xfff) == 0x2c) - sc->sc_flags |= AMDTEMP_FLAG_DO_QUIRK; - } - - /* * CPUID Register is available from Revision F. */ family = CPUID_TO_FAMILY(cpu_id); @@ -232,11 +264,6 @@ amdtemp_attach(device_t dev) /* * Thermaltrip Status Register * - * - DiodeOffsetSignBit - * - * Revision D & E: bit 24 - * Other: N/A - * * - ThermSenseCoreSel * * Revision F & G: 0 - Core1, 1 - Core0 @@ -254,15 +281,39 @@ amdtemp_attach(device_t dev) * ThermSenseCoreSel work in undocumented cases as well. * In fact, the Linux driver suggests it may not work but * we just assume it does until we find otherwise. + * + * XXX According to Linux, CurTmp starts at -28C on + * Socket AM2 Revision G processors, which is not + * documented anywhere. */ - if (model < 0x40) { - sc->sc_flags |= AMDTEMP_FLAG_DO_ZERO; - if (model >= 0x10) - sc->sc_flags |= AMDTEMP_FLAG_DO_SIGN; - } else { + if (model >= 0x40) sc->sc_flags |= AMDTEMP_FLAG_CS_SWAP; - if (model >= 0x60 && model != 0xc1) - sc->sc_flags |= AMDTEMP_FLAG_CT_10BIT; + if (model >= 0x60 && model != 0xc1) { + u_int regs[4], bid; + + do_cpuid(0x80000001, regs); + bid = (regs[1] >> 9) & 0x1f; + switch (model) { + case 0x68: /* Socket S1g1 */ + case 0x6c: + case 0x7c: + break; + case 0x6b: /* Socket AM2 and ASB1 (2 cores) */ + if (bid != 0x0b && bid != 0x0c) + sc->sc_flags |= + AMDTEMP_FLAG_ALT_OFFSET; + break; + case 0x6f: /* Socket AM2 and ASB1 (1 core) */ + case 0x7f: + if (bid != 0x07 && bid != 0x09 && + bid != 0x0c) + sc->sc_flags |= + AMDTEMP_FLAG_ALT_OFFSET; + break; + default: + sc->sc_flags |= AMDTEMP_FLAG_ALT_OFFSET; + } + sc->sc_flags |= AMDTEMP_FLAG_CT_10BIT; } /* @@ -274,6 +325,8 @@ amdtemp_attach(device_t dev) break; case 0x10: case 0x11: + case 0x12: + case 0x14: /* * There is only one sensor per package. */ @@ -297,41 +350,49 @@ amdtemp_attach(device_t dev) /* * dev.amdtemp.N tree. */ + unit = device_get_unit(dev); + snprintf(tn, sizeof(tn), "dev.amdtemp.%d.sensor_offset", unit); + TUNABLE_INT_FETCH(tn, &sc->sc_offset); + sysctlctx = device_get_sysctl_ctx(dev); + SYSCTL_ADD_INT(sysctlctx, + SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, + "sensor_offset", CTLFLAG_RW, &sc->sc_offset, 0, + "Temperature sensor offset"); sysctlnode = SYSCTL_ADD_NODE(sysctlctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, - "sensor0", CTLFLAG_RD, 0, "Sensor 0"); + "core0", CTLFLAG_RD, 0, "Core 0"); SYSCTL_ADD_PROC(sysctlctx, SYSCTL_CHILDREN(sysctlnode), - OID_AUTO, "core0", CTLTYPE_INT | CTLFLAG_RD, - dev, SENSOR0_CORE0, amdtemp_sysctl, "IK", - "Sensor 0 / Core 0 temperature"); + OID_AUTO, "sensor0", CTLTYPE_INT | CTLFLAG_RD, + dev, CORE0_SENSOR0, amdtemp_sysctl, "IK", + "Core 0 / Sensor 0 temperature"); if (sc->sc_ntemps > 1) { - if (sc->sc_ncores > 1) - SYSCTL_ADD_PROC(sysctlctx, - SYSCTL_CHILDREN(sysctlnode), - OID_AUTO, "core1", CTLTYPE_INT | CTLFLAG_RD, - dev, SENSOR0_CORE1, amdtemp_sysctl, "IK", - "Sensor 0 / Core 1 temperature"); - - sysctlnode = SYSCTL_ADD_NODE(sysctlctx, - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, - "sensor1", CTLFLAG_RD, 0, "Sensor 1"); - SYSCTL_ADD_PROC(sysctlctx, SYSCTL_CHILDREN(sysctlnode), - OID_AUTO, "core0", CTLTYPE_INT | CTLFLAG_RD, - dev, SENSOR1_CORE0, amdtemp_sysctl, "IK", - "Sensor 1 / Core 0 temperature"); + OID_AUTO, "sensor1", CTLTYPE_INT | CTLFLAG_RD, + dev, CORE0_SENSOR1, amdtemp_sysctl, "IK", + "Core 0 / Sensor 1 temperature"); - if (sc->sc_ncores > 1) + if (sc->sc_ncores > 1) { + sysctlnode = SYSCTL_ADD_NODE(sysctlctx, + SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), + OID_AUTO, "core1", CTLFLAG_RD, 0, "Core 1"); + SYSCTL_ADD_PROC(sysctlctx, SYSCTL_CHILDREN(sysctlnode), - OID_AUTO, "core1", CTLTYPE_INT | CTLFLAG_RD, - dev, SENSOR1_CORE1, amdtemp_sysctl, "IK", - "Sensor 1 / Core 1 temperature"); + OID_AUTO, "sensor0", CTLTYPE_INT | CTLFLAG_RD, + dev, CORE1_SENSOR0, amdtemp_sysctl, "IK", + "Core 1 / Sensor 0 temperature"); + + SYSCTL_ADD_PROC(sysctlctx, + SYSCTL_CHILDREN(sysctlnode), + OID_AUTO, "sensor1", CTLTYPE_INT | CTLFLAG_RD, + dev, CORE1_SENSOR1, amdtemp_sysctl, "IK", + "Core 1 / Sensor 1 temperature"); + } } /* @@ -377,7 +438,7 @@ amdtemp_intrhook(void *arg) sysctlctx = device_get_sysctl_ctx(cpu); sensor = sc->sc_ntemps > 1 ? - (i == 0 ? CORE0 : CORE1) : SENSOR0_CORE0; + (i == 0 ? CORE0 : CORE1) : CORE0_SENSOR0; sc->sc_sysctl_cpu[i] = SYSCTL_ADD_PROC(sysctlctx, SYSCTL_CHILDREN(device_get_sysctl_tree(cpu)), OID_AUTO, "temperature", CTLTYPE_INT | CTLFLAG_RD, @@ -415,13 +476,13 @@ amdtemp_sysctl(SYSCTL_HANDLER_ARGS) switch (sensor) { case CORE0: - auxtemp[0] = sc->sc_gettemp(dev, SENSOR0_CORE0); - auxtemp[1] = sc->sc_gettemp(dev, SENSOR1_CORE0); + auxtemp[0] = sc->sc_gettemp(dev, CORE0_SENSOR0); + auxtemp[1] = sc->sc_gettemp(dev, CORE0_SENSOR1); temp = imax(auxtemp[0], auxtemp[1]); break; case CORE1: - auxtemp[0] = sc->sc_gettemp(dev, SENSOR0_CORE1); - auxtemp[1] = sc->sc_gettemp(dev, SENSOR1_CORE1); + auxtemp[0] = sc->sc_gettemp(dev, CORE1_SENSOR0); + auxtemp[1] = sc->sc_gettemp(dev, CORE1_SENSOR1); temp = imax(auxtemp[0], auxtemp[1]); break; default: @@ -439,74 +500,49 @@ static int32_t amdtemp_gettemp0f(device_t dev, amdsensor_t sensor) { struct amdtemp_softc *sc = device_get_softc(dev); - uint32_t mask, temp; - int32_t diode_offset, offset; - uint8_t cfg, sel; + uint32_t mask, offset, temp; /* Set Sensor/Core selector. */ - sel = 0; + temp = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 1); + temp &= ~(AMDTEMP_TTSR_SELCORE | AMDTEMP_TTSR_SELSENSOR); switch (sensor) { - case SENSOR1_CORE0: - sel |= AMDTEMP_TTSR_SELSENSOR; + case CORE0_SENSOR1: + temp |= AMDTEMP_TTSR_SELSENSOR; /* FALLTHROUGH */ - case SENSOR0_CORE0: + case CORE0_SENSOR0: case CORE0: if ((sc->sc_flags & AMDTEMP_FLAG_CS_SWAP) != 0) - sel |= AMDTEMP_TTSR_SELCORE; + temp |= AMDTEMP_TTSR_SELCORE; break; - case SENSOR1_CORE1: - sel |= AMDTEMP_TTSR_SELSENSOR; + case CORE1_SENSOR1: + temp |= AMDTEMP_TTSR_SELSENSOR; /* FALLTHROUGH */ - case SENSOR0_CORE1: + case CORE1_SENSOR0: case CORE1: if ((sc->sc_flags & AMDTEMP_FLAG_CS_SWAP) == 0) - sel |= AMDTEMP_TTSR_SELCORE; + temp |= AMDTEMP_TTSR_SELCORE; break; } - cfg = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 1); - cfg &= ~(AMDTEMP_TTSR_SELSENSOR | AMDTEMP_TTSR_SELCORE); - pci_write_config(dev, AMDTEMP_THERMTP_STAT, cfg | sel, 1); + pci_write_config(dev, AMDTEMP_THERMTP_STAT, temp, 1); - /* CurTmp starts from -49C. */ - offset = AMDTEMP_ZERO_C_TO_K - 490; - - /* Adjust offset if DiodeOffset is set and valid. */ + mask = (sc->sc_flags & AMDTEMP_FLAG_CT_10BIT) != 0 ? 0x3ff : 0x3fc; + offset = (sc->sc_flags & AMDTEMP_FLAG_ALT_OFFSET) != 0 ? 28 : 49; temp = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 4); - diode_offset = (temp >> 8) & 0x3f; - if ((sc->sc_flags & AMDTEMP_FLAG_DO_ZERO) != 0) { - if ((sc->sc_flags & AMDTEMP_FLAG_DO_SIGN) != 0 && - ((temp >> 24) & 0x1) != 0) - diode_offset *= -1; - if ((sc->sc_flags & AMDTEMP_FLAG_DO_QUIRK) != 0 && - ((temp >> 25) & 0xf) <= 2) - diode_offset += 10; - offset += diode_offset * 10; - } else if (diode_offset != 0) - offset += (diode_offset - 11) * 10; + temp = ((temp >> 14) & mask) * 5 / 2; + temp += AMDTEMP_ZERO_C_TO_K + (sc->sc_offset - offset) * 10; - mask = (sc->sc_flags & AMDTEMP_FLAG_CT_10BIT) != 0 ? 0x3ff : 0x3fc; - temp = ((temp >> 14) & mask) * 5 / 2 + offset; - return (temp); } static int32_t amdtemp_gettemp(device_t dev, amdsensor_t sensor) { + struct amdtemp_softc *sc = device_get_softc(dev); uint32_t temp; - int32_t diode_offset, offset; - /* CurTmp starts from 0C. */ - offset = AMDTEMP_ZERO_C_TO_K; - - /* Adjust offset if DiodeOffset is set and valid. */ - temp = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 4); - diode_offset = (temp >> 8) & 0x7f; - if (diode_offset > 0 && diode_offset < 0x40) - offset += (diode_offset - 11) * 10; - temp = pci_read_config(dev, AMDTEMP_REPTMP_CTRL, 4); - temp = ((temp >> 21) & 0x7ff) * 5 / 4 + offset; + temp = ((temp >> 21) & 0x7ff) * 5 / 4; + temp += AMDTEMP_ZERO_C_TO_K + sc->sc_offset * 10; return (temp); } --Boundary-00=_bMtNOs9uQI1kw+C-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 16:34:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 53E061065670; Mon, 1 Aug 2011 16:34:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Mon, 1 Aug 2011 12:34:09 -0400 User-Agent: KMail/1.6.2 References: <201107312128.29322.lobo@bsd.com.br> In-Reply-To: <201107312128.29322.lobo@bsd.com.br> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108011234.11176.jkim@FreeBSD.org> Cc: Mario Lobo , freebsd-questions@freebsd.org Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:34:29 -0000 On Sunday 31 July 2011 08:28 pm, Mario Lobo wrote: > Hi to all > > In my desktop machine, I had an AM2+ ASROCK mobo with Phenom II 955 > BE that showed each core temperature perfectly under FBSD 8-STABLE, > via dev.cpu.x.temp. amdtemp.ko loaded. > > Unfortunately this Mobo died and only found AM3 boards for which my > phenom 955 doesn't fit. So I got an ASUS M4A88T-V EVO with a Phenom > II 975 BE. > > Funny thing. An AM3 phenom II fits on an AM2 board but an AM3 board > doesn't accept an AM2/AM2+ phenom II :(. > > Anyway, now, under the very same system, it shows 0 degrees on > dev.cpu.x.temp for all cores. > > I've been looking through k8temp and amdtemp src code. I am > definitely not > > sure of this but I believe something might have happened to those: > >From k8temp.h > > K10_THERM_REG 0xa4 > K10_THERMTRIP_REG 0xe4 > K10_CURTMP(val) (((val) >> 21) & 0xfff) > K10_THERMTRIP(val) ((val >> 1) & 1) > > >From amdtemp.c > > /* > * Register control (K8 family) > */ > #define AMDTEMP_REG0F 0xe4 > #define AMDTEMP_REG_SELSENSOR 0x40 > #define AMDTEMP_REG_SELCORE 0x04 > > /* > * Register control (K10 & K11) family > */ > #define AMDTEMP_REG 0xa4 > > > Output of k8temp -dn: > > CPUID: Vendor: AuthenticAMD, 0x100f43: Model=04 Family=f+1 > Stepping=3 Advanced Power Management=0x1f9 > Temperature sensor: Yes > Frequency ID control: No > Voltage ID control: No > THERMTRIP support: Yes > HW Thermal control: Yes > SW Thermal control: Yes > 100MHz multipliers: Yes > HW P-State control: Yes > TSC Invariant: Yes > Temp=c0fef > ThermTrip=1fc00c30 > 0 > > I keep a small win7 partition to test little things like this and > see if the same thing happens there, and it doesn't, so I concluded > that the sensors are there and are working. > > One thing is worth noting though. I have used a free gadget that > shows activity/temp for each core. It worked fine with the previous > MB/CPU.That ALSO stopped working with this new MB. Like FBSD, it > shows 0 degrees for any core too, although it correctly displays > each core load. > > The only windows tool that correctly shows the temperature are the > ASUS tools that came with the mobo. FYI, FreeBSD has aibs(4) (or acpi_aiboost(4) depending on your FreeBSD version) and it does essentially the same thing. Jung-uk Kim > Other than that, everything is working fine! The only thing I had > to fix was the fstab ada location. > > I know this is not a big thing but I got accustomed to keeping an > eye on those temperatures. > > I have googled for a few days now searching for Thermal register > address or offsets for the Phenom II 975 BE, or anything related to > this problem and found nothing. Every search on AMD site was > fruitless. I could not find a single bit of tech info on this > processor there, or any other tech info for that matter. > > > Would any one have any pointers/clues/suggestions on this? > > Thanks, From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:03:45 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6162E1065672; Mon, 1 Aug 2011 19:03:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3B28FC13; Mon, 1 Aug 2011 19:03:44 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA02272; Mon, 01 Aug 2011 22:03:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QnxmA-000EcG-H0; Mon, 01 Aug 2011 22:03:42 +0300 Message-ID: <4E36F88C.7050404@FreeBSD.org> Date: Mon, 01 Aug 2011 22:03:40 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Jung-uk Kim References: <201107312128.29322.lobo@bsd.com.br> <4E36B4CF.3060308@FreeBSD.org> <201108011223.55772.jkim@FreeBSD.org> In-Reply-To: <201108011223.55772.jkim@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:03:45 -0000 [cc list trimmed] on 01/08/2011 19:23 Jung-uk Kim said the following: > I gave up the DiodeOffset recently because a lot of BIOSes do not set > any meaningful values. Instead, I added a tunable for that. Please > see the attached patch, which is also available from here: > > http://people.freebsd.org/~jkim/amdtemp.diff I haven't tried your patch yet, but already have a few comments :-) - at least on head pci_cfgregread() is public via x86/include/pci_cfgreg.h - I am not sure if you really need it; shouldn't pci_read_config() just work since amdtemp attaches under pci bus? - about erratum 319 - I feel like objecting to amdtemp_force_enable approach; given the wide spread of AM2+ and AM3 in consumer boards, and the very important fact that I have AM2+ and I have never observed (with my own eyes) incorrect reading from amdtemp, and the less important fact that the output of amdtemp is not used for anything critical (for anything at all, in fact) in the base system, and that that would be a kind of POLA violation (which is PITA) - I propose to just print some warning message on the affected systems; at most, export that warning as a sysctl node Finally, I promise to test this patch soon-ish. Thank you for digging into this! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:10:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A39F106564A; Mon, 1 Aug 2011 19:10:47 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 41D988FC0A; Mon, 1 Aug 2011 19:10:45 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 333A437B496; Mon, 1 Aug 2011 13:52:31 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7E1FB61C43; Mon, 1 Aug 2011 13:52:30 -0500 (CDT) Date: Mon, 1 Aug 2011 13:52:30 -0500 From: "Matthew D. Fuller" To: Mario Lobo Message-ID: <20110801185230.GA81791@over-yonder.net> References: <201107312128.29322.lobo@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107312128.29322.lobo@bsd.com.br> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, FreeBSD Questions Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:10:47 -0000 On Sun, Jul 31, 2011 at 09:28:29PM -0300 I heard the voice of Mario Lobo, and lo! it spake thus: > > Unfortunately this Mobo died and only found AM3 boards for which my > phenom 955 doesn't fit. Not that it helps you now, but the 955 _is_ perfectly compatible with AM3. It's only the initial 920 and 940 that were AM2-only. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:48:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 40BCF106566B; Mon, 1 Aug 2011 19:48:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Mon, 1 Aug 2011 15:48:00 -0400 User-Agent: KMail/1.6.2 References: <201107312128.29322.lobo@bsd.com.br> <201108011223.55772.jkim@FreeBSD.org> <4E36F88C.7050404@FreeBSD.org> In-Reply-To: <4E36F88C.7050404@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108011548.03059.jkim@FreeBSD.org> Cc: Andriy Gapon Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:48:15 -0000 On Monday 01 August 2011 03:03 pm, Andriy Gapon wrote: > [cc list trimmed] > > on 01/08/2011 19:23 Jung-uk Kim said the following: > > I gave up the DiodeOffset recently because a lot of BIOSes do not > > set any meaningful values. Instead, I added a tunable for that. > > Please see the attached patch, which is also available from here: > > > > http://people.freebsd.org/~jkim/amdtemp.diff > > I haven't tried your patch yet, but already have a few comments :-) > > - at least on head pci_cfgregread() is public via > x86/include/pci_cfgreg.h That's cool. Thanks. > - I am not sure if you really need it; shouldn't pci_read_config() > just work since amdtemp attaches under pci bus? amdtemp(4) attaches under PCI bus but its sibling on function 2 isn't easy to address, i.e., hostbN. > - about erratum 319 - I feel like objecting to amdtemp_force_enable > approach; given the wide spread of AM2+ and AM3 in consumer boards, > and the very important fact that I have AM2+ and I have never > observed (with my own eyes) incorrect reading from amdtemp, and the > less important fact that the output of amdtemp is not used for > anything critical (for anything at all, in fact) in the base > system, and that that would be a kind of POLA violation (which is > PITA) - I propose to just print some warning message on the > affected systems; at most, export that warning as a sysctl node I have mixed feeling about this because I own a system with such CPU/motherboard combo, too. I also believe it works well but errata is errata. If vendor says we shouldn't use it, then we shouldn't. In fact, I am just following Linux as an example here but I have no problem with turning this into a warning message, either. AMD says it shouldn't be interpreted as physical temperature but we are doing it anyway. ;-) Jung-uk Kim > Finally, I promise to test this patch soon-ish. > Thank you for digging into this! From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 20:07:50 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68EAE106564A; Mon, 1 Aug 2011 20:07:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6B45D8FC0A; Mon, 1 Aug 2011 20:07:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA03115; Mon, 01 Aug 2011 23:07:48 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QnymB-000EfN-Mq; Mon, 01 Aug 2011 23:07:47 +0300 Message-ID: <4E370793.8080809@FreeBSD.org> Date: Mon, 01 Aug 2011 23:07:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Jung-uk Kim References: <201107312128.29322.lobo@bsd.com.br> <201108011223.55772.jkim@FreeBSD.org> <4E36F88C.7050404@FreeBSD.org> <201108011548.03059.jkim@FreeBSD.org> In-Reply-To: <201108011548.03059.jkim@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:07:50 -0000 on 01/08/2011 22:48 Jung-uk Kim said the following: > amdtemp(4) attaches under PCI bus but its sibling on function 2 isn't > easy to address, i.e., hostbN. pci_find_bsf() should help with that. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 20:10:14 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 947A41065670; Mon, 1 Aug 2011 20:10:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B1F228FC12; Mon, 1 Aug 2011 20:10:13 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA03159; Mon, 01 Aug 2011 23:10:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QnyoW-000EfT-66; Mon, 01 Aug 2011 23:10:12 +0300 Message-ID: <4E370823.4000707@FreeBSD.org> Date: Mon, 01 Aug 2011 23:10:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Jung-uk Kim References: <201107312128.29322.lobo@bsd.com.br> <201108011223.55772.jkim@FreeBSD.org> <4E36F88C.7050404@FreeBSD.org> <201108011548.03059.jkim@FreeBSD.org> In-Reply-To: <201108011548.03059.jkim@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:10:14 -0000 on 01/08/2011 22:48 Jung-uk Kim said the following: > I have mixed feeling about this because I own a system with such > CPU/motherboard combo, too. I also believe it works well but errata > is errata. If vendor says we shouldn't use it, then we shouldn't. > In fact, I am just following Linux as an example here but I have no > problem with turning this into a warning message, either. Let's cut a deal :-) If we start using amdtemp for fan control, emergency system shutdown or similar, then we follow the strict path. Until then, while we use amdtemp to amuse users with numbers, let's just print a warning :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 21:06:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 91C12106566C; Mon, 1 Aug 2011 21:06:31 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 1 Aug 2011 17:06:08 -0400 User-Agent: KMail/1.6.2 References: <201107312128.29322.lobo@bsd.com.br> <201108011548.03059.jkim@FreeBSD.org> <4E370823.4000707@FreeBSD.org> In-Reply-To: <4E370823.4000707@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108011706.14163.jkim@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:06:32 -0000 On Monday 01 August 2011 04:10 pm, Andriy Gapon wrote: > on 01/08/2011 22:48 Jung-uk Kim said the following: > > I have mixed feeling about this because I own a system with such > > CPU/motherboard combo, too. I also believe it works well but > > errata is errata. If vendor says we shouldn't use it, then we > > shouldn't. In fact, I am just following Linux as an example here > > but I have no problem with turning this into a warning message, > > either. > > Let's cut a deal :-) > If we start using amdtemp for fan control, emergency system > shutdown or similar, then we follow the strict path. Until then, > while we use amdtemp to amuse users with numbers, let's just print > a warning :-) Okay, here is the new patch (not tested on the affected system yet): http://people.freebsd.org/~jkim/amdtemp2.diff Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 21:09:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 883F9106567F; Mon, 1 Aug 2011 21:09:11 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 1 Aug 2011 17:08:55 -0400 User-Agent: KMail/1.6.2 References: <201107312128.29322.lobo@bsd.com.br> <201108011548.03059.jkim@FreeBSD.org> <4E370793.8080809@FreeBSD.org> In-Reply-To: <4E370793.8080809@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108011708.58713.jkim@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:09:11 -0000 On Monday 01 August 2011 04:07 pm, Andriy Gapon wrote: > on 01/08/2011 22:48 Jung-uk Kim said the following: > > amdtemp(4) attaches under PCI bus but its sibling on function 2 > > isn't easy to address, i.e., hostbN. > > pci_find_bsf() should help with that. I thought about that but it seemed like an overkill because this driver is strictly MD anyway. :-) Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 22:21:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7914C10656D0; Mon, 1 Aug 2011 22:21:48 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2851F8FC16; Mon, 1 Aug 2011 22:21:47 +0000 (UTC) Received: by yxl31 with SMTP id 31so4403485yxl.13 for ; Mon, 01 Aug 2011 15:21:47 -0700 (PDT) Received: by 10.236.181.234 with SMTP id l70mr3790389yhm.335.1312237307307; Mon, 01 Aug 2011 15:21:47 -0700 (PDT) Received: from papi.localnet ([177.17.4.208]) by mx.google.com with ESMTPS id b24sm1338757yhm.53.2011.08.01.15.21.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 15:21:46 -0700 (PDT) From: Mario Lobo To: "Matthew D. Fuller" Date: Mon, 1 Aug 2011 19:21:38 -0300 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) References: <201107312128.29322.lobo@bsd.com.br> <20110801185230.GA81791@over-yonder.net> In-Reply-To: <20110801185230.GA81791@over-yonder.net> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201108011921.39245.lobo@bsd.com.br> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, FreeBSD Questions Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:21:48 -0000 On Monday 01 August 2011 15:52:30 Matthew D. Fuller wrote: > On Sun, Jul 31, 2011 at 09:28:29PM -0300 I heard the voice of > > Mario Lobo, and lo! it spake thus: > > Unfortunately this Mobo died and only found AM3 boards for which my > > phenom 955 doesn't fit. > > Not that it helps you now, but the 955 _is_ perfectly compatible with > AM3. It's only the initial 920 and 940 that were AM2-only. I was just following this: http://support.amd.com/us/kbarticles/Pages/CPU-6-socket-am2-plus-phenom-ii- compatibility-alert.aspx -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 23:47:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EFB1106566B for ; Mon, 1 Aug 2011 23:47:43 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B47D78FC14 for ; Mon, 1 Aug 2011 23:47:42 +0000 (UTC) Received: by wwe6 with SMTP id 6so6023088wwe.31 for ; Mon, 01 Aug 2011 16:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=F+TK/DTPuR9nbeLlp281fqfrZPNwrqhuWIr2sfZReCQ=; b=JYl4Oou+v9uf9OP37hZZJsVk7Z4bAI2S4lRvq6bQurl73NWsRKW+fyUcz/jayjQpGy BiERwBhCjcdEThhcdhuCkJ9/JBHy2WrbFLybHIBHc+rdaqz6L2Ka5pP93TQfL/HmwDRM ISkullf0yUGMpqMoJaqTkDwAcEXDreiuosrHM= Received: by 10.216.168.72 with SMTP id j50mr1156889wel.88.1312240784528; Mon, 01 Aug 2011 16:19:44 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk [87.194.105.247]) by mx.google.com with ESMTPS id n18sm4552952wbh.23.2011.08.01.16.19.42 (version=SSLv3 cipher=OTHER); Mon, 01 Aug 2011 16:19:43 -0700 (PDT) Date: Tue, 2 Aug 2011 00:19:40 +0100 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20110802001940.5ec25799@gumby.homeunix.com> In-Reply-To: <201108011921.39245.lobo@bsd.com.br> References: <201107312128.29322.lobo@bsd.com.br> <20110801185230.GA81791@over-yonder.net> <201108011921.39245.lobo@bsd.com.br> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 23:47:43 -0000 On Mon, 1 Aug 2011 19:21:38 -0300 Mario Lobo wrote: > On Monday 01 August 2011 15:52:30 Matthew D. Fuller wrote: > > On Sun, Jul 31, 2011 at 09:28:29PM -0300 I heard the voice of > > > > Mario Lobo, and lo! it spake thus: > > > Unfortunately this Mobo died and only found AM3 boards for which > > > my phenom 955 doesn't fit. > > > > Not that it helps you now, but the 955 _is_ perfectly compatible > > with AM3. It's only the initial 920 and 940 that were AM2-only. > > I was just following this: > > http://support.amd.com/us/kbarticles/Pages/CPU-6-socket-am2-plus-phenom-ii- > compatibility-alert.aspx It says "Although Socket AM3 processors can be used on Socket AM2+ motherboards, the opposite is not possible". I'm using a 955 in a M4A88T-M/USB3, which is minor variant of your AM3 board. My understanding is that the 955 is an AM3 processor. BTW in my case only the temperature is correct, but is only given for the first 2 cores. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 06:07:56 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA607106566B; Tue, 2 Aug 2011 06:07:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D63238FC13; Tue, 2 Aug 2011 06:07:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA10522; Tue, 02 Aug 2011 09:07:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qo88v-000HLY-15; Tue, 02 Aug 2011 09:07:53 +0300 Message-ID: <4E379438.2040701@FreeBSD.org> Date: Tue, 02 Aug 2011 09:07:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Jung-uk Kim References: <201107312128.29322.lobo@bsd.com.br> <201108011548.03059.jkim@FreeBSD.org> <4E370793.8080809@FreeBSD.org> <201108011708.58713.jkim@FreeBSD.org> In-Reply-To: <201108011708.58713.jkim@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Phenom II 975 BE shows 0 celsius X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:07:56 -0000 on 02/08/2011 00:08 Jung-uk Kim said the following: > On Monday 01 August 2011 04:07 pm, Andriy Gapon wrote: >> on 01/08/2011 22:48 Jung-uk Kim said the following: >>> amdtemp(4) attaches under PCI bus but its sibling on function 2 >>> isn't easy to address, i.e., hostbN. >> >> pci_find_bsf() should help with that. > > I thought about that but it seemed like an overkill because this > driver is strictly MD anyway. :-) It's just that pci_cfgregread() has very low level feel to it, nothing else... -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 20:43:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ABD01065716 for ; Tue, 2 Aug 2011 20:43:11 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 14F658FC16 for ; Tue, 2 Aug 2011 20:43:10 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p72Kh6mf022129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2011 06:43:08 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p72Kh6bT078883; Wed, 3 Aug 2011 06:43:06 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p72Kh5t1078882; Wed, 3 Aug 2011 06:43:05 +1000 (EST) (envelope-from peter) Date: Wed, 3 Aug 2011 06:43:05 +1000 From: Peter Jeremy To: "Christoph P.U. Kukulies" Message-ID: <20110802204304.GA78870@server.vk2pj.dyndns.org> References: <4E356498.40001@kukulies.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <4E356498.40001@kukulies.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: invalid argument in select() when peer socket is in FD_SET X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:43:11 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jul-31 16:20:08 +0200, "Christoph P.U. Kukulies" wrote: > if (array_of_fds[i]) { > nfds =3D max(nfds, array_of_fds[i]) + 1; I suspect you mean: nfds =3D max(nfds, array_of_fds[i] + 1); > FD_SET(array_of_fds[i], &readfds); > } --=20 Peter Jeremy --5vNYLRcllDrimb99 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk44YVgACgkQ/opHv/APuIeSSQCfaFbMJ00cnPB0zfRigo1pF9Sv aJMAn0F+4zy5BeQ+v0Umji1iCz0B/ony =HJUz -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 21:16:54 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7B31106566C for ; Tue, 2 Aug 2011 21:16:54 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 66EF98FC13 for ; Tue, 2 Aug 2011 21:16:54 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id EB7073593B0; Tue, 2 Aug 2011 23:16:52 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id E0FFF17431; Tue, 2 Aug 2011 23:16:52 +0200 (CEST) Date: Tue, 2 Aug 2011 23:16:52 +0200 From: Jilles Tjoelker To: Vlad Galu Message-ID: <20110802211652.GA28731@stack.nl> References: <7E99FCF5-66DF-422E-B2FE-28547AF916A7@dudu.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E99FCF5-66DF-422E-B2FE-28547AF916A7@dudu.ro> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org Subject: Re: eliminating a syscall on accept()+ioctl() combo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:16:54 -0000 On Mon, Aug 01, 2011 at 08:11:04AM +0200, Vlad Galu wrote: > On Jul 31, 2011, at 9:59 PM, Bernard van Gastel wrote: > > I want to reduce the number of syscalls for my networking > > application. The app handles incoming connections with the > > 'accept()' system call. Is there a way to specify to accept() that > > the newly created file descriptors should be non-blocking (FIONBIO)? > > This will avoid an ioctl() after the accept(). Thanks! > You can make your listening socket non-blocking. Newly created file > descriptors will inherit that property. However, that will require you > to select()/poll()/kqueue() for that descriptor as well, instead of > simply blocking in accept(). This is documented FreeBSD behaviour and common across BSDs, but is not portable. POSIX leaves it unspecified what the non-blocking state of the new socket is and in fact Linux always makes the new socket blocking (unless you request non-blocking using their new accept4() call). Because this portability issue can be very subtle, I suggest not blindly relying on it. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 21:45:17 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7CC0106564A for ; Tue, 2 Aug 2011 21:45:17 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6053A8FC15 for ; Tue, 2 Aug 2011 21:45:17 +0000 (UTC) Received: by fxe4 with SMTP id 4so322840fxe.13 for ; Tue, 02 Aug 2011 14:45:16 -0700 (PDT) Received: by 10.223.159.4 with SMTP id h4mr1666328fax.57.1312321516223; Tue, 02 Aug 2011 14:45:16 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id x20sm116126fah.2.2011.08.02.14.45.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 14:45:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Vlad Galu In-Reply-To: <20110802211652.GA28731@stack.nl> Date: Tue, 2 Aug 2011 23:45:11 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <7E99FCF5-66DF-422E-B2FE-28547AF916A7@dudu.ro> <20110802211652.GA28731@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1244.3) Cc: hackers@freebsd.org Subject: Re: eliminating a syscall on accept()+ioctl() combo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:45:17 -0000 On Aug 2, 2011, at 11:16 PM, Jilles Tjoelker wrote: > On Mon, Aug 01, 2011 at 08:11:04AM +0200, Vlad Galu wrote: >> On Jul 31, 2011, at 9:59 PM, Bernard van Gastel wrote: >>> I want to reduce the number of syscalls for my networking >>> application. The app handles incoming connections with the >>> 'accept()' system call. Is there a way to specify to accept() that >>> the newly created file descriptors should be non-blocking (FIONBIO)? >>> This will avoid an ioctl() after the accept(). Thanks! > >> You can make your listening socket non-blocking. Newly created file >> descriptors will inherit that property. However, that will require you >> to select()/poll()/kqueue() for that descriptor as well, instead of >> simply blocking in accept(). > > This is documented FreeBSD behaviour and common across BSDs, but is not > portable. POSIX leaves it unspecified what the non-blocking state of the > new socket is and in fact Linux always makes the new socket blocking > (unless you request non-blocking using their new accept4() call). > > Because this portability issue can be very subtle, I suggest not blindly > relying on it. Oh, ok. I wasn't aware. Thanks for the heads-up. Good, fast & cheap: pick any two. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 22:48:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DFB7106566B; Tue, 2 Aug 2011 22:48:26 +0000 (UTC) (envelope-from rmh.aybabtu@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 4E18A8FC16; Tue, 2 Aug 2011 22:48:26 +0000 (UTC) Received: by iyb11 with SMTP id 11so329745iyb.13 for ; Tue, 02 Aug 2011 15:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oUqlCCf0yOnwln41eg39D8ywAj5RwmDCkOhVsXvc524=; b=ER14aA8ZG1tHmOKrazcIzN+H65NKeJSM1vPJH3lEQ024ZFOf+/Xly+dHcS857bRsIe gV3oNTRk1COZ+s2rjL0KcOgYSOpbFC08yPif5/VfYbORCypnsZncyOPa25jXURztxHmo 4Naw018pmOG31HMgAmuZbFTnwnzKK4UfoeaFs= MIME-Version: 1.0 Received: by 10.42.146.133 with SMTP id j5mr4469601icv.180.1312325305508; Tue, 02 Aug 2011 15:48:25 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.218.8 with HTTP; Tue, 2 Aug 2011 15:48:25 -0700 (PDT) In-Reply-To: <20110731193017.GR17489@deviant.kiev.zoral.com.ua> References: <20110730173239.GA17489@deviant.kiev.zoral.com.ua> <20110731193017.GR17489@deviant.kiev.zoral.com.ua> Date: Wed, 3 Aug 2011 00:48:25 +0200 X-Google-Sender-Auth: D7883XdZdhl0CHEffIbwHf-87EU Message-ID: From: Robert Millan To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Ed Maste , bde@freebsd.org Subject: Re: kern/159281: [PATCH] Linux-like /proc/swaps for linprocfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:48:26 -0000 2011/7/31 Kostik Belousov : > Below is the hopefully final patch after Bruce Evans' comments incorporated. > If nobody speaks, I will send this to re tomorrow. I notice it's been committed already, and tested latest HEAD. It's working fine, thank you! -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 10:35:19 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 825B61065672 for ; Wed, 3 Aug 2011 10:35:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CAF548FC08 for ; Wed, 3 Aug 2011 10:35:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA09653; Wed, 03 Aug 2011 13:35:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QoYn4-000Kra-Ki; Wed, 03 Aug 2011 13:35:06 +0300 Message-ID: <4E392458.1060606@FreeBSD.org> Date: Wed, 03 Aug 2011 13:35:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: ambrosehuang ambrose , Fabian Keil , Yuri References: <20110722202811.17302hol2s3ar084@newwebmail.rawbw.com> <20110723135655.4479d190@fabiankeil.de> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: DTrace script asserts and kills the other process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:35:19 -0000 on 28/07/2011 07:10 ambrosehuang ambrose said the following: >> Yuri wrote: >> >>> I am trying to run this dtrace script: >>> >>> #!/usr/sbin/dtrace -s >>> pid123:libc::entry >>> { >>> self->timestmp[probefunc] = timestmp; >>> } >>> pid123:libc::return >>> /self->timestmp[probefunc] != 0/ >>> { >>> @function_duration[probefunc] = sum(timestmp - >>> self->timestmp[probefunc]); timestmp[probefunc] = 0; >>> } >>> >>> which I got from here: >>> http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html >>> replacing 123 with the pid of some running process. >>> >>> Result: dtrace utility asserts: >>> Assertion failed: (dpr != NULL), file >>> >> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, >>> line 751. >>> Abort trap: 6 >>> >>> Also the target process is killed too: >>> Killed: 9 >>> >>> 8.2-STABLE amd64 >> >> This is a known issue. You may be able to work around it by >> letting dtrace start the traced process. >> >> There's already a PR about it: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431 >> but the limitation isn't mentioned in the wiki: >> http://wiki.freebsd.org/DTrace/userland FYI and benefit: I've committed what should be a fix for this issue, r224632. >> It's not clear to me if this has worked in the past or if it >> works for other architectures (the reporter and I are both using >> amd64, too). >> >> Fabian >> > I came across the same problem in 8.2-stable , it seemed the problem had > been there since 8.2-release with userland dtrace integrated. I followed the > PR185431 and found when dtrace started, it indeed attached to the traced > process( dpr != NULL), but the traced process died soon, and > according to the PR, this is "error in error" since the dtrace came accross > error in dfatal > .................................................................................................................................................... > #3 0x0000000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40, > remove=0) > at > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751 > #4 0x0000000808d8af92 in dt_proc_destroy (dtp=0x80b841000, P=0x80d7ffb40) > at > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763 > #5 0x0000000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000) > at > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162 > #6 0x0000000808daa4b5 in dtrace_close (dtp=0x80b841000) > at > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554 > #7 0x0000000000402775 in dfatal (fmt=0x408572 "no probes %s\n") > at > /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236 > #8 0x0000000000406b2c in main (argc=3, argv=0x7ffffffed9c0) > at > /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825 > ..................................................................................................................................................... > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 10:56:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83A7B1065670 for ; Wed, 3 Aug 2011 10:56:35 +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 3BF778FC17 for ; Wed, 3 Aug 2011 10:56:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QoZ7o-000Pe8-BC; Wed, 03 Aug 2011 13:56:32 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Aug 2011 13:56:32 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-emulation@freebsd.org Subject: matlab on Linux, any success stories? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:56:35 -0000 Im trying to install matlab R2010B-Mac-Linux under freebsd-8.2-STABLE, having installed linux_base-f10-10_4 but keep getting: rnd# /compat/linux/bin/sh ./install Preparing installation files ... Exception in thread "main" java.lang.UnsatisfiedLinkError: /dist/local/amd64.FreeBSD_8.2-wip/compat/linux/tmp/mathworks_54440/java/jre/gln x86/jre/lib/i386/xawt/libmawt.so: libXext.so.6: ca not open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) any known magic incantations? thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 12:33:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418B7106566C for ; Wed, 3 Aug 2011 12:33:54 +0000 (UTC) (envelope-from lichray@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 042E58FC18 for ; Wed, 3 Aug 2011 12:33:53 +0000 (UTC) Received: by iyb11 with SMTP id 11so1208663iyb.13 for ; Wed, 03 Aug 2011 05:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GRNZsMLR6+2kvUgLDNKDOKAc68NHZlbu3QC1mkc5Xbg=; b=MT85tBTMQ3MBJlJoA27alW4SJh53hK9zC1rerEC1RqpZnHjidweOBVRVnbtoBJuR6S vvm+v7mahNbC7AxK0JfaWn0t7E0y3Jwz1bLcovyTbbkXqOLzZnPE5oPevXdJA7fW3ivd cOmXN18+UWPnnMEPZJwYKokv/NawCWIja4dAc= MIME-Version: 1.0 Received: by 10.231.41.23 with SMTP id m23mr4902006ibe.183.1312374833503; Wed, 03 Aug 2011 05:33:53 -0700 (PDT) Received: by 10.231.33.205 with HTTP; Wed, 3 Aug 2011 05:33:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Aug 2011 07:33:53 -0500 Message-ID: From: Zhihao Yuan To: Daniel Braniss Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: matlab on Linux, any success stories? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:33:54 -0000 On Wed, Aug 3, 2011 at 5:56 AM, Daniel Braniss wrote: > Im trying to install matlab R2010B-Mac-Linux under freebsd-8.2-STABLE, > having installed linux_base-f10-10_4 but keep getting: > > rnd# /compat/linux/bin/sh =C2=A0./install > Preparing installation files ... > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /dist/local/amd64.FreeBSD_8.2-wip/compat/linux/tmp/mathworks_54440/java/j= re/gln > x86/jre/lib/i386/xawt/libmawt.so: libXext.so.6: ca not open shared object > file: No such file or directory > =C2=A0 =C2=A0 =C2=A0 =C2=A0at java.lang.ClassLoader$NativeLibrary.load(Na= tive Method) > You need linux-f10-xorg-libs at least. And, if you need 3D acceleration in matlab, linux-f10-dri (and linux-enabled nvidia driver if you are a nvidia user) are required. > any known magic incantations? > > thanks, > =C2=A0 =C2=A0 =C2=A0 =C2=A0danny > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 13:11:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0844D106564A for ; Wed, 3 Aug 2011 13:11:41 +0000 (UTC) (envelope-from reks@iiap.res.in) Received: from smtp.iiap.res.in (iiap.res.in [124.30.128.133]) by mx1.freebsd.org (Postfix) with ESMTP id 6DABA8FC08 for ; Wed, 3 Aug 2011 13:11:39 +0000 (UTC) X-AuditID: c0a8013d-b7c16ae0000006e4-88-4e39a7ecfdff Received: from mail.iiap.res.in ( [192.168.1.223]) by smtp.iiap.res.in (Symantec Brightmail Gateway) with SMTP id 23.F1.01764.CE7A93E4; Thu, 4 Aug 2011 01:26:28 +0530 (IST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.iiap.res.in (Postfix) with ESMTP id E634E4B597 for ; Wed, 3 Aug 2011 18:26:35 +0530 (IST) X-Virus-Scanned: amavisd-new at iiap.res.in Received: from mail.iiap.res.in ([127.0.0.1]) by localhost (iiap.res.in [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk7rpo6ki2XI for ; Wed, 3 Aug 2011 18:26:34 +0530 (IST) Received: from kiwi.home.net (unknown [180.149.48.210]) by mail.iiap.res.in (Postfix) with ESMTP id 39A5D4B500 for ; Wed, 3 Aug 2011 18:26:34 +0530 (IST) From: Rekhesh Mohan Organization: Indian Institute of Astrophysics To: freebsd-hackers@freebsd.org Date: Wed, 3 Aug 2011 18:26:13 +0530 User-Agent: KMail/1.13.7 (Linux/2.6.35.10-74.fc14.x86_64; KDE/4.6.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201108031826.13208.reks@iiap.res.in> X-Brightmail-Tracker: AAAAAA== Subject: freeBSD8.2: getgrgid() works only for wheel group. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:11:41 -0000 Dear Hackers, I'm trying to install mailman on a freeBSD 8.2 box. Mailman allows only the apache-www group to run its CGI scripts and only the mail group can execute some of the mailing list related functionalities. Mailman is using getgrgid() to check the group name. This is failing on me. It appears that only the wheel group members are allowed to use getgrgid() on my machine. getgrgid() returns (null) for others. I was wondering if anyone else has faced this situation. Let me know.. Thanks in advance! --R From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 18:57:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BB651065688 for ; Wed, 3 Aug 2011 18:57:57 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB848FC19 for ; Wed, 3 Aug 2011 18:57:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=dE/ceyja514liMRgQbbbQAsEzuFW9rbM6sHOS43zzO8=; b=lC5Z/pmy5jsJLzEkm3v/evrQA3vyfVOukuVLvqsBwmwuqVECT2KLtunWsNvNaeVMKyfKOuypZlX4oVa1UBVvR8HbuNilOJQUlFZKdscJet6f1dYNCjQjPCq6HMEQdZGxpoISPOfKs6UGfBvfXGnx6E2BoHw9dPQcF4gOok/NryXAcqyMcFPx5wOMtFiSBtCHJVuUudRwJmmudAZCCTYQHi95h0ncY+qIISNX8Oo+3quXisRmpy/2tC6tvgzDwBXXKqjop02124HXBjY2IRuA//bqaoimAeFJjKDvi7vvNO0nvS3Hlm5YMv9hhmT+RW4+mJUB6ApxXxxPqFeteA7/Ew==; Received: from phoenix.codelabs.ru (ppp91-77-180-171.pppoe.mtu-net.ru [91.77.180.171]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Qogdf-000MGH-Eu; Wed, 03 Aug 2011 22:57:55 +0400 Date: Wed, 3 Aug 2011 22:57:53 +0400 From: Eygene Ryabinkin To: Rekhesh Mohan Message-ID: <6J1Itwyabc8Do31LEfVLpMwSCVA@yLRruTFns/Hy+kDinNNIWtUAGVU> References: <201108031826.13208.reks@iiap.res.in> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: <201108031826.13208.reks@iiap.res.in> Sender: rea@codelabs.ru Cc: freebsd-hackers@freebsd.org Subject: Re: freeBSD8.2: getgrgid() works only for wheel group. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:57:57 -0000 --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Rekhesh, good day. Wed, Aug 03, 2011 at 06:26:13PM +0530, Rekhesh Mohan wrote: > I'm trying to install mailman on a freeBSD 8.2 box. Mailman allows only= =20 > the apache-www group to run its CGI scripts and only the mail group can= =20 > execute some of the mailing list related functionalities. Mailman is=20 > using getgrgid() to check the group name. This is failing on me. >=20 > It appears that only the wheel group members are allowed to use=20 > getgrgid() on my machine. getgrgid() returns (null) for others. I was=20 > wondering if anyone else has faced this situation.=20 What's the output from 'ls -l /etc/group; ls -ld /etc'? --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF0EAREIAAYFAk45mjAACgkQFq+eroFS7PveNwD4+XC6emq52551DxQbgkorkjjS LDwXEHZVqcMZEbcl9gD/XOJd68t/PJmtUpbWcWZeSE/obcPl/9DFeP0yFaajHhk= =QcR0 -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 02:13:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 543C51065670 for ; Thu, 4 Aug 2011 02:13:39 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id F20E18FC14 for ; Thu, 4 Aug 2011 02:13:38 +0000 (UTC) Received: by qwc9 with SMTP id 9so1082191qwc.13 for ; Wed, 03 Aug 2011 19:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fVnBs/QeTGknD9pFox4PivbeDTrKkLhY5szQkGcUGPo=; b=hIdKb22uRAN5KhrU3JQjdlBRdl3qFmu4MHsR5THzCRCWqiRMUoDqiIPRfQtS90YkZc 2DDdJ8s7ULYFbnRsZh3NOi/lh0QnBQzAjJv7P01L2urJkQooSv9h+t6vgTgbRLJYV9V3 MtLJtARbUZOnCxqT9f4uSBuCrN8U8MCscnd70= MIME-Version: 1.0 Received: by 10.229.66.219 with SMTP id o27mr156602qci.26.1312424016272; Wed, 03 Aug 2011 19:13:36 -0700 (PDT) Received: by 10.229.185.75 with HTTP; Wed, 3 Aug 2011 19:13:36 -0700 (PDT) In-Reply-To: <4E392458.1060606@FreeBSD.org> References: <20110722202811.17302hol2s3ar084@newwebmail.rawbw.com> <20110723135655.4479d190@fabiankeil.de> <4E392458.1060606@FreeBSD.org> Date: Thu, 4 Aug 2011 10:13:36 +0800 Message-ID: From: ambrosehuang ambrose To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Yuri , Fabian Keil , freebsd-hackers@freebsd.org Subject: Re: DTrace script asserts and kills the other process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 02:13:39 -0000 2011/8/3 Andriy Gapon > on 28/07/2011 07:10 ambrosehuang ambrose said the following: > >> Yuri wrote: > >> > >>> I am trying to run this dtrace script: > >>> > >>> #!/usr/sbin/dtrace -s > >>> pid123:libc::entry > >>> { > >>> self->timestmp[probefunc] = timestmp; > >>> } > >>> pid123:libc::return > >>> /self->timestmp[probefunc] != 0/ > >>> { > >>> @function_duration[probefunc] = sum(timestmp - > >>> self->timestmp[probefunc]); timestmp[probefunc] = 0; > >>> } > >>> > >>> which I got from here: > >>> http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html > >>> replacing 123 with the pid of some running process. > >>> > >>> Result: dtrace utility asserts: > >>> Assertion failed: (dpr != NULL), file > >>> > >> > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, > >>> line 751. > >>> Abort trap: 6 > >>> > >>> Also the target process is killed too: > >>> Killed: 9 > >>> > >>> 8.2-STABLE amd64 > >> > >> This is a known issue. You may be able to work around it by > >> letting dtrace start the traced process. > >> > >> There's already a PR about it: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431 > >> but the limitation isn't mentioned in the wiki: > >> http://wiki.freebsd.org/DTrace/userland > > FYI and benefit: I've committed what should be a fix for this issue, > r224632. > > >> It's not clear to me if this has worked in the past or if it > >> works for other architectures (the reporter and I are both using > >> amd64, too). > >> > >> Fabian > >> > > I came across the same problem in 8.2-stable , it seemed the problem had > > been there since 8.2-release with userland dtrace integrated. I followed > the > > PR185431 and found when dtrace started, it indeed attached to the > traced > > process( dpr != NULL), but the traced process died soon, and > > according to the PR, this is "error in error" since the dtrace came > accross > > error in dfatal > > > .................................................................................................................................................... > > #3 0x0000000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40, > > remove=0) > > at > > > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751 > > #4 0x0000000808d8af92 in dt_proc_destroy (dtp=0x80b841000, P=0x80d7ffb40) > > at > > > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763 > > #5 0x0000000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000) > > at > > > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162 > > #6 0x0000000808daa4b5 in dtrace_close (dtp=0x80b841000) > > at > > > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554 > > #7 0x0000000000402775 in dfatal (fmt=0x408572 "no probes %s\n") > > at > > > /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236 > > #8 0x0000000000406b2c in main (argc=3, argv=0x7ffffffed9c0) > > at > > > /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825 > > > ..................................................................................................................................................... > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > > I just saw your commit, I will verify it on 8-stable soon, thank you! > -- > Andriy Gapon > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 10:33:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 812D71065672; Thu, 4 Aug 2011 10:33:46 +0000 (UTC) (envelope-from reks@iiap.res.in) Received: from smtp.iiap.res.in (iiap.res.in [124.30.128.133]) by mx1.freebsd.org (Postfix) with ESMTP id A8F7F8FC27; Thu, 4 Aug 2011 10:33:44 +0000 (UTC) X-AuditID: c0a8013d-b7c16ae0000006e4-78-4e3ad7f07445 Received: from mail.iiap.res.in ( [192.168.1.223]) by smtp.iiap.res.in (Symantec Brightmail Gateway) with SMTP id E0.C3.01764.0F7DA3E4; Thu, 4 Aug 2011 23:03:36 +0530 (IST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.iiap.res.in (Postfix) with ESMTP id A08C34B615; Thu, 4 Aug 2011 16:03:42 +0530 (IST) X-Virus-Scanned: amavisd-new at iiap.res.in Received: from mail.iiap.res.in ([127.0.0.1]) by localhost (iiap.res.in [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfsvR+FX9rYW; Thu, 4 Aug 2011 16:03:40 +0530 (IST) Received: from voodoo.iiap.res.in (ws92.iiap.res.in [192.168.1.92]) by mail.iiap.res.in (Postfix) with ESMTP id 69F954B53A; Thu, 4 Aug 2011 16:03:40 +0530 (IST) From: Rekhesh Mohan Organization: Indian Institute of Astrophysics To: Eygene Ryabinkin Date: Thu, 4 Aug 2011 16:03:39 +0530 User-Agent: KMail/1.13.7 (Linux/2.6.35.13-92.fc14.x86_64; KDE/4.6.4; x86_64; ; ) References: <201108031826.13208.reks@iiap.res.in> <6J1Itwyabc8Do31LEfVLpMwSCVA@yLRruTFns/Hy+kDinNNIWtUAGVU> In-Reply-To: <6J1Itwyabc8Do31LEfVLpMwSCVA@yLRruTFns/Hy+kDinNNIWtUAGVU> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201108041603.39841.reks@iiap.res.in> X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org Subject: Re: freeBSD8.2: getgrgid() works only for wheel group. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:33:46 -0000 On 04/08/2011 Eygene wrote > Rekhesh, good day. > > Wed, Aug 03, 2011 at 06:26:13PM +0530, Rekhesh Mohan wrote: > > I'm trying to install mailman on a freeBSD 8.2 box. Mailman allows > > only the apache-www group to run its CGI scripts and only the mail > > group can execute some of the mailing list related > > functionalities. Mailman is using getgrgid() to check the group > > name. This is failing on me. > > > > It appears that only the wheel group members are allowed to use > > getgrgid() on my machine. getgrgid() returns (null) for others. I > > was wondering if anyone else has faced this situation. > > What's the output from 'ls -l /etc/group; ls -ld /etc'? Eygene! You are the man :) /etc had 750 permissions. Thanks a lot. I was probably too busy looking inside /etc and never thought of looking up above the directory. Everything is working now. Thanks again.. --R From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 08:20:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70989106566B for ; Thu, 4 Aug 2011 08:20:50 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9938FC0C for ; Thu, 4 Aug 2011 08:20:49 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id D4FB56A661F for ; Thu, 4 Aug 2011 10:01:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id tS8AR3S5qlqa for ; Thu, 4 Aug 2011 10:01:31 +0200 (CEST) Received: from 0x20.net (0x20.net [217.69.76.212]) (Authenticated sender: lala) by mail.0x20.net (Postfix) with ESMTPA id 766846A61CF for ; Thu, 4 Aug 2011 10:01:31 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 04 Aug 2011 10:01:31 +0200 From: Lars Engels To: In-Reply-To: <2c9d3cc8a0b85313f55f53ca573af81a.squirrel@zugang.kibab.com> References: <4E167C94.70300@kibab.com> <4E1685D8.403@gmail.com> <2c9d3cc8a0b85313f55f53ca573af81a.squirrel@zugang.kibab.com> Message-ID: <769b9c9ca386e2a2b43c27a8fb5e1ff7@mail.0x20.net> X-Sender: lars.engels@0x20.net User-Agent: Roundcube Webmail/0.5.3 X-Mailman-Approved-At: Thu, 04 Aug 2011 10:52:11 +0000 Subject: Re: Capsicum project: Ideas needed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 08:20:50 -0000 I just stumbled upon this rather outdated thread... On Fri, 8 Jul 2011 15:09:52 +0400, Ilya Bakulin wrote: [...] >> wget >> curl >> links/lynx > This is Ports software, we may try to modify it and even send patches > to > upstream, or maintain our local patches. I wanted to focus on base > system > components during GSoC, but it doesn't hurt to try to capsicumize > these > tools either. fetch(1) is similar to wget and curl and is part of the base system, so would this be a candidate? From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 15:05:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B4CF1065672 for ; Thu, 4 Aug 2011 15:05:43 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E412C8FC0A for ; Thu, 4 Aug 2011 15:05:42 +0000 (UTC) Received: by ywm39 with SMTP id 39so1398289ywm.13 for ; Thu, 04 Aug 2011 08:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=/IfbIXE8Oijo+/ko9puUcyTLGtr0t0dztw+Gd/fW38Y=; b=RVsPFJ2VD6abbSAzTTvlah0bLs1Es7V4msUor1t8DQluuPXxptlq8d1rGh/DR3faiH m8fu89nIn2VKUjPsL8j7xggKvI8RHxlq33KyXVGIWwXDiAwJLwitMk+xm/ty2JN7/OZB wdRzxvbbyBWNjfbDJyXqwbcOlGmRcPdmgrVug= MIME-Version: 1.0 Received: by 10.42.161.1 with SMTP id r1mr823693icx.448.1312470341847; Thu, 04 Aug 2011 08:05:41 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.178.73 with HTTP; Thu, 4 Aug 2011 08:05:41 -0700 (PDT) Date: Thu, 4 Aug 2011 17:05:41 +0200 X-Google-Sender-Auth: ecANf_dJROXC98w-s4QgmNFBl2k Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: files that need as a prerequisite X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:05:43 -0000 Can't they just #include ? Or am I missing something? I'll be happy to send a patch if that's an acceptable solution. sys/sys/linker_set.h:#error this file needs sys/cdefs.h as a prerequisite sys/sys/syslimits.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/in_cksum.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/profile.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/ieeefp.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/cpufunc.h:#error this file needs sys/cdefs.h as a prerequisite sys/arm/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/in_cksum.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/ieeefp.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/profile.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/cpufunc.h:#error this file needs sys/cdefs.h as a prerequisite sys/ia64/include/cpufunc.h:#error this file needs sys/cdefs.h as a prerequisite sys/ia64/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/mips/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/mips/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/powerpc/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/powerpc/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/powerpc/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/sparc64/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/sparc64/include/profile.h:#error this file needs sys/cdefs.h as a prerequisite sys/sparc64/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 16:23:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49410106564A for ; Thu, 4 Aug 2011 16:23:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 076A68FC0C for ; Thu, 4 Aug 2011 16:23:15 +0000 (UTC) Received: by vws18 with SMTP id 18so2047018vws.13 for ; Thu, 04 Aug 2011 09:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=85Yoxptln/DXCUzc1zTVVqNAX0Gvms82wzNS7/9aK30=; b=YkJ2uQ+8TzXMu+7KZCIQa+sX2uYsZvhKqJDJg2wvIpjrtiI0JzAsvBvoBO0sdiHbIQ CSZVHAjQA/J43sfOvMfY0QyQD84nj7rpqkt9VEpgY4sFC+1rWEx13lblFTPkiy7pZcJz 2aBLQ9UkcHAGwyHZji/rfCQ4QG2LE0mCHS/Tg= MIME-Version: 1.0 Received: by 10.52.74.166 with SMTP id u6mr1093787vdv.252.1312474995250; Thu, 04 Aug 2011 09:23:15 -0700 (PDT) Received: by 10.220.172.18 with HTTP; Thu, 4 Aug 2011 09:23:15 -0700 (PDT) Date: Thu, 4 Aug 2011 09:23:15 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: module_register_init fails, but driver is still loaded? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:23:16 -0000 Hi hackers, I noticed that if anything fails while initializing a driver, the driver stays attached to the kernel as a module instead of being kicked when all references to the driver go to 0. Is this desired behavior (it doesn't seem like it, but I can see potential pros and cons of kicking the driver out of the kernel immediately when a failure state occurs)? I've seen this on 7.2 ~ 9-CURRENT. Example sourcecode and invocation attached below. Thanks! -Garrett /* bad_module.c */ #include #include #include #define MODULE_NAME "bad_module" static int load(module_t m, int what, void *arg) { return (EINVAL); } static moduledata_t bad_module_mod = { MODULE_NAME, &load, NULL, }; DECLARE_MODULE(bad_module, bad_module_mod, SI_SUB_KLD, SI_ORDER_ANY); MODULE_VERSION(bad_module, 1); /* Makefile */ KMOD= bad_module SRCS= bad_module.c .include $ sudo kldload ./bad_driver.ko $ dmesg | tail -n 1 module_register_init: MOD_LOAD (bad_module, 0xffffffff80a53000, 0) error 22 $ kldstat -v | grep bad_driver 5 1 0xffffffff80a53000 de bad_driver.ko $ sudo kldunload ./bad_driver.ko $ kldstat -v | grep bad_driver $ From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 16:41:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EDD8106564A; Thu, 4 Aug 2011 16:41:40 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D8E748FC0A; Thu, 4 Aug 2011 16:41:39 +0000 (UTC) Received: by qwc9 with SMTP id 9so1515878qwc.13 for ; Thu, 04 Aug 2011 09:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LpTviYBwZyXA4iHfdGIytd10mLwTvhbiwHj+k+rPG/g=; b=uWsrMbUsSYrHbGC3uJPesVE9CKTw1+ZsFftAiJouQDGRcA4yilaztufcnsC7t/8cJX 5jqbeHqz984WrAtD1Q3SF2/61IBOCKIb69bttyqksNWCt/Eh48hXFazshbonb5AdfPTH yiL2XIwjby8NFI+MeCe6RRurWZOQi3XSCo/WU= MIME-Version: 1.0 Received: by 10.224.173.207 with SMTP id q15mr702996qaz.278.1312476098390; Thu, 04 Aug 2011 09:41:38 -0700 (PDT) Received: by 10.229.185.75 with HTTP; Thu, 4 Aug 2011 09:41:38 -0700 (PDT) In-Reply-To: References: <20110722202811.17302hol2s3ar084@newwebmail.rawbw.com> <20110723135655.4479d190@fabiankeil.de> <4E392458.1060606@FreeBSD.org> Date: Fri, 5 Aug 2011 00:41:38 +0800 Message-ID: From: ambrosehuang ambrose To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Yuri , Fabian Keil , freebsd-hackers@freebsd.org Subject: Re: DTrace script asserts and kills the other process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:41:40 -0000 2011/8/4 ambrosehuang ambrose > > > 2011/8/3 Andriy Gapon > >> on 28/07/2011 07:10 ambrosehuang ambrose said the following: >> >> Yuri wrote: >> >> >> >>> I am trying to run this dtrace script: >> >>> >> >>> #!/usr/sbin/dtrace -s >> >>> pid123:libc::entry >> >>> { >> >>> self->timestmp[probefunc] = timestmp; >> >>> } >> >>> pid123:libc::return >> >>> /self->timestmp[probefunc] != 0/ >> >>> { >> >>> @function_duration[probefunc] = sum(timestmp - >> >>> self->timestmp[probefunc]); timestmp[probefunc] = 0; >> >>> } >> >>> >> >>> which I got from here: >> >>> http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html >> >>> replacing 123 with the pid of some running process. >> >>> >> >>> Result: dtrace utility asserts: >> >>> Assertion failed: (dpr != NULL), file >> >>> >> >> >> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, >> >>> line 751. >> >>> Abort trap: 6 >> >>> >> >>> Also the target process is killed too: >> >>> Killed: 9 >> >>> >> >>> 8.2-STABLE amd64 >> >> >> >> This is a known issue. You may be able to work around it by >> >> letting dtrace start the traced process. >> >> >> >> There's already a PR about it: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431 >> >> but the limitation isn't mentioned in the wiki: >> >> http://wiki.freebsd.org/DTrace/userland >> >> FYI and benefit: I've committed what should be a fix for this issue, >> r224632. >> >> >> It's not clear to me if this has worked in the past or if it >> >> works for other architectures (the reporter and I are both using >> >> amd64, too). >> >> >> >> Fabian >> >> >> > I came across the same problem in 8.2-stable , it seemed the problem had >> > been there since 8.2-release with userland dtrace integrated. I followed >> the >> > PR185431 and found when dtrace started, it indeed attached to the >> traced >> > process( dpr != NULL), but the traced process died soon, and >> > according to the PR, this is "error in error" since the dtrace came >> accross >> > error in dfatal >> > >> .................................................................................................................................................... >> > #3 0x0000000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40, >> > remove=0) >> > at >> > >> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751 >> > #4 0x0000000808d8af92 in dt_proc_destroy (dtp=0x80b841000, >> P=0x80d7ffb40) >> > at >> > >> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763 >> > #5 0x0000000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000) >> > at >> > >> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162 >> > #6 0x0000000808daa4b5 in dtrace_close (dtp=0x80b841000) >> > at >> > >> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554 >> > #7 0x0000000000402775 in dfatal (fmt=0x408572 "no probes %s\n") >> > at >> > >> /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236 >> > #8 0x0000000000406b2c in main (argc=3, argv=0x7ffffffed9c0) >> > at >> > >> /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825 >> > >> ..................................................................................................................................................... >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> I just saw your commit, I will verify it on 8-stable soon, thank you! >> > -- >> Andriy Gapon >> > I test your commit on 8-stable, here is my commit: commit 84f49c7ffa130ec4bcd7fb0a619b36ab615dfeb4 Author: mm Date: Thu Aug 4 10:37:12 2011 +0000 this is the my result: [root@lateaxfreebsd dtrace]# dtrace -n 'pid$target:libc::entry' -p 39699 libc.so.7: invalid probe specifier pid$target:libc::entry: probe description pid39699:libc::entry User defined signal 1: 30 [1]+ Hangup: 1 ../test I also test the example from userland/dtrace in wiki, it failed with same result, it seems the pid provider has something wrong with libc when probing; [root@lateaxfreebsd dtrace]# dtrace -n 'pid$target:::entry' -p 40346 test: description 'pid$target:::entry' matched 2 probes ^C success [root@lateaxfreebsd dtrace]# dtrace -ln 'pid$target:::entry' -p 40346 ID PROVIDER MODULE FUNCTION NAME 33913 pid40346 test _start entry 33914 pid40346 test main entry User defined signal 1: 30 [1]+ Hangup: 1 ../test Anyway, there is no core dump. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 17:19:39 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27B90106564A; Thu, 4 Aug 2011 17:19:39 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id D594D8FC13; Thu, 4 Aug 2011 17:19:36 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 70792D4815F; Thu, 4 Aug 2011 19:19:30 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id D854033DF5; Thu, 4 Aug 2011 17:19:28 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id C8392A11B4; Thu, 4 Aug 2011 17:19:28 +0000 (UTC) Date: Thu, 4 Aug 2011 19:19:28 +0200 From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Message-ID: <20110804171928.GB96031@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20110219185043.GA6573@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jhb@FreeBSD.org Subject: [RFC] stdbuf: Force stdio's streams initial buffering mode (patch) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:19:39 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Feb 19, 2011 at 07:50:43PM +0100, Jeremie Le Hen wrote: > I've been annoyed multiple time when running a command such like > iostat -x 1 | grep -v ad10 | cat -n > > The problem stems from two factors: > - grep's stdio sees that its stdout is not a terminal, so stdout is > full buffered and not line-buffered; > - iostat produces output too slowly so the aforementioned buffer takes > numerous seconds to be filled and flushed to the last command. > > This problems is not specific to FreeBSD, it is actually a consequence > of POSIX specification. I've checked this on Solaris and Linux. > > I've attached a small patch for stdio, so if the environment variable > STDIO_IOLBF is set, the output streams will be line-oriented by default. > iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n I improved the whole picture. Now there is a shared library libstdbuf.so which can be loaded with LD_PRELOAD and configured through a environment variables. It is able to initial control buffering for stdin, stdout and stderr (no buffering, line buffering, block buffering). There is also an utility named stdbuf(1) which can be used to run a command with the appropriate environment variables. Those are named after a similar tool in recent versions of GNU coreutils; of course, I also borrowed the interface for POLA. Here is how to use it (example taken from the manpage): vmstat 1 | stdbuf -o L awk '$2 > 1 || $3 > 1' | cat -n I think that using a preloaded shared library is better performance-wise because libc doesn't bother looking up configuration variables in the environment upon each execve(2), especially for something which is to be rarely used. Manpages for both stdbuf(1) and libstdbuf(3) are provided. There is surely room for improvement, so feel free to propose corrections to them. The patch can be applied as-is I think, although I've developped it against an old -CURRENT source tree (about 6 months ago). I'm looking for some feedback and review and hopefully this feature will be committed for FreeBSD 9.0-RELEASE. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche --XsQoSWH+UP9D9v3l Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="stdbuf.diff" diff -urNp src.HEAD_20111506/lib/libc/stdio/setbuf.3 src/lib/libc/stdio/setbuf.3 --- src.HEAD_20111506/lib/libc/stdio/setbuf.3 2007-01-09 01:28:07.000000000 +0100 +++ src/lib/libc/stdio/setbuf.3 2011-08-04 19:00:49.000000000 +0200 @@ -30,7 +30,7 @@ .\" SUCH DAMAGE. .\" .\" @(#)setbuf.3 8.1 (Berkeley) 6/4/93 -.\" $FreeBSD: src/lib/libc/stdio/setbuf.3,v 1.17 2007/01/09 00:28:07 imp Exp $ +.\" $FreeBSD: src/lib/libc/stdio/setbuf.3,v 1.17.10.1 2009/08/03 08:13:06 kensmith Exp $ .\" .Dd June 4, 1993 .Dt SETBUF 3 @@ -83,6 +83,9 @@ normally does) it is line buffered. The standard error stream .Dv stderr is always unbuffered. +Note that these defaults maybe be altered using the +.Xr stdbuf 1 +utility. .Pp The .Fn setvbuf @@ -177,6 +180,7 @@ function returns what the equivalent .Fn setvbuf would have returned. .Sh SEE ALSO +.Xr stdbuf 1 , .Xr fclose 3 , .Xr fopen 3 , .Xr fread 3 , diff -urNp src.HEAD_20111506/lib/libstdbuf/Makefile src/lib/libstdbuf/Makefile --- src.HEAD_20111506/lib/libstdbuf/Makefile 1970-01-01 01:00:00.000000000 +0100 +++ src/lib/libstdbuf/Makefile 2011-08-04 18:49:59.000000000 +0200 @@ -0,0 +1,15 @@ +# $FreeBSD: src/lib/libftpio/Makefile,v 1.17.2.1 2009/08/03 08:13:06 kensmith Exp $ + +.include + +LIB= stdbuf +SRCS= stdbuf.c +SHLIB_MAJOR= 1 +MAN= libstdbuf.3 + +CFLAGS+= -I${.CURDIR} +LDADD= -lutil + +WARNS?= 6 + +.include diff -urNp src.HEAD_20111506/lib/libstdbuf/libstdbuf.3 src/lib/libstdbuf/libstdbuf.3 --- src.HEAD_20111506/lib/libstdbuf/libstdbuf.3 1970-01-01 01:00:00.000000000 +0100 +++ src/lib/libstdbuf/libstdbuf.3 2011-08-04 18:47:04.000000000 +0200 @@ -0,0 +1,111 @@ +.\" Copyright (c) 2011 Jeremie Le Hen +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``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 AUTHOR 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. +.\" +.\" $FreeBSD$ +.\" +.Dd August 4, 2011 +.Dt LIBSTDBUF 3 +.Os +.Sh NAME +.Nm libstdbuf +.Nd preloaded library to change standard streams initial buffering +.Sh DESCRIPTION +The +.Nm +library is meant to be preloaded with the +.Ev LD_PRELOAD +environment variable to as to change the initial buffering +of standard input, standard output and standard error streams. +.Pp +Although you may load and configure this library manually, +an utility, +.Xr stdbuf 1 , +can be used to run a command with the appropriate environment variables. +.Sh ENVIRONMENT +Each stream can be configured indepentently through the following +environment variables (values are defined below): +.Bl -tag -width size -offset indent +.It Ev STDBUF_0 +Initial buffering definition for the standard input stream +.It Ev STDBUF_1 +Initial buffering definition for the standard output stream +.It Ev STDBUF_2 +Initial buffering definition for the standard error stream +.It Ev _STDBUF_I +GNU-compatible variable for +.Ev STDBUF_0 +.It Ev _STDBUF_O +GNU-compatible variable equivalent to +.Ev STDBUF_1 +.It Ev _STDBUF_E +GNU-compatible variable equivalent to +.Ev STDBUF_2 +.El +.Pp +Each variable may take one of the following values: +.Bl -tag -width size -offset indent +.It Qq 0 +unbuffered +.It Qq L +line buffered +.It Qq B +fully buffered with the default buffer size +.It Ar size +fully buffered with a buffer of +.Ar size +bytes +.El +.Sh EXAMPLE +In the following example, the stdout stream of the +.Xr awk 1 +command +will be fully buffered by default because it does not refer +to a terminal. +.Nm +is used to force it to be line-buffered so +.Xr vmstat 8 Ns 's +output will not stall until the full buffer fills. +.Bd -literal -offset indent +# vmstat 1 | LD_PRELOAD=/usr/lib/libstdbuf.so \\ + STDBUF_1=L awk '$2 > 1 || $3 > 1' | cat -n +.Ed +.Pp +See also the manpage of +.Xr stdbuf 1 +for a simpler way to do this. +.Sh HISTORY +The +.Nm +library first appeared in +.Fx 9.0 . +.Sh AUTHORS +.An -nosplit +The original idea of the +.Nm +command comes from +.An Padraig Brady +who implemented it in the GNU coreutils. +.An Jeremie Le Hen +implemented it on +.Fx . diff -urNp src.HEAD_20111506/lib/libstdbuf/stdbuf.c src/lib/libstdbuf/stdbuf.c --- src.HEAD_20111506/lib/libstdbuf/stdbuf.c 1970-01-01 01:00:00.000000000 +0100 +++ src/lib/libstdbuf/stdbuf.c 2011-08-04 18:17:07.000000000 +0200 @@ -0,0 +1,105 @@ +/*- + * Copyright (c) 2011 Jeremie Le Hen + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``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 AUTHOR 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. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include + +static const char * +stream_name(FILE *s) +{ + if (s == stdin) + return "stdin"; + if (s == stdout) + return "stdout"; + if (s == stderr) + return "stderr"; + /* This should not happen. */ + abort(); +} + +static void +change_buf(FILE *s, const char *bufmode) +{ + size_t bufsiz; + uint64_t sizearg; + int mode; + + bufsiz = 0; + if (bufmode[0] == '0' && bufmode[1] == '\0') + mode = _IONBF; + else if (bufmode[0] == 'L' && bufmode[1] == '\0') + mode = _IOLBF; + else if (bufmode[0] == 'B' && bufmode[1] == '\0') { + mode = _IOFBF; + bufsiz = 0; + } else { + errno = 0; + if (expand_number(bufmode, &sizearg) == -1) { + warn("Wrong buffer mode '%s' for %s", bufmode, + stream_name(s)); + return; + } + if (sizearg > SIZE_T_MAX) { + warn("Buffer size too big for %s", stream_name(s)); + return; + } + mode = _IOFBF; + bufsiz = (size_t)sizearg; + } + if (setvbuf(s, NULL, mode, bufsiz) != 0) + warn("Cannot set buffer mode '%s' for %s", bufmode, + stream_name(s)); +} + +__attribute__ ((constructor)) static void +stdbuf(void) +{ + char *i_mode, *o_mode, *e_mode; + + i_mode = getenv("STDBUF_0"); + if (i_mode == NULL) + i_mode = getenv("_STDBUF_I"); + o_mode = getenv("STDBUF_1"); + if (o_mode == NULL) + o_mode = getenv("_STDBUF_O"); + e_mode = getenv("STDBUF_2"); + if (e_mode == NULL) + e_mode = getenv("_STDBUF_E"); + + if (e_mode) + change_buf(stderr, e_mode); + if (i_mode) + change_buf(stdin, i_mode); + if (o_mode) + change_buf(stdout, o_mode); +} diff -urNp src.HEAD_20111506/usr.bin/stdbuf/Makefile src/usr.bin/stdbuf/Makefile --- src.HEAD_20111506/usr.bin/stdbuf/Makefile 1970-01-01 01:00:00.000000000 +0100 +++ src/usr.bin/stdbuf/Makefile 2011-08-02 19:16:30.000000000 +0200 @@ -0,0 +1,8 @@ +# $Id$ + +PROG= stdbuf +SRCS= stdbuf.c + +WARNS?= 6 + +.include Files src.HEAD_20111506/usr.bin/stdbuf/sh.core and src/usr.bin/stdbuf/sh.core differ diff -urNp src.HEAD_20111506/usr.bin/stdbuf/stdbuf.1 src/usr.bin/stdbuf/stdbuf.1 --- src.HEAD_20111506/usr.bin/stdbuf/stdbuf.1 1970-01-01 01:00:00.000000000 +0100 +++ src/usr.bin/stdbuf/stdbuf.1 2011-08-04 18:46:35.000000000 +0200 @@ -0,0 +1,124 @@ +.\" Copyright (C) 2011 Jeremie Le Hen +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code and documentation must retain the above +.\" copyright notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed or owned by Caldera +.\" International, Inc. +.\" 4. Neither the name of Caldera International, Inc. nor the names of other +.\" contributors may be used to endorse or promote products derived from +.\" this software without specific prior written permission. +.\" +.\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA +.\" INTERNATIONAL, INC. AND CONTRIBUTORS ``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 CALDERA INTERNATIONAL, INC. 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. +.\" +.\" $FreeBSD: src/usr.bin/dc/dc.1,v 1.2 2010/01/22 23:50:46 delphij Exp $ +.\" +.Dd August 4, 2011 +.Dt STDBUF 1 +.Os +.Sh NAME +.Nm stdbuf +.Nd change standard streams initial buffering +.Sh SYNOPSIS +.Nm +.Op Fl e Ar bufdef +.Op Fl i Ar bufdef +.Op Fl o Ar bufdef +.Op Ar command Op ... +.Sh DESCRIPTION +.Nm +is used to change the initial buffering of standard input, +standard output and/or standard error streams for +.Ar command . +It relies on +.Xr libstdbuf 3 +which is loaded and configured by +.Nm +through environment variables. +.Pp +The options are as follows: +.Bl -tag -width Ds +.It Fl e Ar bufdef +Set initial buffering of the standard error stream for +.Ar command +as defined by +.Ar bufdef +.Pq see Sx BUFFER DEFINITION . +.It Fl i Ar bufdef +Set initial buffering of the standard input stream for +.Ar command +as defined by +.Ar bufdef +.Pq see Sx BUFFER DEFINITION . +.It Fl o Ar bufdef +Set initial buffering of the standard output stream for +.Ar command +as defined by +.Ar bufdef +.Pq see Sx BUFFER DEFINITION . +.El +.Sh BUFFER DEFINITION +Buffer definition is the same as in +.Xr libstdbuf 3 : +.Bl -tag -width size -offset indent +.It Qq 0 +unbuffered +.It Qq L +line buffered +.It Qq B +fully buffered with the default buffer size +.It Ar size +fully buffered with a buffer of +.Ar size +bytes +.El +.Sh EXAMPLES +In the following example, the stdout stream of the +.Xr awk 1 +command +will be fully buffered by default because it does not refer +to a terminal. +.Nm +is used to force it to be line-buffered so +.Xr vmstat 8 Ns 's +output will not stall until the full buffer fills. +.Bd -literal -offset indent +# vmstat 1 | stdbuf -o L awk '$2 > 1 || $3 > 1' | cat -n +.Ed +.Sh SEE ALSO +.Xr libstdbuf 3 , +.Xr setvbuf 3 +.Sh HISTORY +The +.Nm +utility first appeared in +.Fx 9.0 . +.Sh AUTHORS +.An -nosplit +The original idea of the +.Nm +command comes from +.An Padraig Brady +who implemented it in the GNU coreutils. +.An Jeremie Le Hen +implemented it on +.Fx . diff -urNp src.HEAD_20111506/usr.bin/stdbuf/stdbuf.c src/usr.bin/stdbuf/stdbuf.c --- src.HEAD_20111506/usr.bin/stdbuf/stdbuf.c 1970-01-01 01:00:00.000000000 +0100 +++ src/usr.bin/stdbuf/stdbuf.c 2011-08-04 18:17:50.000000000 +0200 @@ -0,0 +1,107 @@ +/*- + * Copyright (c) 2011 Jeremie Le Hen + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``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 AUTHOR 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. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include + +#define LIBSTDBUF "/usr/lib/libstdbuf.so" + +extern char *__progname; + +static void usage(int); + +static void +usage(int s) +{ + + fprintf(stderr, "Usage: %s [-e bufdef] [-i bufdef] [-o bufdef] " + " [args ...]\n", __progname); + fprintf(stderr, " ``bufdef'' being:\n"); + fprintf(stderr, " - \"0\" to disable buffering;\n"); + fprintf(stderr, " - \"L\" to set line-buffering;\n"); + fprintf(stderr, " - to set full-buffering.\n"); + exit(s); +} + +int +main(int argc, char *argv[]) +{ + int i; + char *ibuf = NULL, *obuf = NULL, *ebuf = NULL; + char *preload0, *preload1; + + while ((i = getopt(argc, argv, ":e:i:o:")) != -1) { + switch (i) { + case 'e': + ebuf = optarg; + break; + case 'i': + ibuf = optarg; + break; + case 'o': + obuf = optarg; + break; + case ':': + warnx("Missing argument for option -%c", optopt); + usage(1); + break; + case '?': + default: + warnx("Unknown option -%c", optopt); + usage(1); + break; + } + } + argc -= optind; + argv += optind; + + if (ibuf != NULL && setenv("STDBUF_0", ibuf, 1) == -1) + warn("Failed to set environment variable: %s=%s", + "STDBUF_0", ibuf); + if (obuf != NULL && setenv("STDBUF_1", obuf, 1) == -1) + warn("Failed to set environment variable: %s=%s", + "STDBUF_1", obuf); + if (ebuf != NULL && setenv("STDBUF_2", ebuf, 1) == -1) + warn("Failed to set environment variable: %s=%s", + "STDBUF_2", ebuf); + + preload0 = getenv("LD_PRELOAD"); + if (preload0 == NULL) + i = asprintf(&preload1, "LD_PRELOAD=" LIBSTDBUF); + else + i = asprintf(&preload1, "LD_PRELOAD=%s:%s", preload0, + LIBSTDBUF); + + if (i < 0 || putenv(preload1) == -1) + warn("Failed to set environment variable: %s", preload1); + + execvp(argv[0], argv); + err(2, "%s", argv[0]); +} --XsQoSWH+UP9D9v3l-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 23:12:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD6271065672 for ; Thu, 4 Aug 2011 23:12:59 +0000 (UTC) (envelope-from prvs=11971cf4bd=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 449368FC19 for ; Thu, 4 Aug 2011 23:12:56 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 05 Aug 2011 00:01:53 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 05 Aug 2011 00:01:53 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014471622.msg for ; Fri, 05 Aug 2011 00:01:51 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11971cf4bd=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> From: "Steven Hartland" To: Date: Fri, 5 Aug 2011 00:02:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: cam / ata timeout limited to 2147 due to overflow bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:12:59 -0000 I'm working on adding security methods to camcontrol and have come up against a strange issue. It seems that the timeout value for cam, at least on ata (ahci), is limited to less than 2148 seconds. This can be seen by running:- camcontrol identify ada0 -t 2148 -v (pass0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 (pass0:ahcich0:0:0:0): CAM status: Command timeout Also seen in /var/log/messages at this time is:- Aug 4 23:29:51 cfdev kernel: ahcich0: Timeout on slot 24 Aug 4 23:29:51 cfdev kernel: ahcich0: is 00000000 cs 01000000 ss 00000000 rs 01000000 tfd d0 serr 00000000 Dropping the timeout down to 2147 and the command runs fine. I've done some digging and it seems like this is implemented via:- sys/dev/ahci/ahci.c ahci_execute_transaction(struct ahci_slot *slot) { ... /* Start command execution timeout */ callout_reset(&slot->timeout, (int)ccb->ccb_h.timeout * hz / 2000, (timeout_t*)ahci_timeout, slot); Now its documented that:- "Non-positive values of ticks are silently converted to the value 1" So I suspect that this is what's happening resulting in an extremely small timeout instead of a large one. Now I know that passed in value to the timeout is seconds * 1000 so we should be seeing 2148000 for ccb->ccb_h.timeout now multiply that by 1000 (hz) and your over the int wrap point 2147483647. So instead of the wrap point being 2147483 seconds (24 days), I suspect because of the way this is structured its actually 2147 seconds (26mins). If this is the case the fix is likely to be something like:- callout_reset(&slot->timeout, (int)(ccb->ccb_h.timeout * (hz / 2000)), Does this sound reasonable? What I don't understand is why the /2000? For reference the reason for wanting a large timeout is that a secure erase of large media could take many hours so I'm using the erase time reported by the drive for this, in my case here is 400 minutes. Currently this instantly fails with a Command timeout which is clearly not right. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 08:00:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98DD31065673 for ; Fri, 5 Aug 2011 08:00:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2512F8FC0A for ; Fri, 5 Aug 2011 08:00:00 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p757xvSV058254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 10:59:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p757xvf0075090; Fri, 5 Aug 2011 10:59:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p757xv17075089; Fri, 5 Aug 2011 10:59:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Aug 2011 10:59:57 +0300 From: Kostik Belousov To: Steven Hartland Message-ID: <20110805075957.GP17489@deviant.kiev.zoral.com.ua> References: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MRe2Ouhm04S76NDZ" Content-Disposition: inline In-Reply-To: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: cam / ata timeout limited to 2147 due to overflow bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:00:01 -0000 --MRe2Ouhm04S76NDZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 05, 2011 at 12:02:19AM +0100, Steven Hartland wrote: > I'm working on adding security methods to camcontrol and have > come up against a strange issue. It seems that the timeout > value for cam, at least on ata (ahci), is limited to less than > 2148 seconds. >=20 > This can be seen by running:- > camcontrol identify ada0 -t 2148 -v > (pass0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 0= 0=20 > 00 > (pass0:ahcich0:0:0:0): CAM status: Command timeout >=20 > Also seen in /var/log/messages at this time is:- > Aug 4 23:29:51 cfdev kernel: ahcich0: Timeout on slot 24 > Aug 4 23:29:51 cfdev kernel: ahcich0: is 00000000 cs 01000000 ss 0000000= 0=20 > rs 01000000 tfd d0 serr 00000000 >=20 > Dropping the timeout down to 2147 and the command runs fine. >=20 > I've done some digging and it seems like this is implemented via:- > sys/dev/ahci/ahci.c > ahci_execute_transaction(struct ahci_slot *slot) > { > ... > /* Start command execution timeout */ > callout_reset(&slot->timeout, (int)ccb->ccb_h.timeout * hz / 2000, > (timeout_t*)ahci_timeout, slot); >=20 > Now its documented that:- > "Non-positive values of ticks are silently converted to the value 1" >=20 > So I suspect that this is what's happening resulting in an extremely > small timeout instead of a large one. Now I know that passed in value > to the timeout is seconds * 1000 so we should be seeing 2148000 > for ccb->ccb_h.timeout now multiply that by 1000 (hz) and your over > the int wrap point 2147483647. >=20 > So instead of the wrap point being 2147483 seconds (24 days), I suspect > because of the way this is structured its actually 2147 seconds (26mins). >=20 > If this is the case the fix is likely to be something like:- > callout_reset(&slot->timeout, (int)(ccb->ccb_h.timeout * (hz / 2000)), For hz =3D=3D 1000, hz / 2000 =3D=3D 0 according to the C rules, so the result will be 0 always. >=20 > Does this sound reasonable? What I don't understand is why the /2000? >=20 > For reference the reason for wanting a large timeout is that a > secure erase of large media could take many hours so I'm using > the erase time reported by the drive for this, in my case here is > 400 minutes. >=20 > Currently this instantly fails with a Command timeout which is > clearly not right. >=20 > Regards > Steve >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he=20 > person or entity to whom it is addressed. In the event of misdirection, t= he=20 > recipient is prohibited from using, copying, printing or otherwise=20 > disseminating it or any information contained in it.=20 > In the event of misdirection, illegible or incomplete transmission please= =20 > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --MRe2Ouhm04S76NDZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk47ovwACgkQC3+MBN1Mb4iaPQCfbbcO3Vu0DEBP7h7umwZoYXW7 ttIAoKgMITHEs0YyuHfeMaYQ08cTc4qX =0hCw -----END PGP SIGNATURE----- --MRe2Ouhm04S76NDZ-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 08:11:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54141106566C; Fri, 5 Aug 2011 08:11:23 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E1D118FC16; Fri, 5 Aug 2011 08:11:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=H9g4xF5qYv9oBS1IawlHR54V6TKh5eNMPHG01shxj4M=; b=DHM4jn8eyLZuJjO873AWJJXY7uClGHSAWxatPaP/QZuaSjsQkI/hrzO78/JKMg5Ewni1rFl5qfKYhH9/VdOgyzIzKeoLphksRlz8Xa/URt/vLwrPIT71UehbsmxvyZWZyvb+1hHiRitK4kw6eG2nW4kd6jMm6UwbO0XfoPLiugo7eswFBN9cFQRk0jB809zcEde+p+J/2zKFu9/Z0s1jdBWX7LbowMd4w0BRyq4ECAQ19jXX3rKkoVSC3dq0ut48WMVxe+zWmKrW2oVqaYnTIxuCUOyPomsLPSjx3v3x258wZMfV3OUfQuHcR9a4jr6q9lnP04NaCoDIYjJ7aZS0Ng==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1QpFV3-0005ef-6G; Fri, 05 Aug 2011 12:11:21 +0400 Date: Fri, 5 Aug 2011 12:11:18 +0400 From: Eygene Ryabinkin To: Steven Hartland Message-ID: References: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> Sender: rea@codelabs.ru Cc: freebsd-hackers@freebsd.org, mav@freebsd.org Subject: Re: cam / ata timeout limited to 2147 due to overflow bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:11:23 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Steven, good day. Fri, Aug 05, 2011 at 12:02:19AM +0100, Steven Hartland wrote: > So I suspect that this is what's happening resulting in an extremely > small timeout instead of a large one. Now I know that passed in value > to the timeout is seconds * 1000 so we should be seeing 2148000 > for ccb->ccb_h.timeout now multiply that by 1000 (hz) and your over > the int wrap point 2147483647. >=20 > So instead of the wrap point being 2147483 seconds (24 days), I suspect > because of the way this is structured its actually 2147 seconds (26mins). >=20 > If this is the case the fix is likely to be something like:- > callout_reset(&slot->timeout, (int)(ccb->ccb_h.timeout * (hz / 2000)), It will give you 0 timeout for all values of hz that are lower than 2000: hz is int, so you'll get integer division. Since ccb_h.timeout is u_int32_t, the proper way to handle this situation would be {{{ (u_int64_t)ccb->ccb_h.timeout * (u_int32_t)hz)/2000 }}} as long as the value of hz won't be greater than 2^32. Can you try the patch at http://codelabs.ru/fbsd/patches/ahci/AHCI-properly-convert-CAM-timeout-to= -ticks.diff > What I don't understand is why the /2000 It gives (timeout_in_ticks)/2. The code in ahci_timeout does the following: {{{ /* Check if slot was not being executed last time we checked. */ if (slot->state < AHCI_SLOT_EXECUTING) { /* Check if slot started executing. */ sstatus =3D ATA_INL(ch->r_mem, AHCI_P_SACT); ccs =3D (ATA_INL(ch->r_mem, AHCI_P_CMD) & AHCI_P_CMD_CCS_MA= SK) >> AHCI_P_CMD_CCS_SHIFT; if ((sstatus & (1 << slot->slot)) !=3D 0 || ccs =3D=3D slot= ->slot || ch->fbs_enabled) slot->state =3D AHCI_SLOT_EXECUTING; callout_reset(&slot->timeout, (int)slot->ccb->ccb_h.timeout * hz / 2000, (timeout_t*)ahci_timeout, slot); return; } }}} So, my theory is that the first half of the timeout time is devoted to the transition from AHCI_SLOT_RUNNING -> AHCI_SLOT_EXECUTING and the second one is the transition from AHCI_SLOT_RUNNING -> TIMEOUT to give the whole process the duration of a full timeout. However, judging by the code, if the slot won't start executing at the first invocation of ahci_timeout that was spawned by the callout armed in ahci_execute_transaction, we can have timeouts more than for the specified amount of time. And if the slot will never start its execution, the callout will spin forever, unless I am missing something important here. May be Alexander can shed some light into this? --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk47paYACgkQFq+eroFS7PshggD7BjGIRUl6F0iBu2jazwBmcM72 8cIbhC6QN+zbvLSFE2wBAJQlebM+hbMjdT6dAPwo8NXacDd7UMvmUTtwyueekbHU =pWkn -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 10:11:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91DA1106564A for ; Fri, 5 Aug 2011 10:11:29 +0000 (UTC) (envelope-from prvs=1198404263=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 02C828FC13 for ; Fri, 5 Aug 2011 10:11:28 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 05 Aug 2011 11:00:36 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 05 Aug 2011 11:00:33 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014476977.msg; Fri, 05 Aug 2011 11:00:33 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1198404263=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Eygene Ryabinkin" References: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> Date: Fri, 5 Aug 2011 10:59:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-hackers@freebsd.org, mav@freebsd.org Subject: Re: cam / ata timeout limited to 2147 due to overflow bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:11:29 -0000 Fri, Aug 05, 2011 at 12:02:19AM +0100, Steven Hartland wrote: >> So I suspect that this is what's happening resulting in an extremely >> small timeout instead of a large one. Now I know that passed in value >> to the timeout is seconds * 1000 so we should be seeing 2148000 >> for ccb->ccb_h.timeout now multiply that by 1000 (hz) and your over >> the int wrap point 2147483647. >> >> So instead of the wrap point being 2147483 seconds (24 days), I suspect >> because of the way this is structured its actually 2147 seconds (26mins). >> >> If this is the case the fix is likely to be something like:- >> callout_reset(&slot->timeout, (int)(ccb->ccb_h.timeout * (hz / 2000)), > > It will give you 0 timeout for all values of hz that are lower than > 2000: hz is int, so you'll get integer division. Since ccb_h.timeout > is u_int32_t, the proper way to handle this situation would be > {{{ > (u_int64_t)ccb->ccb_h.timeout * (u_int32_t)hz)/2000 > }}} > as long as the value of hz won't be greater than 2^32. Ahh of course, was late ;-) > Can you try the patch at > http://codelabs.ru/fbsd/patches/ahci/AHCI-properly-convert-CAM-timeout-to-ticks.diff > >> What I don't understand is why the /2000 > > It gives (timeout_in_ticks)/2. The code in ahci_timeout does the following: > {{{ > /* Check if slot was not being executed last time we checked. */ > if (slot->state < AHCI_SLOT_EXECUTING) { snip.. > > So, my theory is that the first half of the timeout time is devoted > to the transition from AHCI_SLOT_RUNNING -> AHCI_SLOT_EXECUTING and > the second one is the transition from AHCI_SLOT_RUNNING -> TIMEOUT > to give the whole process the duration of a full timeout. However, > judging by the code, if the slot won't start executing at the first > invocation of ahci_timeout that was spawned by the callout armed in > ahci_execute_transaction, we can have timeouts more than for the > specified amount of time. And if the slot will never start its > execution, the callout will spin forever, unless I am missing something > important here. > > May be Alexander can shed some light into this? Interesting thanks for the explaination. I've tried the patch and it a few cut and paste errors, which I've fixed, and confirmed it works as expected, so thanks for that :) There's also a load more drivers with the same issue so I've gone through and fixed all the occurances I can find. Here's the updated patch:- http://blog.multiplay.co.uk/dropzone/freebsd/ccb_timeout.patch Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 11:41:05 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E44B106564A; Fri, 5 Aug 2011 11:41:05 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C23C78FC15; Fri, 5 Aug 2011 11:41:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=d5GYb5GdRRO/jd/bSG1FzglUGXQAHr2H5agpGy3BOoE=; b=qTuTzzq+z46KmrTRXO+yIa92b8JX6Qk79YYhIIRKKuxiHkMCcyrDnSeYrY7UYsLPCQXjx7CC6w0cs0xuuBewWXUstluKLwhMBZaQZdfTFzZRQ6qkwgpcgZQ6yypkMF5hiovlNKFkNr816O/f2VGk1CYQT1SVVaAMs+bk8Xx9yNvIdiqrc6b42kvQbFRMeKKWJJrY+7CWDMCGwf3aJ6sN2LnPb0moQTvIWjFJU/7qua5Ja2OUHJVJQ9toyxvEEGZFvvQk9zxJwlycc0tjld37NK8YAPNbq/YOKpEVntz9B6YE+35EtBf+0A3vBqCa3ZUWn+f92OE0QqghrMnolUOI5A==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1QpIlz-000Lt9-Dn; Fri, 05 Aug 2011 15:41:03 +0400 Date: Fri, 5 Aug 2011 15:41:01 +0400 From: Eygene Ryabinkin To: Steven Hartland Message-ID: References: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: Sender: rea@codelabs.ru Cc: freebsd-hackers@freebsd.org, mav@freebsd.org Subject: Re: cam / ata timeout limited to 2147 due to overflow bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 11:41:05 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Fri, Aug 05, 2011 at 10:59:43AM +0100, Steven Hartland wrote: > I've tried the patch and it a few cut and paste errors, which I've fixed, Thanks for spotting that! > and confirmed it works as expected, so thanks for that :) >=20 > There's also a load more drivers with the same issue so I've gone through > and fixed all the occurances I can find. Here's the updated patch:- > http://blog.multiplay.co.uk/dropzone/freebsd/ccb_timeout.patch I had found a couple of missed drivers, fixed overlong lines and fixed the missing 10 in the sys/dev/hptrr/hptrr_os_bsd.c. Also changed ciss to have u_int32_t timeouts instead of int ones: this should not harm anything, because all passed timeouts are explicit numbers that are not larger than 100000. And I had also renamed CAM_HDR_TIMEOUT_TO_TICKS to the base CAM_TIMEOUT_TO_TICKS, because it seems that every CAM timeout is 32-bit long. The new patch lives at http://codelabs.ru/fbsd/patches/cam/CAM-properly-convert-timeout-to-ticks= =2Ediff But there are some cases where the argument to the CAM_TIMEOUT_TO_TICKS is int and not u_int32_t. It should be mostly harmless for now, since the values do not exceed 2^32, but my current feeling about timeouts that are counted in milliseconds that there should be an in-kernel type for this stuff. Seems like 32-bit wide unsigned value is good for it: maximal value is around 46 days that should be fine for the millisecond-precision timeout. Through my grep session for the kernel sources I had seen other (t * hz / 1000) constructs, so I feel that the fix should be extended to cover these cases as well. I am interested in the other's opinions on this. Thanks again! --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk471s0ACgkQFq+eroFS7PvdvgD/Y8vcBd31rE8RQgX3HAjf76Z/ hubFqM3PkZknlM63XEIA/25zx2hjvBuzzgbC3QftshBTHZpf155idkJZgFjLFZAx =Kpxm -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 15:21:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92A701065675 for ; Fri, 5 Aug 2011 15:21:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 542058FC19 for ; Fri, 5 Aug 2011 15:21:40 +0000 (UTC) Received: by yic13 with SMTP id 13so2183376yic.13 for ; Fri, 05 Aug 2011 08:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZQLrKuA6eGeqUICKdmSBkiwQL8akI792vDxUPRTqDEE=; b=mlY+0z9BwAiD8JzRqLRZMZ31pAhn56cI8LMKzPXrDnLCuSLY5CTos3Tp5NXGCBZ1ZE YjtEK0EQHzHW3hVKTLsvCsZDuR8BvRkafMIOJ/zdid2vpv8q5emnJMLo2xHJcfMg2w2I zuDKlobCmoPjAj6wDwcrzM7cd3NgX+BAe1jTs= MIME-Version: 1.0 Received: by 10.150.166.1 with SMTP id o1mr200107ybe.73.1312557699657; Fri, 05 Aug 2011 08:21:39 -0700 (PDT) Received: by 10.150.200.3 with HTTP; Fri, 5 Aug 2011 08:21:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Aug 2011 19:21:39 +0400 Message-ID: From: Sergey Kandaurov To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: module_register_init fails, but driver is still loaded? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 15:21:40 -0000 On 4 August 2011 20:23, Garrett Cooper wrote: > Hi hackers, > =A0 =A0I noticed that if anything fails while initializing a driver, the > driver stays attached to the kernel as a module instead of being > kicked when all references to the driver go to 0. Is this desired > behavior (it doesn't seem like it, but I can see potential pros and > cons of kicking the driver out of the kernel immediately when a > failure state occurs)? I've seen this on 7.2 ~ 9-CURRENT. Example > sourcecode and invocation attached below. Hi. I have cooked something that might work, though I don't know how much is it correct from locking & cleanup side. Can you try it? Anyway, in its current form we cannot return error from module_register_init() because it's usually called from SYSINIT, so kldload(8) will say nonsense: can't load ./bad_module.ko: No error: 0. Index: sys/kern/kern_module.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_module.c (revision 224471) +++ sys/kern/kern_module.c (working copy) @@ -112,6 +117,7 @@ module_register_init(const void *arg) const moduledata_t *data =3D (const moduledata_t *)arg; int error; module_t mod; + linker_file_t lf; mtx_lock(&Giant); MOD_SLOCK; @@ -123,12 +129,14 @@ module_register_init(const void *arg) error =3D MOD_EVENT(mod, MOD_LOAD); if (error) { MOD_EVENT(mod, MOD_UNLOAD); + lf =3D mod->file; MOD_XLOCK; module_release(mod); MOD_XUNLOCK; printf("module_register_init: MOD_LOAD (%s, %p, %p) error" " %d\n", data->name, (void *)data->evhand, data->priv, error); + linker_release_module(NULL, NULL, lf); } else { MOD_XLOCK; if (mod->file) { --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 15:39:27 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB7701065670 for ; Fri, 5 Aug 2011 15:39:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0130D8FC1D for ; Fri, 5 Aug 2011 15:39:26 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA23079; Fri, 05 Aug 2011 18:39:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E3C0EAB.8010609@FreeBSD.org> Date: Fri, 05 Aug 2011 18:39:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Sergey Kandaurov References: In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@FreeBSD.org Subject: Re: module_register_init fails, but driver is still loaded? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 15:39:27 -0000 on 05/08/2011 18:21 Sergey Kandaurov said the following: > On 4 August 2011 20:23, Garrett Cooper wrote: >> Hi hackers, >> I noticed that if anything fails while initializing a driver, the >> driver stays attached to the kernel as a module instead of being >> kicked when all references to the driver go to 0. Is this desired >> behavior (it doesn't seem like it, but I can see potential pros and >> cons of kicking the driver out of the kernel immediately when a >> failure state occurs)? I've seen this on 7.2 ~ 9-CURRENT. Example >> sourcecode and invocation attached below. > > Hi. > I have cooked something that might work, though I don't know how much > is it correct from locking & cleanup side. Can you try it? Anyway, in its > current form we cannot return error from module_register_init() because > it's usually called from SYSINIT, so kldload(8) will say nonsense: > can't load ./bad_module.ko: No error: 0. Have you also accounted for a situation where multiple logical modules shared the same kernel loadable file? Especially when some modules load successfully while others fail. > Index: sys/kern/kern_module.c > =================================================================== > --- sys/kern/kern_module.c (revision 224471) > +++ sys/kern/kern_module.c (working copy) > @@ -112,6 +117,7 @@ module_register_init(const void *arg) > const moduledata_t *data = (const moduledata_t *)arg; > int error; > module_t mod; > + linker_file_t lf; > > mtx_lock(&Giant); > MOD_SLOCK; > @@ -123,12 +129,14 @@ module_register_init(const void *arg) > error = MOD_EVENT(mod, MOD_LOAD); > if (error) { > MOD_EVENT(mod, MOD_UNLOAD); > + lf = mod->file; > MOD_XLOCK; > module_release(mod); > MOD_XUNLOCK; > printf("module_register_init: MOD_LOAD (%s, %p, %p) error" > " %d\n", data->name, (void *)data->evhand, data->priv, > error); > + linker_release_module(NULL, NULL, lf); > } else { > MOD_XLOCK; > if (mod->file) { > > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 04:16:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C8C106564A for ; Sat, 6 Aug 2011 04:16:52 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id DFCB68FC13 for ; Sat, 6 Aug 2011 04:16:51 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p764GpQR003877 for ; Fri, 5 Aug 2011 21:16:51 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4E3CC033.6070604@rawbw.com> Date: Fri, 05 Aug 2011 21:16:51 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: top(1) loses process user time count when threads end X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 04:16:52 -0000 I have the process that first runs in 3 threads but later two active threads exit. top(1) shows this moment this way (1 sec intervals): 30833 yuri 3 76 0 4729M 4225M nanslp 4 0:32 88.62% app 30833 yuri 3 76 0 4729M 4225M nanslp 6 0:34 90.92% app 30833 yuri 1 96 0 4729M 4225M CPU1 1 0:03 1.17% app 30833 yuri 1 98 0 4729M 4226M CPU1 1 0:04 12.89% app Process time goes down: 0:34 -> 0:03. Also WCPU goes down 90.92% -> 1.17% even though this process is CPU bound and does intense things right after threads exit. getrusage(2) though, called in the process, shows the correct user time. I think this is the major bug in the process time accounting. 8.2-STABLE Yuri From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 09:11:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 808F81065676; Sat, 6 Aug 2011 09:11:27 +0000 (UTC) Date: Sat, 6 Aug 2011 09:11:27 +0000 From: Alexander Best To: Yuri Message-ID: <20110806091127.GA39951@freebsd.org> References: <4E3CC033.6070604@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3CC033.6070604@rawbw.com> Cc: freebsd-hackers@freebsd.org Subject: Re: top(1) loses process user time count when threads end X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 09:11:27 -0000 On Fri Aug 5 11, Yuri wrote: > I have the process that first runs in 3 threads but later two active > threads exit. > > top(1) shows this moment this way (1 sec intervals): > 30833 yuri 3 76 0 4729M 4225M nanslp 4 0:32 88.62% app > 30833 yuri 3 76 0 4729M 4225M nanslp 6 0:34 90.92% app > 30833 yuri 1 96 0 4729M 4225M CPU1 1 0:03 1.17% app > 30833 yuri 1 98 0 4729M 4226M CPU1 1 0:04 12.89% app > > Process time goes down: 0:34 -> 0:03. Also WCPU goes down 90.92% -> > 1.17% even though this process is CPU bound and does intense things > right after threads exit. > > getrusage(2) though, called in the process, shows the correct user time. > > I think this is the major bug in the process time accounting. could you check, whether kern/128177 or kern/140892 describe your situation? cheers. alex > > 8.2-STABLE > > Yuri From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 17:57:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81EB7106564A for ; Sat, 6 Aug 2011 17:57:36 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD338FC14 for ; Sat, 6 Aug 2011 17:57:36 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p76HvZ8u024741; Sat, 6 Aug 2011 10:57:36 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4E3D808F.1030101@rawbw.com> Date: Sat, 06 Aug 2011 10:57:35 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: Alexander Best References: <4E3CC033.6070604@rawbw.com> <20110806091127.GA39951@freebsd.org> In-Reply-To: <20110806091127.GA39951@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: top(1) loses process user time count when threads end X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 17:57:36 -0000 On 08/06/2011 02:11, Alexander Best wrote: > On Fri Aug 5 11, Yuri wrote: >> I have the process that first runs in 3 threads but later two active >> threads exit. >> >> top(1) shows this moment this way (1 sec intervals): >> 30833 yuri 3 76 0 4729M 4225M nanslp 4 0:32 88.62% app >> 30833 yuri 3 76 0 4729M 4225M nanslp 6 0:34 90.92% app >> 30833 yuri 1 96 0 4729M 4225M CPU1 1 0:03 1.17% app >> 30833 yuri 1 98 0 4729M 4226M CPU1 1 0:04 12.89% app >> >> Process time goes down: 0:34 -> 0:03. Also WCPU goes down 90.92% -> >> 1.17% even though this process is CPU bound and does intense things >> right after threads exit. >> >> getrusage(2) though, called in the process, shows the correct user time. >> >> I think this is the major bug in the process time accounting. > could you check, whether kern/128177 or kern/140892 describe your situation? I have ULE scheduler. kern/128177 talks about single thread with ULE scheduler, and my issue is with threads. So I am not sure if it is related. There have been no motion on kern/128177 since Feb 9, 2009. kern/140892 is probably the same as mine. In any case, both these PRs have to be fixed since they are very user visible, not just some obscure issues. Yuri