Re: PathScale EKO Path 5 not for FreeBSD anymore?
Oliver I try to use FreeBSD for day-to-day numerical work, as far as possible. I have to complement it with linux cluster systems, largely due to a range of compilers available there. Anyway, keep me posted if you get anywhere with this. Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: system 20% busy at all times?
Hi,
On Feb 19, 2013, at 17:58, Adrian Chadd adr...@freebsd.org wrote:
Try top -HS .. to try and break down the kernel threads.
ACPI is eating the cycles, according to top:
0 root 80 0K 496K - 2 1:13 27.88%
kernel{acpi_task_2}
0 root 80 0K 496K - 0 1:13 25.68%
kernel{acpi_task_1}
0 root 80 0K 496K CPU11 1:07 23.68%
kernel{acpi_task_0}
I got an off-list hint that the machine in question requires device mptable
instead of relying on ACPI. I will try that.
As for dtrace, a complete buildworld/installworld cycle didn't change things, I
still get:
# dtrace -n 'syscall:::entry { @num[execname] = count(); }'
dtrace: invalid probe specifier syscall:::entry { @num[execname] = count(); }:
/usr/lib/dtrace/psinfo.d, line 90: failed to resolve type kernel`struct
thread * for identifier curthread: Module is no longer loaded
Thanks for all the help!
Lars
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r246916 probably broke amd64 build
Davide Italiano dav...@freebsd.org writes: Unfortunately tinderbox didn't catch this bug because it's triggered only when gcc is used to build kernel. In this particular case, the broken code is only built on platforms which default to clang. Otherwise, it would have been caught when building one of the platforms that default to gcc. The tinderbox servers simply donn't have enough CPU power to build all possible combinations. There isn't even enough for a standard build of all platforms at a reasonable frequency. I have a stack of new servers, but nowhere to host them - see the donations wantlist for details. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PathScale EKO Path 5 not for FreeBSD anymore?
I forwarded this thread to Christopher Bergstöm and got this reply: FreeBSD simply isn't a scientific computing platform - There isn't any market demand, it's not designed for it, many of the tools commonly used aren't available and the amount of work to change that is significant. (I don't just mean technical, but also mindshare for those in the technical computing field) However, we haven't dropped support for it http://c591116.r16.cf2.rackcdn.com/enzo/nightly/FreeBSD/enzo-2013-02-19-installer.run There's a few GPGPU related bugs we'd have to fix for it to work for you, but those are pretty small and wouldn't take more than a few days. We made some big changes in EKOPath 5/ENZO and development is closed for now. We're trying to figure out a strategy which will have an impact and be win/win for everyone. Apologies if I may have dropped the ball on communication. I'm not subscribed to -current or -performance and please cc me on any replies. ./C A few additional comments: - FreeBSD libm really needs to get the missing C99 functions committed. We have good versions of these written now (with better accuracy than several competing operating systems that are successful scientific computing platforms), but they need committing. Of the 31 test failures in the libc++ test suite (which covers most of C++11) that I see currently, 18 are due to missing C99 functionality. Most of the missing functions are implemented, but committing them was held up by style nits in the source code. This is just embarrassing. - GPU support has been quite poor on FreeBSD, and this has a knock-on effect on GPGPU. It's a mistake to think of GPUs as just things gamers need and therefore not too important for FreeBSD - they're currently the best performance-per-dollar accelerators available on the market and so are of interest in a number of markets. If you or your company is using FreeBSD and wants to do GPGPU things, then make sure that AMD, Intel, and nVidia all know, and ideally let Qualcomm and ARM know too. The FreeBSD Foundation has funded work on KMS, GEM and TTM, and so open source driver support is improving. If you're willing to fund some more of this work, then please get in touch with the Foundation. Most of the companies in this space don't care what we say, they care what their customers (and potential customers) say. They won't support FreeBSD if there's no (perceived) demand, so it's important to make sure that they're aware of the demand. - A big part of the problem is mindshare. Linux is seen as the thing to use on clusters and supercomputers, even when it isn't the best tool for the job. It's hard to contradict this view when there aren't any (public) large-scale deployments of FreeBSD for scientific computing. If you have one that you're willing to talk about, please contact the Foundation and let them know. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
WITH_BMAKE: make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here
Well, I'm brave and switched several beta switches on my FreeBSD 10.0-CUR systems on and I realize, that I receive a lot of make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here make: /usr/ports/Mk/bsd.port.mk line 5140: warning: duplicate script for target -depends ignored messages when doing updates with portmaster or installing ports. I think this is BETA-normal, but a re there serious implications apart from some performance issues at the moment using bmake as the replacement for the oldish make in FreeBSD? I'm just curious, so feel free to answer if you like. Oliver signature.asc Description: OpenPGP digital signature
Re: daily otput: rejected mail hosts?
From mexas Thu Feb 14 09:51:50 2013 To: freebsd-questi...@freebsd.org Subject: daily otput: rejected mail hosts? Reply-To: me...@bristol.ac.uk I see in the daily output: Checking for rejected mail hosts: 172 553 check_mail system.mail exist 129 553 check_mail tsvpt014.vpt.co.uk exist 43 553 check_mail unix.dedicated.com.tr exist 43 553 check_mail ubs.net exist 43 553 check_mail localhost.localdomain exist 43 553 check_mail journal-cfp.org exist 43 553 check_mail italiasito.it exist What is that about? Is this described somewhere in sendmail manuals? I got no reply from questions@, so trying my luck here. Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PathScale EKO Path 5 not for FreeBSD anymore?
Am 02/20/13 10:09, schrieb Anton Shterenlikht: Oliver I try to use FreeBSD for day-to-day numerical work, as far as possible. I have to complement it with linux cluster systems, largely due to a range of compilers available there. Anyway, keep me posted if you get anywhere with this. Anton Hello Anton. The good German wine was talking yesterday, I guess. On PathScales EKOPath 4 website, FreeBSD and OpenSOLARIS are still mentioned and its HMPP, not OpenACC, that is used inline code. I have first to apologize for the depressive mood I spread around. It is EKOPath 5 BETA (webpage) that doesn't mention FreeBSD as supported platform - as one can easily see and watch at the intro page right bottom corner. The community of FreeBSD systems is decreasing from year to year and as David Chisnall reported in a reply on my posting, it seems to be a mindshare thing. Too many people are talking about business - business isn't the motivator, science is and this may be a special view of my country. BSD was developed at Berkeley in a very scientific manner and therefore it is a very strong logical system - apart from the crap Lnux started with. I think it is unwise to talk about philosphy at this moment. The fact is, that I'm the only one in my department that is using FreeBSD on two remaining servers (one is a small storage server) and my personal lab workstation - my private systems are all FreeBSD, but that is not the matter here. The equipment I bought when we had to spend money on the project's funding is quite impressive for a under the desk workstation - I guess. We also had the chance to purchase a Dell Precision 7500 workstation with a TESLA 2075 board and two 6-core Westmere CPUs at 2,6 GHz with 96 GB RAM - for modelling and rendering purposes (sometimes our scientific work in the planetology field requires to do PR for funding, so we render also ...). Having FreeBSD in the first place on that box everything worked quite well, since the drivers were applicable to the provided hardware, even the TESLA card was accepted by the nVidia BLOB. But that's it. We swapped to Suse Linux since the developer working on that system required OpenCL thriving the GPU for large DTM rendering. Our cluster system (Rocks) is pure Linux. We have a lot of Dell stuff around here, equipted with expensive iDRAC modules. They're supposed to get accessed via JAVA. From FreeBSD/Firefox, I can not start the console due to a JAVA error. Dell rejects support, since FreeBSD isn't supported. Yes, and this is the meaning of platform indepenedency ... It is also a political thing. Another thing, that seems unlogical is the MIT/BSD/CDDL versus GPLv3 licensing issue. FreeBSD, as the other *BSDs, are supposed to have the most advanced licensing model in terms of academic freedom and even for companies benefit from such a free licensing model. GPLv3 is curcified as the evil license and even companies which have an interest protecting their code should look at the BSD systems - but the fact is: Linux all over the place. What is wrong with this picture? The opinion shared within THIS community or a real blindness? Funding companies or professional developers for developing KMS, GEM and other stuff is one thing. Why is there no effort to fund students working on their Diploma Thesis or Dissertation with regards to develop methods, code or functionality to FreeBSD in a wide and open manner, so that it can be used platform independend? It is just an idea and it is a question that the FreeBSD Foundation has to answer and to decide on. The other very bad thing is the information I have to gather. Somehow I feel lost when looking for software for my work, even it is very popular. Gathering informations from many places - as it is with WHICH PROFESSIONAL COMPILER WORKS ON FREEBSD WITH PROFESSIONAL HIGH PERFORMANCE MATH LIBS is horrible and time consuming. try it on Google with the tag Linux makes you happy within seconds. And back to our case. For instance, meshalb is a very powerful tool used by many people working with point cloud data. Since more than half a year that port is broken on FreeBSD and that drove to scientists away from my FreeBSD installation to Linux - where is works perfectly - magically. Well, we have now devel/freeocl in the ports to provide a bit OpenCL stuff on FreeBSD - but on the CPU, not the GPU. My next attempt is to provide a port of devel/pocl, which isn't fit for FreeBSD in version 0.7 as there is a typo regarding amd64 and the x86_64 terminology, but those guys from Finnlandia are very, very nice and also PRO(!) freeBSd, so they told me that there is alsready a patch in the GIT. I haven't had the time to look at this since I'm consumed due to writing my thesis at the moment, but THERE IS STUFF of interest, but if it is a lonely-hunter-work only and the interest of the community is so low on such stuff even of the professional people hired to code for FreeBSD, then ... well, I lack in the necessary words.
Re: Possible bug in NFSv4 with krb5p security?
On Tue, Feb 19, 2013 at 08:52:49PM -0500, Rick Macklem wrote:
I cannot find how to get information about maximum buffer size for
the getpwnam_r() function. This information should be returned by
sysconf(_SC_GETPW_R_SIZE_MAX), but since it does not work on FreeBSD
it is necessary to guess its size. Original value is 128 and it works
for somebody, 1024 works for your environment, but it can fail for
another environment.
SUSv4 specifies Storage referenced by the structure is allocated from
the memory provided with the buffer parameter, but then tells about
groups
in EXAMPLE for getpwnam_r() Note that sysconf(_SC_GETPW_R_SIZE_MAX)
may
return -1 if there is no hard limit on the size of the buffer needed
to
store all the groups returned.
malloc() can give overhead, but that function can try to call
getpwnam_r()
with buffer allocated from stack and if getpwnam_r() failed with
ERANGE
use dynamically allocated buffer.
#define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN +
_PASSWORD_LEN + 1)
#define PWBUF_SIZE_INC 128
char bufs[2 * MAXLOGNAME + MAXPATHLEN + PASSWORD_LEN + 1 + 32];
error = getpwnam_r(lname, pwd, bufs, sizeof(bufs), pw);
if (pw != NULL) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else if (error != ERANGE)
return (GSS_S_FAILURE);
size = PWBUF_SIZE_INI;
for (;;) {
size += PWBUF_SIZE_INC;
buf = malloc(size);
if (buf == NULL)
return (GSS_S_FAILURE);
error = getpwnam_r(lname, pwd, buf, size, pw);
free(buf);
if (pw != NULL) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else {
if (error == ERANGE
size = SIZE_MAX - PWBUF_SIZE_INC)
continue;
return (GSS_S_FAILURE);
}
}
Just my opinion, but I think the above is a good approach.
(ie. First trying a fairly large buffer on the stack that
will succeed 99.99% of the time, but check for ERANGE and
loop trying progressively larger malloc'd buffers until
it stops reporting ERANGE.)
I suspect the overheads behind getpwnam_r() are larger than
the difference between using a buffer on the stack vs malloc,
so I think it should use a fairly large buffer the first time.
Personally, I might have coded it as a single do { } while(),
with the first attempt in it, but that's just personal stylistic
taste. (You can check for buf != bufs before doing a free() of it.)
And, if you wanted to be clever, the code could use a static bufsiz_hint,
which is set to the largest size needed sofar and that is used as
the initial malloc size. That way it wouldn't loop as much for a
site with huge passwd entries. (An entire bio in the GECOS field or ???)
Thanks for the review.
Another variant. This is a program that can be used for verifying
correctness of the function, just change PWBUF_SIZE_* values and put
some printfs to see when buffer is reallocated. sizehint is updated
only when malloc() succeeded.
-
#include sys/param.h
#include sys/limits.h
#include gssapi/gssapi.h
#include errno.h
#include limits.h
#include pwd.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
static int
getpwnam_r_func(const char *name, uid_t *uidp)
{
#define PWBUF_SIZE_INI (2 * MAXLOGNAME + MAXPATHLEN + _PASSWORD_LEN)
#define PWBUF_SIZE_INC 128
static size_t sizehint = PWBUF_SIZE_INI;
struct passwd pwd;
struct passwd *pw;
char *buf;
size_t size;
int error;
char lname[MAXLOGNAME];
char bufs[PWBUF_SIZE_INI];
strncpy(lname, name, sizeof(lname));
buf = bufs;
size = sizeof(bufs);
for (;;) {
error = getpwnam_r(lname, pwd, buf, size, pw);
if (buf != bufs)
free(buf);
if (pw != NULL) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else if (error != ERANGE || size SIZE_MAX - PWBUF_SIZE_INC)
return (GSS_S_FAILURE);
if (size != sizehint)
size = sizehint;
else
size += PWBUF_SIZE_INC;
buf = malloc(size);
if (buf == NULL)
return (GSS_S_FAILURE);
sizehint = size;
}
}
int
main(void)
{
const char *str[] = { man, root, q, bin, NULL };
uid_t uid;
u_int i;
for (i = 0; str[i] != NULL; ++i) {
printf(%-20s\t, str[i]);
if (getpwnam_r_func(str[i], uid) == GSS_S_COMPLETE)
printf(%u\n, uid);
else
printf(not found\n);
}
return (0);
}
-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. After this, I took a look at how PCPU stuff is used in whole kernel and found out mentioned here i386 pmap issue. So, my concern is following: 1. to verify my newly gained ideas how per CPU data should be used, 2. to decide how to change my implementation of pmap on ARM11mpcore, as it's based on i386 pmap, 3. to make FreeBSD code better. In the meanwhile, it looks that using data dedicated to one CPU on another one is OK. However, I can't agree. At least, without comments, it is misleading for anyone new in FreeBSD and makes code misty. Both threads in your description make useful progress, and computation proceeds correctly. I thought, there is only one thread in my example. One thread running on CPU1, but holding sysmaps dedicated to CPU0 instead of holding sysmaps dedicated to CPU1. So, any thread running on CPU0 must wait because the thread running on CPU1 is a thief. Futhermore, the idea that a thread on CPU1 should hold data for CPU1 is not valid. So, either some comment is missing in the code that it's OK or the using of PCPU_GET(cpuid) is unneeded and some kind of free sysmaps list can be used and it will serve better. What is wrong on almost all architectures except x86 is PCPU_ADD(), which is usually supposed by the MD code to be atomic in regard to _both_ interrupts and preemption. I said almost all, but in fact I am not aware of any architecture except x86 where it is right. And, RISCs with the load-link and store-conditional (ll/sc) primitives are well capable of doing the PCPU_ADD() correctly. You could look at the projects/counters branch, where single-instruction increment is used on x86 for dynamic per-cpu counters, and critical_enter() for other architectures. I might do some work for other arches, but the counters are correct but slower that it could be, on !x86. Thanks to help me to settle my thoughts. Svata ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: daily otput: rejected mail hosts?
On 20/02/2013 11:09, Anton Shterenlikht wrote: From mexas Thu Feb 14 09:51:50 2013 To: freebsd-questi...@freebsd.org Subject: daily otput: rejected mail hosts? Reply-To: me...@bristol.ac.uk I see in the daily output: Checking for rejected mail hosts: 172 553 check_mail system.mail exist 129 553 check_mail tsvpt014.vpt.co.uk exist 43 553 check_mail unix.dedicated.com.tr exist 43 553 check_mail ubs.net exist 43 553 check_mail localhost.localdomain exist 43 553 check_mail journal-cfp.org exist 43 553 check_mail italiasito.it exist What is that about? Is this described somewhere in sendmail manuals? I got no reply from questions@, so trying my luck here. questions@ is a better place to ask really as this isnt -CURRENT related, its part of the output of the daily periodic script /etc/periodic/daily/460.status-mail-rejects which is enabled by default. the defaults are in /etc/defaults/periodic.conf feel free to overide them in /etc/periodic.conf Vince Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs
Compiling most recent sources of CURRENT with Revision: 247040 results in a kernel crash with funny blinking characters on the screen. This happens on all systems with different amd64 Intel CPU generations at this very moment. Last working sources (reverting and booting kernel.old) is in my case FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:18:42 CET 2013 Does anyone also experience this? Another remote experimental box, equipted with a Intel Q6600 CPU, is crashed, I have to investigate this when I get to the lab later. It seems not to be related only to Sandy-Bridge-E/Ivy-Bridge CPUs. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: announcing mdoc.su, short manual page URLs
On Tue, Feb 19, 2013 at 12:27:01AM -0800, Constantine A. Murenin wrote:
Dear freebsd-{chat,current,doc}@,
I would like to announce and introduce URL:http://mdoc.su/,
a deterministic URL shortener for BSD manual pages,
written entirely in nginx.conf.
It supports several address schemes, for example:
http://mdoc.su/f/zfs
http://mdoc.su/f/zfs.8
http://mdoc.su/f/8/zfs
http://mdoc.su/freebsd/zfs
http://mdoc.su/FreeBSD/zfs
http://mdoc.su/d/hammer.5
http://mdoc.su/d/hammer.8
etc.
Very col!
One question: is the os version accessible comewhere, i.e. can I ask for
a manpage from a specific version of FreeBSD?
I have to disagree with Darren Pilgrim however, this is not slight abuse
of rewrite rules but putting rewrite rules to better use :-)
Kind regards,
Paul Schenkeveld
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
No ZFS when loading modules from loeader prompt
At the moment, the most recent kernel of FreeBSD 10.0-CURRENT crashes on all of the boxes I compiled the most recent kernel sources (build a world ncluding kernel, not only the kernel, so the system is consistent). At the loader prompt, I need to unload the buggy kernel and load the old working one via load /boot/kernel.old/kernel Then I load also the ZFS related modules load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko Issuing boot at the end of that stage boots the kernel - the old one -successfully - but there is no working ZFS and no ZFS volume gets mounted although the rc.conf is executed correctly. What am I doing wrong at that point? Why isn't ZFS run and mount properly? Luckily, just booting the old kernel via load /boot/kernel.old/kernel and booting it having zfs_enable=YES in /etc/rc.conf set loads the /boot/kernel/opensolaris/zfs stuff - usually those kernel modules are out of sync compared to kernel.old but in this case its just a coincidence that this works. So, what is the proper way to have ZFS mounted in an emergency case when I'm in need of loading a working kernel manually? Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: r246916 probably broke amd64 build
On Wed, Feb 20, 2013 at 10:54 AM, Dag-Erling Smørgrav d...@des.no wrote: Davide Italiano dav...@freebsd.org writes: Unfortunately tinderbox didn't catch this bug because it's triggered only when gcc is used to build kernel. In this particular case, the broken code is only built on platforms which default to clang. Otherwise, it would have been caught when building one of the platforms that default to gcc. I see. In fact this was a very unlucky case (problem in MD code, for a platform that default to clang). The tinderbox servers simply donn't have enough CPU power to build all possible combinations. There isn't even enough for a standard build of all platforms at a reasonable frequency. I have a stack of new servers, but nowhere to host them - see the donations wantlist for details. DES -- Dag-Erling Smørgrav - d...@des.no Sorry I can't help you with that. Thanks, Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 16.02.2013 12:07, Joel Dahl wrote: On 14-02-2013 20:37, Joel Dahl wrote: On 12-02-2013 8:51, Hans Petter Selasky wrote: On Monday 11 February 2013 23:21:05 Joel Dahl wrote: On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. Hi, I don't see any relevant USB+UMASS patches for your issue in this interval, but many patches in the SCSI/CAM area. I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. 237478 is the following commit by mav@: r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). It allows to remove number of duplicate checks from several places. So, mav@ haven't replied yet so I did some more investigation. I collected all the USB sticks I had in the office (5 in total, all Kingston but different size and models) and tried a memstick installation with each stick. Turns out r237478 only breaks memstick installation in combination with certain USB sticks: # Works: da0: Kingston DataTraveler 2.0 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 7664MB (15695872 512 byte sectors: 255H 63S/T 977C) da0: Kingston DataTraveler 2.0 PMAP Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1906MB (3903488 512 byte sectors: 255H 63S/T 242C) # Does not work: da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 15295MB (31324160 512 byte sectors: 255H 63S/T 1949C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 242C) It seems that only USB sticks labeled as Kingston DataTraveler G3 are affected by r237478 (in my limited testing, at least). This particular model is what you get if you buy the cheapest Kingston model on the market right now. I've reviewed that change once more and I see no flaws in it. My only guess is that it changes something innocent or unrelated in request order that confuses flash firmware, making it stuck and return errors without SCSI sense information. In log provided I see that when device first detected, it normally reports its size. But later, possibly after some command (SYNCHRONIZE CACHE?, PREVENT ALLOW MEDIUM REMOVAL?), it starts to behave wrong. Wrong answer to another READ CAPACITY request causes got CAM status 0xXX message and following device loss. Unfortunately I can't reproduce the problem. All USB sticks I have are working fine without any problems with HEAD system. If I could, I would try to log all commands sent to the stick to find one after which problem begins. Commands could be logged either on CAM layer by running `camcontrol debug -IPpc all` before plugging stick in and `camcontrol debug off` after (you may want to do it in single-user mode or without syslog running to avoid logging activity on other CAM disks), or probably somehow on umass layer, or with usbdump on raw USB layer (in last case some more knowledge will be needed to interpret result). -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov pcpu reg, r0 add offset of pc_curthread, r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld pcpu reg, r1 which is fine. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No ZFS when loading modules from loeader prompt
Sounds like a perfect use case for Boot Environments. Create a new BE, install the new kernel into it, set it as the default, reboot. If it fails, you manually set the previous BE as the default, and reboot. That way, your known-good, working environment is never affected. beadm should be part of 10-CURRENT. If not, there should be a port for it. On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann ohart...@zedat.fu-berlin.dewrote: At the moment, the most recent kernel of FreeBSD 10.0-CURRENT crashes on all of the boxes I compiled the most recent kernel sources (build a world ncluding kernel, not only the kernel, so the system is consistent). At the loader prompt, I need to unload the buggy kernel and load the old working one via load /boot/kernel.old/kernel Then I load also the ZFS related modules load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko Issuing boot at the end of that stage boots the kernel - the old one -successfully - but there is no working ZFS and no ZFS volume gets mounted although the rc.conf is executed correctly. What am I doing wrong at that point? Why isn't ZFS run and mount properly? Luckily, just booting the old kernel via load /boot/kernel.old/kernel and booting it having zfs_enable=YES in /etc/rc.conf set loads the /boot/kernel/opensolaris/zfs stuff - usually those kernel modules are out of sync compared to kernel.old but in this case its just a coincidence that this works. So, what is the proper way to have ZFS mounted in an emergency case when I'm in need of loading a working kernel manually? Regards, Oliver -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs
O. Hartmann wrote on 20.02.2013 18:36: Compiling most recent sources of CURRENT with Revision: 247040 results in a kernel crash with funny blinking characters on the screen. This happens on all systems with different amd64 Intel CPU generations at this very moment. Last working sources (reverting and booting kernel.old) is in my case FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:18:42 CET 2013 Does anyone also experience this? Another remote experimental box, equipted with a Intel Q6600 CPU, is crashed, I have to investigate this when I get to the lab later. It seems not to be related only to Sandy-Bridge-E/Ivy-Bridge CPUs. Regards, Oliver I just updated from r246618 to r247044 (kernel only, built with old world) and everything works as expected. I have: CPU: Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz (2394.62-MHz K8-class CPU) I may build new world and build new kernel with it if it's may help to reproduce. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[patch] remove negative socklen_t checks
Hi.
These checks are useless after the address length argument is converted
to socklen_t (up to SUSv2). Any objections?
Index: lib/libc/sys/accept.2
===
--- lib/libc/sys/accept.2 (revision 245745)
+++ lib/libc/sys/accept.2 (working copy)
@@ -28,7 +28,7 @@
.\ @(#)accept.2 8.2 (Berkeley) 12/11/93
.\ $FreeBSD$
.\
-.Dd December 11, 1993
+.Dd February 20, 2013
.Dt ACCEPT 2
.Os
.Sh NAME
@@ -154,10 +154,6 @@ The descriptor references a file, not a socket.
.It Bq Er EINVAL
.Xr listen 2
has not been called on the socket descriptor.
-.It Bq Er EINVAL
-The
-.Fa addrlen
-argument is negative.
.It Bq Er EFAULT
The
.Fa addr
Index: sys/kern/uipc_syscalls.c
===
--- sys/kern/uipc_syscalls.c(revision 246354)
+++ sys/kern/uipc_syscalls.c(working copy)
@@ -353,8 +353,6 @@ kern_accept(struct thread *td, int s, struct socka
if (name) {
*name = NULL;
- if (*namelen 0)
- return (EINVAL);
}
AUDIT_ARG_FD(s);
@@ -1327,8 +1325,6 @@ kern_setsockopt(td, s, level, name, val, valseg, v
if (val == NULL valsize != 0)
return (EFAULT);
- if ((int)valsize 0)
- return (EINVAL);
sopt.sopt_dir = SOPT_SET;
sopt.sopt_level = level;
@@ -1406,8 +1402,6 @@ kern_getsockopt(td, s, level, name, val, valseg, v
if (val == NULL)
*valsize = 0;
- if ((int)*valsize 0)
- return (EINVAL);
sopt.sopt_dir = SOPT_GET;
sopt.sopt_level = level;
@@ -1484,9 +1478,6 @@ kern_getsockname(struct thread *td, int fd, struct
socklen_t len;
int error;
- if (*alen 0)
- return (EINVAL);
-
AUDIT_ARG_FD(fd);
error = getsock_cap(td-td_proc-p_fd, fd, CAP_GETSOCKNAME, fp, NULL);
if (error)
@@ -1584,9 +1575,6 @@ kern_getpeername(struct thread *td, int fd, struct
socklen_t len;
int error;
- if (*alen 0)
- return (EINVAL);
-
AUDIT_ARG_FD(fd);
error = getsock_cap(td-td_proc-p_fd, fd, CAP_GETPEERNAME, fp, NULL);
if (error)
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs
On 02/20/13 18:17, Ruslan Makhmatkhanov wrote: O. Hartmann wrote on 20.02.2013 18:36: Compiling most recent sources of CURRENT with Revision: 247040 results in a kernel crash with funny blinking characters on the screen. This happens on all systems with different amd64 Intel CPU generations at this very moment. Last working sources (reverting and booting kernel.old) is in my case FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:18:42 CET 2013 Does anyone also experience this? Another remote experimental box, equipted with a Intel Q6600 CPU, is crashed, I have to investigate this when I get to the lab later. It seems not to be related only to Sandy-Bridge-E/Ivy-Bridge CPUs. Regards, Oliver I just updated from r246618 to r247044 (kernel only, built with old world) and everything works as expected. I have: CPU: Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz (2394.62-MHz K8-class CPU) I may build new world and build new kernel with it if it's may help to reproduce. My C2D Q6600 quits with a trap 16 or 18 (I have all withness and debug support deactivated at the moment). The Intel i3-3220 crashes with blinking characters on the screen (I use the built-in GPU for console displaying). A C2D 8400 - same setup, crashes also very early while booting. The whole system/world is built with CLANG, this is the setting of the /etc/src.conf: CPUTYPE?= native # CFLAGS+=-O3 -pipe -march=native # for Kernel COPTFLAGS+= -O3 -pipe -march=native # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 # WITH_CLANG_EXTRAS= YES WITH_CLANG_FULL=YES WITH_LLVM= YES WITH_LLVM_EXTRAS= YES # WITH_LIBCPLUSPLUS= YES # WITH_BIND_LARGE_FILE= YES WITH_BIND_SIGCHASE= YES WITH_BIND_LIBS= YES # WITH_IDEA= YES # #WITH_ICONV=YES WITH_BSD_GREP= YES WITH_BSDCONFIG= YES WITH_BSD_SORT= YES WITH_BSD_PATCH= YES # #WITH_OFED= YES WITH_NAND= YES WITH_NMTREE=YES #WITH_BMAKE=YES #WITH_CTF= YES # MALLOC_PRODUCTION= YES # PORTS_MODULES= emulators/virtualbox-ose-kmod #PORTS_MODULES+=x11/nvidia-driver I have a custom kernel, will try also the GENERIC and report in later. Oliver signature.asc Description: OpenPGP digital signature
Re: [patch] remove negative socklen_t checks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/20/13 09:19, Sergey Kandaurov wrote:
Hi.
These checks are useless after the address length argument is
converted to socklen_t (up to SUSv2). Any objections?
No objection in general but there is a minor style issue, see below.
[...]
Index: sys/kern/uipc_syscalls.c
===
- --- sys/kern/uipc_syscalls.c(revision 246354)
+++ sys/kern/uipc_syscalls.c(working copy) @@ -353,8 +353,6 @@
kern_accept(struct thread *td, int s, struct socka
if (name) { *name = NULL; - if (*namelen 0) -
return (EINVAL); }
The { } for if () is no longer needed now per style(9).
By the way I wonder why there is no compiler warning for this -- or do
we compile kernel without signedness warnings? Just curious...
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJRJRkcAAoJEG80Jeu8UPuzagkIAICE9uJzbLS8MvPPYLEMCop3
mamlq7AOJSpGfEyBzB0CZV2badJC91LEtUGADMN0CANPbvX6EpDsYoPygpXBuxei
etNelbp1+9jbqwV6yK+9FVCioRiMMLrPKkyh02+s1ZhWCf6kjz3Xl9MEYKUKYuV1
ay7xLcLnQMxOzf1oS7Sovm6NsIFnDC06WZ0PZDFdBtv7typtGblw3rrgWMsOnshL
x35C1UC8NgLnauMEOhX6Vr1zeRz+hqfw+YauCi/P+3chxfUgpe6XR551IN2h9xBU
mYTNEjLkRgX8u5sCHYGB16r/OZ3X59w1sJH/21ayrHuF0gNEmQbnMlBnA/krH94=
=iiGi
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Wed, Feb 20, 2013 at 10:22:29AM -0500, John Baldwin wrote: On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov pcpu reg, r0 add offset of pc_curthread, r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld pcpu reg, r1 which is fine. I just looked at the arm pcpu.h, and indeed the curthread falls back to the default implementation from sys/pcpu.h, which is get_pcpu()-pc_curthread. This looks buggy for SMP, does our arm port support any multi-cpu configuration ? pgpoLvGDsLIGn.pgp Description: PGP signature
Re: [patch] remove negative socklen_t checks
On 20 February 2013 22:42, Xin Li delp...@delphij.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/20/13 09:19, Sergey Kandaurov wrote:
Hi.
These checks are useless after the address length argument is
converted to socklen_t (up to SUSv2). Any objections?
No objection in general but there is a minor style issue, see below.
[...]
Index: sys/kern/uipc_syscalls.c
===
- --- sys/kern/uipc_syscalls.c(revision 246354)
+++ sys/kern/uipc_syscalls.c(working copy) @@ -353,8 +353,6 @@
kern_accept(struct thread *td, int s, struct socka
if (name) { *name = NULL; - if (*namelen 0) -
return (EINVAL); }
The { } for if () is no longer needed now per style(9).
Indeed, thanks.
By the way I wonder why there is no compiler warning for this -- or do
we compile kernel without signedness warnings? Just curious...
No, they are (at least with clang). That's how I came there.
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-Werror /usr/src/sys/kern/uipc_syscalls.c
/usr/src/sys/kern/uipc_syscalls.c:356:16: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
if (*namelen 0)
^ ~
/usr/src/sys/kern/uipc_syscalls.c:1487:12: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
if (*alen 0)
~ ^ ~
/usr/src/sys/kern/uipc_syscalls.c:1587:12: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
if (*alen 0)
~ ^ ~
Other two warnings are obviously not triggered because of explicit
cast to int (eek!).
Thanks for review.
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Wednesday, February 20, 2013 2:27:39 pm Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 10:22:29AM -0500, John Baldwin wrote: On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov pcpu reg, r0 add offset of pc_curthread, r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld pcpu reg, r1 which is fine. I just looked at the arm pcpu.h, and indeed the curthread falls back to the default implementation from sys/pcpu.h, which is get_pcpu()-pc_curthread. This looks buggy for SMP, does our arm port support any multi-cpu configuration ? Not in HEAD. There is a projects branch for armv6 I think that does. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PathScale EKO Path 5 not for FreeBSD anymore?
On 20/02/2013 13:00, freebsd-current-requ...@freebsd.org wrote: Gathering informations from many places - as it is with WHICH PROFESSIONAL COMPILER WORKS ON FREEBSD WITH PROFESSIONAL HIGH PERFORMANCE MATH LIBS is horrible and time consuming. try it on Google with the tag Linux makes you happy within seconds. So true...I found that when the first search for a FreeBSD thing doesn't yield results, I search for Linux and then either check if the results work here or, having some well known name, look for alternatives. -- Twoje radio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Wed, 2013-02-20 at 14:32 -0500, John Baldwin wrote: On Wednesday, February 20, 2013 2:27:39 pm Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 10:22:29AM -0500, John Baldwin wrote: On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov pcpu reg, r0 add offset of pc_curthread, r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld pcpu reg, r1 which is fine. I just looked at the arm pcpu.h, and indeed the curthread falls back to the default implementation from sys/pcpu.h, which is get_pcpu()-pc_curthread. This looks buggy for SMP, does our arm port support any multi-cpu configuration ? Not in HEAD. There is a projects branch for armv6 I think that does. There isn't anything I've heard of that makes it all the way to single user mode yet with multiple cores enabled. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
-CURRENT userland regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRJUrOAAoJEG80Jeu8UPuzJBsIAMi/2gkOd2ApEGWRi7DgHu5c MVRBIgmGW72BfQUWGkNyBCg0nsOO67oKpxMPYx0xzSKMvt2vAohS4+55VuytjOKF mdKjs2wSVeMSYguJ5+OtM3cUxK1OuYRgqla6cvW5DCKdhF4WPFK27+tRgYlGTkzw poGgznOTP2jJlPjICQI+VXkSNrI46xRJqxM3d3/jeYjjujGDOKTthYZJsPNxkTqh mY3ng0hv18vFVxhQMDceRnaXl9QIYQKmzTPc1pnmF21GMDgpHeSfWDdPwvwYDVmO 04Jl8p0jyjfZvgpLddMoBy9GWfMLDY/qwYRE8sGYqWGQqR4y2dFXZTPZZN/YmO8= =0shF -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
On Wed, Feb 20, 2013 at 02:14:38PM -0800, Xin Li wrote: It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. There was a thread earlier today titled: Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs if this helps. I am not sure if the report was isolated to that specific revision, or if it was the revision of -CURRENT at the time. Glen pgph__urp_1WP.pgp Description: PGP signature
Re: -CURRENT userland regression
On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? pgpcbeGcTv8OO.pgp Description: PGP signature
Re: -CURRENT userland regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/20/13 14:25, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? It would take some time to bi-sect as one needs to do full world/kernel build. The only thing I can say definitely is that something from userland was broken within the (246858,247057] range. I'm compiling 246957 right now. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRJU5RAAoJEG80Jeu8UPuzvh0H/3gL+Og4fmzZ8TYrkhseuIS4 Pll3sWdIZnCqorfUV2ZFiRzV9Awvt4KRfl3m15lCM6ornl6jdVilQq9o07cfTQFK mvkD6J08nraG/7D/raSzQ9oO4uTUYLVkzoaCDDa3Lz6fdpoIQ6JvuzcvOAsV+DJa DjjKCIB6bOITaA+boyvTAsMwkv437Mz4Ze2eVqUbexwhWktHkzlROhX/H2Cz7CQn fMNxpZFntjhEszi5HRYXQXVkdr/M0t92FpykZQCEXIClyw6tdXWEPJcMZFWVPRip Rg6AR9Iys/BhlMJRUl5BzVK0eOB4Jx2PS1pckAduXBKykIrpsEIqY2Ybf1I= =0Hzl -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
On 02/20/13 14:25, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? I upgraded from a month old (approx.) head to r247054 and ran into this problem. I haven't tried bisecting as I need a running system right now. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/20/13 14:25, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? It would take some time to bi-sect as one needs to do full world/kernel build. The only thing I can say definitely is that something from userland was broken within the (246858,247057] range. I'm compiling 246957 right now. My first guess would be r247047, but I did booted the kernel+world with this change applied, on amd64. Hm, I booted on the machine with serial console. pgpUqhGlB2tVE.pgp Description: PGP signature
Re: -CURRENT userland regression
On Wed, Feb 20, 2013 at 02:33:23PM -0800, Navdeep Parhar wrote: On 02/20/13 14:25, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? I upgraded from a month old (approx.) head to r247054 and ran into this problem. I haven't tried bisecting as I need a running system right now. ... I did not see such a problem after building booting: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #817 r247030M/247030: Wed Feb 20 08:13:58 PST 2013 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 built with clang. FWIW. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpGOQLgq9XAB.pgp Description: PGP signature
Re: -CURRENT userland regression
On Wed, Feb 20, 2013 at 02:33:23PM -0800, Navdeep Parhar wrote: On 02/20/13 14:25, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? I upgraded from a month old (approx.) head to r247054 and ran into this problem. I haven't tried bisecting as I need a running system right now. BTW, does the loader fails, or is it the kernel where the problems start appearing ? pgpwwIMLtLKoB.pgp Description: PGP signature
Re: -CURRENT userland regression
On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: It would take some time to bi-sect as one needs to do full world/kernel build. The only thing I can say definitely is that something from userland was broken within the (246858,247057] range. I'm compiling 246957 right now. I have laptop:kargl[201] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247049M: Wed Feb 20 11:05:4 running without a problem. It's an older cpu, CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fd Family = 0x6 Model = 0xf Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics I've rebuilt several ports on this laptop since rebooting with ports/distfile located on a usb mounted UFS2 filesystem. Do note, that everything is compiled with gcc as clang is explicitly disabled with WITHOUT_CLANG in /etc/make.conf. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
On Wed, Feb 20, 2013 at 02:48:53PM -0800, Steve Kargl wrote: On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: It would take some time to bi-sect as one needs to do full world/kernel build. The only thing I can say definitely is that something from userland was broken within the (246858,247057] range. I'm compiling 246957 right now. I have laptop:kargl[201] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247049M: Wed Feb 20 11:05:4 What arch is it ? amd64 or i386 ? running without a problem. It's an older cpu, CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fd Family = 0x6 Model = 0xf Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics I've rebuilt several ports on this laptop since rebooting with ports/distfile located on a usb mounted UFS2 filesystem. Do note, that everything is compiled with gcc as clang is explicitly disabled with WITHOUT_CLANG in /etc/make.conf. -- Steve pgpYigmIZXO15.pgp Description: PGP signature
Re: -CURRENT userland regression
On 02/20/13 14:47, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:33:23PM -0800, Navdeep Parhar wrote: On 02/20/13 14:25, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? I upgraded from a month old (approx.) head to r247054 and ran into this problem. I haven't tried bisecting as I need a running system right now. BTW, does the loader fails, or is it the kernel where the problems start appearing ? The problem occurs well after the kernel is up and running. The last messages that were readable were from ugen/uhub and ada0. The rest was garbled and the system froze solid something after that. I tried pinging it but it wasn't reachable so this wasn't a case where the console was trashed but system was running. This is amd64 built with clang. I have dual consoles - serial and VGA. FreeBSD trantor 10.0-CURRENT FreeBSD 10.0-CURRENT #26: Wed Feb 20 13:18:48 PST 2013 root@trantor:/usr/obj/usr/src/sys/TOEKTR amd64 Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
On Thu, Feb 21, 2013 at 12:51:54AM +0200, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:48:53PM -0800, Steve Kargl wrote: On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: It would take some time to bi-sect as one needs to do full world/kernel build. The only thing I can say definitely is that something from userland was broken within the (246858,247057] range. I'm compiling 246957 right now. I have laptop:kargl[201] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247049M: Wed Feb 20 11:05:4 What arch is it ? amd64 or i386 ? i386. Also note, I do not use modules, so all devices are compiled into the kernel. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/20/13 14:37, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/20/13 14:25, Konstantin Belousov wrote: On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? It would take some time to bi-sect as one needs to do full world/kernel build. The only thing I can say definitely is that something from userland was broken within the (246858,247057] range. I'm compiling 246957 right now. My first guess would be r247047, but I did booted the kernel+world with this change applied, on amd64. Hm, I booted on the machine with serial console. I think it's unlikely -- I have r247057 of sys/ which worked fine... userland 246957 works good by the way. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRJVldAAoJEG80Jeu8UPuzxBcH/AntMKSKAou10EU8/PbZEAHH q7A4enMQll13UuG9DzcXoQLEdmy+oCTpOcCn1Fe7YcY/ykvKgZhSUgTwwmZseL/N vHRgLH44ctAHEZMGW50oAVLgpR4ac4/dwbqeCThFwMb6C0wwRgo2SJD1w5GW8TMw JI40BeGdSEggJVOuYf+GJh433Wg5IhhxTsVkd5DXNrqjY5QfbtFwWJmUS7DKCb4X Ds153GhyxVJ2YXHBp6HjJ8ccmocBZ+plnda9uNTTVYcvklbQDzYWIFmxHsUO1OBq rXXSh93PJ7yJh/vrSFncDyxxpjfEfqlpCyM60Htd6CaFri1JbAn1kl4OmaDrlt8= =i2Ev -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Possible bug in NFSv4 with krb5p security?
Andrey Simonnenko wrote:
On Tue, Feb 19, 2013 at 08:52:49PM -0500, Rick Macklem wrote:
I cannot find how to get information about maximum buffer size for
the getpwnam_r() function. This information should be returned by
sysconf(_SC_GETPW_R_SIZE_MAX), but since it does not work on
FreeBSD
it is necessary to guess its size. Original value is 128 and it
works
for somebody, 1024 works for your environment, but it can fail for
another environment.
SUSv4 specifies Storage referenced by the structure is allocated
from
the memory provided with the buffer parameter, but then tells
about
groups
in EXAMPLE for getpwnam_r() Note that
sysconf(_SC_GETPW_R_SIZE_MAX)
may
return -1 if there is no hard limit on the size of the buffer
needed
to
store all the groups returned.
malloc() can give overhead, but that function can try to call
getpwnam_r()
with buffer allocated from stack and if getpwnam_r() failed with
ERANGE
use dynamically allocated buffer.
#define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN +
_PASSWORD_LEN + 1)
#define PWBUF_SIZE_INC 128
char bufs[2 * MAXLOGNAME + MAXPATHLEN + PASSWORD_LEN + 1 + 32];
error = getpwnam_r(lname, pwd, bufs, sizeof(bufs), pw);
if (pw != NULL) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else if (error != ERANGE)
return (GSS_S_FAILURE);
size = PWBUF_SIZE_INI;
for (;;) {
size += PWBUF_SIZE_INC;
buf = malloc(size);
if (buf == NULL)
return (GSS_S_FAILURE);
error = getpwnam_r(lname, pwd, buf, size, pw);
free(buf);
if (pw != NULL) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else {
if (error == ERANGE
size = SIZE_MAX - PWBUF_SIZE_INC)
continue;
return (GSS_S_FAILURE);
}
}
Just my opinion, but I think the above is a good approach.
(ie. First trying a fairly large buffer on the stack that
will succeed 99.99% of the time, but check for ERANGE and
loop trying progressively larger malloc'd buffers until
it stops reporting ERANGE.)
I suspect the overheads behind getpwnam_r() are larger than
the difference between using a buffer on the stack vs malloc,
so I think it should use a fairly large buffer the first time.
Personally, I might have coded it as a single do { } while(),
with the first attempt in it, but that's just personal stylistic
taste. (You can check for buf != bufs before doing a free() of it.)
And, if you wanted to be clever, the code could use a static
bufsiz_hint,
which is set to the largest size needed sofar and that is used as
the initial malloc size. That way it wouldn't loop as much for a
site with huge passwd entries. (An entire bio in the GECOS field or
???)
Thanks for the review.
Another variant. This is a program that can be used for verifying
correctness of the function, just change PWBUF_SIZE_* values and put
some printfs to see when buffer is reallocated. sizehint is updated
only when malloc() succeeded.
-
#include sys/param.h
#include sys/limits.h
#include gssapi/gssapi.h
#include errno.h
#include limits.h
#include pwd.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
static int
getpwnam_r_func(const char *name, uid_t *uidp)
{
#define PWBUF_SIZE_INI (2 * MAXLOGNAME + MAXPATHLEN + _PASSWORD_LEN)
#define PWBUF_SIZE_INC 128
static size_t sizehint = PWBUF_SIZE_INI;
struct passwd pwd;
struct passwd *pw;
char *buf;
size_t size;
int error;
char lname[MAXLOGNAME];
char bufs[PWBUF_SIZE_INI];
strncpy(lname, name, sizeof(lname));
buf = bufs;
size = sizeof(bufs);
for (;;) {
error = getpwnam_r(lname, pwd, buf, size, pw);
if (buf != bufs)
free(buf);
if (pw != NULL) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else if (error != ERANGE || size SIZE_MAX - PWBUF_SIZE_INC)
return (GSS_S_FAILURE);
if (size != sizehint)
size = sizehint;
else
size += PWBUF_SIZE_INC;
buf = malloc(size);
if (buf == NULL)
return (GSS_S_FAILURE);
sizehint = size;
}
}
All looks fine to me. (Before my mailer messed with the whitespace;-)
Thanks, rick
ps: I will commit it in April, unless someone else does so sooner.
int
main(void)
{
const char *str[] = { man, root, q, bin, NULL };
uid_t uid;
u_int i;
for (i = 0; str[i] != NULL; ++i) {
printf(%-20s\t, str[i]);
if (getpwnam_r_func(str[i], uid) == GSS_S_COMPLETE)
printf(%u\n, uid);
else
printf(not found\n);
}
return (0);
}
-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Re: PathScale EKO Path 5 not for FreeBSD anymore?
I've been talking to others and it seems that several of us are convinced that BSD is back on the uptake, so I wouldn't be so quick to mark its demise. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
-CURRENT userland regression
Hi, I have the same issues with FreeBSD 10.0-CURRENT #0 r247035. I completed the buildworld process and was able to install kernel. When I rebooted and attmpted to installworld, I got the same surprise that everyone got. I was able to get in the system using SAFE MODE. FreeBSD 10.0-CURRENT #0 r247035: Wed Feb 20 09:57:43 EST 2013 derrick@zeus:/usr/obj/usr/src/sys/ZEUS amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (2494.39-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping=9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x7fbae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF Standard Extended Features=0x281GSFSBASE,SMEP,ENHMOVSB TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16421789696 (15661 MB) Event timer LAPIC quality 600 ACPI APIC Table: TOSINV TOSINV00 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x3000-0x303f mem 0xb800-0xb83f,0xb000-0xb7ff irq 16 at device 2.0 on pci0 agp0: IvyBridge mobile GT2 IG on vgapci0 agp0: aperture size is 128M, detected 32764k stolen memory acpi_video0: ACPI video extension on vgapci0 V/r Derrick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2013-02-21 04:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 04:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 04:10:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-21 04:10:20 - cleaning the object tree TB --- 2013-02-21 04:10:20 - /usr/local/bin/svn stat /src TB --- 2013-02-21 04:10:24 - At svn revision 247073 TB --- 2013-02-21 04:10:25 - building world TB --- 2013-02-21 04:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 04:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 04:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 04:10:25 - SRCCONF=/dev/null TB --- 2013-02-21 04:10:25 - TARGET=arm TB --- 2013-02-21 04:10:25 - TARGET_ARCH=arm TB --- 2013-02-21 04:10:25 - TZ=UTC TB --- 2013-02-21 04:10:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 04:10:25 - cd /src TB --- 2013-02-21 04:10:25 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 04:10:30 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 05:59:30 UTC 2013 TB --- 2013-02-21 05:59:30 - generating LINT kernel config TB --- 2013-02-21 05:59:30 - cd /src/sys/arm/conf TB --- 2013-02-21 05:59:30 - /usr/bin/make -B LINT TB --- 2013-02-21 05:59:30 - cd /src/sys/arm/conf TB --- 2013-02-21 05:59:30 - /usr/sbin/config -m LINT TB --- 2013-02-21 05:59:30 - building LINT kernel TB --- 2013-02-21 05:59:30 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 05:59:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 05:59:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 05:59:30 - SRCCONF=/dev/null TB --- 2013-02-21 05:59:30 - TARGET=arm TB --- 2013-02-21 05:59:30 - TARGET_ARCH=arm TB --- 2013-02-21 05:59:30 - TZ=UTC TB --- 2013-02-21 05:59:30 - __MAKE_CONF=/dev/null TB --- 2013-02-21 05:59:30 - cd /src TB --- 2013-02-21 05:59:30 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 05:59:30 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppc/ppc.c
Kernel hang r247079 mps/vfs/zfs?
I was testing a patch on r246300 or so, and wanted to see if it would apply cleanly to a newer copy of HEAD. Well it did, except I had a hang at boot, shortly after ZFS version and the last scsi devices appear. This easily could have been related to the patch I was testing, so I wiped /usr/src/ and /usr/obj (after booting kernel.old) and rebuilt world and kernel cleanly. I assumed that would resolve the issue, but it did not. The hang happens right after zfs is announced, and the last da devices (some of which are usb) are reported. It comes before the noisy output of mps. Hang is complete, and single user or verbose don't yield much. I'm having trouble exfiltrating a dmesg from it, but it may be unrelated to the userland issues reported earlier, as single user does not resolve it for me. The svn up was at 11:20 pacific (GMT +8). Anyone else seeing similar issues? Hardware is an LSI mps device, 9210 crossflashed m1015. Pool is a zfs mirror. Works fine booting from r246300 kernel. Motherboard is an AMD Tyan. Pulling USB headers off the board didn't resolve it. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2013-02-21 04:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 04:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 04:10:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-02-21 04:10:20 - cleaning the object tree TB --- 2013-02-21 04:10:20 - /usr/local/bin/svn stat /src TB --- 2013-02-21 04:10:24 - At svn revision 247073 TB --- 2013-02-21 04:10:25 - building world TB --- 2013-02-21 04:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 04:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 04:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 04:10:25 - SRCCONF=/dev/null TB --- 2013-02-21 04:10:25 - TARGET=i386 TB --- 2013-02-21 04:10:25 - TARGET_ARCH=i386 TB --- 2013-02-21 04:10:25 - TZ=UTC TB --- 2013-02-21 04:10:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 04:10:25 - cd /src TB --- 2013-02-21 04:10:25 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 04:10:30 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 06:55:18 UTC 2013 TB --- 2013-02-21 06:55:18 - generating LINT kernel config TB --- 2013-02-21 06:55:18 - cd /src/sys/i386/conf TB --- 2013-02-21 06:55:18 - /usr/bin/make -B LINT TB --- 2013-02-21 06:55:18 - cd /src/sys/i386/conf TB --- 2013-02-21 06:55:18 - /usr/sbin/config -m LINT TB --- 2013-02-21 06:55:18 - building LINT kernel TB --- 2013-02-21 06:55:18 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 06:55:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 06:55:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 06:55:18 - SRCCONF=/dev/null TB --- 2013-02-21 06:55:18 - TARGET=i386 TB --- 2013-02-21 06:55:18 - TARGET_ARCH=i386 TB --- 2013-02-21 06:55:18 - TZ=UTC TB --- 2013-02-21 06:55:18 - __MAKE_CONF=/dev/null TB --- 2013-02-21 06:55:18 - cd /src TB --- 2013-02-21 06:55:18 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 06:55:18 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 07:05:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 07:05:56 - ERROR: failed to build LINT kernel TB --- 2013-02-21 07:05:56 - 8486.48 user 1311.22 system 10535.43 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2013-02-21 04:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 04:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 04:10:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-02-21 04:10:20 - cleaning the object tree TB --- 2013-02-21 04:10:20 - /usr/local/bin/svn stat /src TB --- 2013-02-21 04:10:24 - At svn revision 247073 TB --- 2013-02-21 04:10:25 - building world TB --- 2013-02-21 04:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 04:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 04:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 04:10:25 - SRCCONF=/dev/null TB --- 2013-02-21 04:10:25 - TARGET=amd64 TB --- 2013-02-21 04:10:25 - TARGET_ARCH=amd64 TB --- 2013-02-21 04:10:25 - TZ=UTC TB --- 2013-02-21 04:10:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 04:10:25 - cd /src TB --- 2013-02-21 04:10:25 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 04:10:30 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu Feb 21 07:28:27 UTC 2013 TB --- 2013-02-21 07:28:27 - generating LINT kernel config TB --- 2013-02-21 07:28:27 - cd /src/sys/amd64/conf TB --- 2013-02-21 07:28:27 - /usr/bin/make -B LINT TB --- 2013-02-21 07:28:27 - cd /src/sys/amd64/conf TB --- 2013-02-21 07:28:27 - /usr/sbin/config -m LINT TB --- 2013-02-21 07:28:27 - building LINT kernel TB --- 2013-02-21 07:28:27 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 07:28:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 07:28:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 07:28:27 - SRCCONF=/dev/null TB --- 2013-02-21 07:28:27 - TARGET=amd64 TB --- 2013-02-21 07:28:27 - TARGET_ARCH=amd64 TB --- 2013-02-21 07:28:27 - TZ=UTC TB --- 2013-02-21 07:28:27 - __MAKE_CONF=/dev/null TB --- 2013-02-21 07:28:27 - cd /src TB --- 2013-02-21 07:28:27 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 07:28:27 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 07:39:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 07:39:20 - ERROR: failed to build LINT kernel TB --- 2013-02-21 07:39:20 - 9819.45 user 1699.91 system 12539.96 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
