Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")
On Mon, Jul 12, 1999 at 07:09:58PM -0700, Mike Smith wrote:
> > Although function calls are more expensive than inline code,
> > they aren't necessarily a lot more so, and function calls to
> > non-locked RMW operations are certainly much cheaper than
> > inline locked RMW operations.
>
> This is a fairly key statement in context, and an opinion here would
> count for a lot; are function calls likely to become more or less
> expensive in time?
Others have answered this question, but I thought I'd point out
that there is another alternative that is likely to be faster
than indirect function calls on some architectures: inline
branched code. So you still have a global variable selecting
locked/non-locked, but it's a boolean, rather than a pointer.
Your atomic macros are then { if (atomic_lock) asm("lock;foo");
else asm ("foo"); }
You might be interested in the paper:
"Efficient Dynamic Dispatch without Virtual Function Tables. The
SmallEiffel Compiler." Olivier ZENDRA, Dominique COLNET, Suzanne
COLLIN. 12th Annual ACM SIGPLAN Conference on Object-Oriented
Programming, Systems, Languages, and Applications (OOPSLA'97),
Volume 32, Issue 10 - Atlanta, GA, USA, October 1997, pages 125-141.
http://SmallEiffel.loria.fr/papers/papers.html#OOPSLA97
as a justification for that approach.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")
On Mon, Jul 12, 1999 at 10:38:03PM -0700, Mike Smith wrote:
> I said:
> > than indirect function calls on some architectures: inline
> > branched code. So you still have a global variable selecting
> > locked/non-locked, but it's a boolean, rather than a pointer.
> > Your atomic macros are then { if (atomic_lock) asm("lock;foo");
> > else asm ("foo"); }
>
> This requires you to have all the methods present at compile time,
> which defeats the entire purpose of dynamic method loading.
Pardon? I didn't see a discussion of dynamic loading anywhere
here. We were referring to tiny inlined assembly language routines.
The existing implementation is #defines in a C header file.
(No, SmallEiffel doesn't do dynamic loading, and that's a perfectly
fair and reasonable choice for a large number of applications.)
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 04:24:41PM -0500, Chuck Robey wrote: > On Fri, 21 Jan 2000, Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Chuck Robey >writes: > > : I would think using a fixed order would be a really bad thing, causing > > : overload of the first server in line. Did I misunderstand you? How about > > : doing a script (say in perl, it has random numbers) that randomly picks > > : the server from a list? That way, the list could even be weighted, so as > > : to allow for greater or lesser machine resources (like net access). > > > > That's one of the things I have to fix up. This script is good for > > me, but bad for everyone. Enhancements like this would be a good > > thing. Got time? > > I don't know perl. Darn. Yes, I will learn perl. Now. sh has random numbers. Spelled "jot -r". -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems installing FreeBSD 4.0 20000125-CURRENT
On Thu, Jan 27, 2000 at 06:53:51PM -0800, Mike Smith wrote: > Since the hostname is simply a plain-text token for the IP address, it > has to remain bound to the IP address (whether that binding is fixed or > dynamic is outside the scope of this discussion). Having a hostname that > doesn't map to your IP address is a misconfiguration, and not a useful > one at that. My system has two ethernet cards, and two IP addresses. One of these is assigned by DHCP and the other is fixed, on my local network. I prefer for my hostname to relate to the local address. Just another data point. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: df output ? (picobsd related)
On Mon, Feb 07, 2000 at 01:04:27PM +0100, Luigi Rizzo wrote:
> and the like. On a recent -current snap, this returns
>
> ufs:fd0a
>
> I used the previous behaviour in picobsd's rc to mount
> the file system from the boot device,
>
> set `df /` ; dev="/dev/$8"
> echo "Reading /etc from ${dev}..."
> mount -o rdonly ${dev} /mnt
>
> unfortunately the "ufs:" prefix breaks the above code.
> Any simple shell trick to parse/remove the ufs: prefix ?
> Note, i cannot use tr, basename or other progs, they are just not there!
How about dev="/dev/${8#*:}" ?
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cpp change breaks ipfw
On Sun, Feb 27, 2000 at 12:48:53AM -0500, Jim Bloom wrote: > I have been using cpp on my firewall to expand my local firewall rules and fill > in the local address and subnetmask. This makes things easier my ISP decides to > change my IP address using DHCP. My firewall is running an approximately one > year old version of current and I'm trying to upgrade it to a recent version. Probably not the answer you're looking for, but another approach to consider: I worked around this problem by having the dhclient-exit-hooks script edit the new address into /etc/hosts, and ipfw uses the symbolic name for the rule. Works quite nicely, but then I don't have any rules that rely on the DHCP-supplied netmask. And here's a picture: if [ x$new_ip_address != x ]; then cp /etc/hosts /tmp/hosts-foo sed -e /gurney-/d /tmp/hosts-foo >/etc/hosts echo "$new_ip_address gurney-gw.reilly.home gurney-gw" >>/etc/hosts echo "$new_routersgurney-router.reilly.home gurney-router" >>/etc/hosts echo "$new_domain_name_serversgurney-ns.reilly.home gurney-ns" >>/etc/ hosts rm /tmp/hosts-foo fi I dare say that this would work less well if you were using a local DNS. Maybe m4 (instead of cpp) is the right way to do it? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixed sound card problem.
On Fri, Sep 03, 1999 at 09:08:59PM +0100, Doug Rabson wrote: > This is no longer necessary (in fact it causes much confusion for the > driver). The correct declaration for a pnp soundcard is 'device pcm0'. How do you set flags for particular cards, now? I used to have to use the flags option to tell the pcm driver which second DMA channel to use (5: flags 0x15). I haven't had the opportunity to do any full-duplex stuff since that change, so I don't know whether it has figured it out for itself or not. I assume that it has? The boot message now says: pcm1 (CS423x/Yamaha/AD1816 sn 0x) at 0x530-0x537 irq 5 drq 1 flags 0x10 on isa So, is 0 a useful 2nd DMA channel, or does the driver make do with one channel now? This is on a -stable system cvsupped on 2nd September. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 01:41:41PM +1000, Peter Jeremy wrote: > On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote: > >Before attempting to build world, you must make and install a new > >kernel. The new kernel will contain new syscalls that are needed during > >build world. doscmd is currently not being build because it needs fixing > >first. > > I'd like to voice my concerns with this change as well. The `normal' > upgrade procedure has always been to build and install a new world > before the new kernel. The only exception I'm aware of has been the > aout->elf transition (where a special build procedure was provided). Isn't this backwards? The kernel's the place that can (and must) have the backwards-compatability hooks, for the simple reason that even if you build the world, your ports and third-party applications have to keep running. Kernels are built and updated without corresponding buildworlds all the time. If you change something fairly fundamental about the interface specification for the userland-kernel interaction (say, going to 64-bit file offsets, for an equivelant example), then it seems pretty obvious to me that a program or library compiled to the new spec _cannot_ run on a kernel that doesn't implement it. How could it be otherwise? This seems to be a different argument to the one John-Mark is makeing: he isn't trying to _run_ his new world on his old kernel, just compile it. I agree that there are probably some curly issues regarding building a build-only set of tools. These are obviously going to be _different_ from the equivelant tools that you want built as part of the buildworld, being cross-compilers and so on. I don't know how close the build target is to that ideal. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote: > The problem > --- > When doing a make world, tools are being built that are used by the > build process. This is to make sure that the tools are appropriate for > doing a make world. The problem we now face is that the sigset_t change > causes this to break. The tools that are being built use new syscalls > not present in a kernel. Not only that, the new tools expect a different > sigframe in general. As far as I can see, if this is the case, then this is the only problem. The tools built for a buildworld are tools that have to run on the _current_ platform, whatever that might be, with the new platform as a target. Therefore, they should be build against the existing system include files and libraries, and so should run on the existing system. With these tools, we build the world. As far as I can tell, the problem is installworld. Either: (a) The tools required to build the corresponding new kernel have to be secreted away in an "upgrade-bin" directory, so that they are still accessible after the install world (none of which will run on the existing kernel). (b) You build a new kernel before you do the install-world, reboot, and then installworld. I can't see any bennefit at all to (a), or any problem with (b). As I mentioned in a previous mail, why on earth should we expect user-land programs built to a new API to run on a kernel that doesn't support that API. The converse has always been true, though. Kernels usually support any new API and the previous one or more, so that old applications will still run. That said, I don't mind your idea of extending the stable kernel, but that is still really just a sneaky way of getting the user to build and install a kernel that supports the new API before they try to installworld. Isn't it? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Fri, Oct 01, 1999 at 03:36:11PM -0400, Daniel Eischen wrote: > But this still doesn't entirely solve the problem. You still have > to build and install a new kernel before installing the world. Of course! Installing the world _is_ upgrading your operating system. I don't see anyone suggesting that ELF applications should work on kernels that only support a.out binaries. Neither should programs that use 64-bit file offsets work on kernels that predate that change. (Note that this is entirely different from the issue of being able to use such a system to _build_ the new world.) > While this is typically what most -current folks do anyways, it > still prevents backing up to a previous kernel after the install > world. Yes. That's what backup tapes are for. If you're going to nuke your entire operating system, you'd better be ready to recover from tores. > It seems like libc should be built to be compatible with the kernel > that is currently running. After installing world and testing the > new kernel, a subsequent make world (or some other target to get > just the libs) can be done to make the libs use the new syscalls. > I like to keep old known working kernels around just in case there > are some serious bugs with the current one. Once a kernel has > proven itself somewhat stable, you can then upgrade the libs. Or, you could do it the sensible way: upgrade the kernel to support the new syscalls, and test it for a while _before_ building and installing a world that depends on it. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, Nov 15, 1999 at 05:48:31PM +0100, Pierre Beyssac wrote:
> The problem is apparently due to the following code fragment:
>
> register u_short answer = 0;
> [...]
> /* mop up an odd byte, if necessary */
> if (nleft == 1) {
> *(u_char *)(&answer) = *(u_char *)w ;
> sum += answer;
> }
>
> Removing the "register" declaration for 'answer' doesn't help.
That code should not even compile, since standard C says that you
_can't_ derefrence a register variable. That's about the only
genuine semantic content of the register keyword now. The fix with
a union (in another message) is the right way to do it, and doesn't
even require that "answer" be in addressable storage. (I.e., it
can now be optimised into a register).
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Is there spinlocks/semaphores available for drivers?
On Sun, Mar 26, 2000 at 11:24:50PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Matthew Dillon writes: > : complex. For example, using fixed-length FIFOs rather then linked lists. > : The writer manipulates the write index variable, the reader manipulates > : the read index variable. No locking is required between reader and > : writer. > > What about wrap around? You mean queue empty or queue full? That's when you have to punt to a rate-limit mechanism. Dunno what that would be in interrupt context. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Build status
On Mon, Apr 17, 2000 at 11:17:15PM +0200, Poul-Henning Kamp wrote: > Once per day the machine cvsups, checks out a virgin source tree, > tries to build GENERIC, GENERIC98, LINT and world. If any of these > builds fail it will send a report like this. > > On Sundays the report will always be sent. Are any of these warnings of the "helpful gcc" type, rather than actual dangers? It would be a shame if this resulted in obfuscation of the code base _just_ to shut gcc up. Of course if gcc is well-behaved on this point, and the warning flags are well sorted and agreed-upon, then there isn't a problem. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone have OpenSSH + X11-fwd working?
On Thu, Apr 20, 2000 at 07:23:00PM -0400, Brian Fundakowski Feldman wrote: > On Thu, 20 Apr 2000, Chris Piazza wrote: > > > It's working from my 5.0 box to my 4.0-R box across town, too. > > > > -Chris > > Thanks. There's one data point. Now it's evidently nothing in the > code, as it fails exactly the same way with 4.0-STABLE OpenSSH, > -CURRENT OpenSSH, and my latest port update OpenSSH. > > I have no idea what it could be now. I suppose I'll investigate problems > with XFree86 itself now :-/ This is extremely weird. Have you got "X11Forwarding yes" in the /etc/sshd_config? I had it set in my ~/.ssh/config file, but that made no difference when the server was denying the requests. Thanks to this conversation and man sshd, I've fixed the problem I was having. Thanks. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone have OpenSSH + X11-fwd working?
On Fri, Apr 21, 2000 at 01:25:20AM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Andrew Reilly" writes: > : Have you got "X11Forwarding yes" > > Ahem. "ForwardX11 yes" is what's documented and is known to work. Bzzzt. Man sshd(8): X11Forwarding Specifies whether X11 forwarding is permitted. The default is ``yes''. Note that disabling X11 forwarding does not improve se- curity in any way, as users can always install their own for- warders. Man ssh(1): ForwardX11 Specifies whether X11 connections will be automatically redirect- ed over the secure channel and DISPLAY set. The argument must be ``yes'' or ``no''. What man ssh(1) doesn't tell you in this paragraph is that even if you say "ForwardX11 yes" in ~/.ssh/config, you will not get a proxy X session unless the server has "X11Forwarding yes" in /etc/ssh/sshd_config. The default that my system configured itself with was "X11Forwarding no", and I've just changed it, and now it works. That's what I found out as a result of this conversation. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 06:36:14PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Warner Losh writes: > >In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: > >: Maybe I'm wrong because of lack of my understanding on crush dump and > >: loader. Please help us :-) > > > >I think that you might be able to do this. The real tricky part maybe > >saving hardware RAM that the drivers expect to be there when you > >wakeup. I thinking of video ram and the X server's font cache, to > >name one example. > > Drivers will need a "your hardware may have been zonked" entrypoint, > think about the i8254 counter or all the weird versions of write > only or "write here - read there" I/O registers in existence. That sounds way too hard. Why not restrict suspend activity to user-level processes and bring the kernel/drivers back up through a regular boot process? At least that way the hardware and drivers will know what they are all up to, even if some of it has changed in the mean time. > Obviously the video driver will need to send a signal or clue to the > Xserver saying "you own the device, you'd better do something" Yeah. The X server has far too much "driver" level code in it already, so probably needs to be tweaked to re-initialise itself properly. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Andrew Reilly" writes: > : That sounds way too hard. Why not restrict suspend activity to > : user-level processes and bring the kernel/drivers back up through > : a regular boot process? At least that way the hardware and drivers > : will know what they are all up to, even if some of it has changed > : in the mean time. > > Takes too long... That's shutdown, not S4. Yes. But what is the difference, really? As far as the hardware is concerned, it's being booted. If that process can be sped up by using the "S4" mechanisms, why can't they be applied to a regular boot process too? [I'm thinking about a kernel equivelant of the "clean shutdown" flag on file systems.] Fundamentally, is there no way to get the kernel and drivers to go through a full boot phase in a small fraction of the time that it takes to repopulate 64M of RAM from disk? (*) I'm concerned about trying to take short-cuts with booting, because I've seen both the Toshiba laptop that I'm using now, and my mother's HP desktop system hang horribly hard when they should have been coming out of suspend. (Both W'98.) I like the idea that my laptop will save power by shutting down after a while, but I don't want to get into trouble if I forget whether I was docked or not, or whether the floppy was plugged in or not, when next I turn it on. (*) Speaking of which: why are we considering doing process dumps into a _different_ swap-ish partition, instead of just ensuring that all processes are sleeping in the normal swap partition? If that was done, then they would just page themselves back in as needed, on wake-up. Sorry for blathering. This is just really interesting stuff. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:30:55PM -0700, Brooks Davis wrote: > On Tue, Jun 20, 2000 at 10:16:08AM +1000, Andrew Reilly wrote: > > (*) Speaking of which: why are we considering doing process > > dumps into a _different_ swap-ish partition, instead of just > > ensuring that all processes are sleeping in the normal swap > > partition? If that was done, then they would just page > > themselves back in as needed, on wake-up. > > Because swap doesn't work that way anymore. They days where every page of > memory had to be backed by disk are long gone. This means that there may > not be anywere to put processes which are in memory unless you allocate > somewhere to save all (or practicaly all) of memory. But to do the proposed state save to disk, there _must_ be enough disk space to back all of the process pages. > In any case, I > haven't seen many laptops capable of using more then 256MB of RAM which > isn't exactly much of a modern disk. My laptop has 256MB of RAM and > ships with up to a 10GB disk. I've retrofitted it with a non-standard > 18GB disk because 10GB looked too small for my needs. Even with the 6.4GB > disk it shipped with, the suspend to disk partition is only 4% of my disk. The issue isn't with the size of the disk storage required, but with the mechanism. Why dedicate 256M to a suspend partition, and invent a new process saving mechanism, instead of making your existing swap partition 256M larger and using the existing swap pager? Processes do still wind up in "sleep" state, completely paged out, don't they? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: > The real issue here is persistent system state across the S4 suspend; ie. > leaving applications open, etc. IMO this isn't really something worth a > lot of effort to us, and it has a lot of additional complications for a > "server-class" operating system in that you have to worry about network > connections from other systems, not just _to_ other systems. Don't the normal TCP timeouts take care of existing connections? I doubt that a "server class" system will be going into suspend mode for any reason, but I would imagine that suspend/resume should look much like network outage for the clients of suspended servers. For the only place that I can see it mattering (laptops), I suspect that suspend/resume should be an X session manager and application level job, and the kernel should just shutdown and boot as normal. I know that there aren't too many X applications that do all of the session management things, but maybe that would change if suspend actions interacted with the popular desktops in the appropriate way. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 12:47:38PM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Bjoern Fischer writes: > : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), > : turning power off, maybe adding some hardware or moving the machine > : to another location, then switching on again, restoring the system context, > : and the machine will proceed as if nothing had happened, do you? > > The S4 sleep state of ACPI doesn't support changing the hardware > configuration while you are in that state. That would probably explain why W'98 gets confused when you _do_ change the hardware configuration while in suspend state. Pretty silly state to get into, then, if hardware like floppy drives are easy to add or remove, and the box looks as though it's off... Any good theories about how to avoid this problem? Avoid S4 and go all the way to shutdown, with a flag set on the boot disk? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
On Mon, Jun 26, 2000 at 08:40:44PM +0900, Daniel C. Sobral wrote: > Jun Kuriyama wrote: > > > And we should keep that master text simple to ease modification by > > hackers. If we force to write complex markups, hackers will *forget* > > to update that master text. :-) > > I'm not sure I would *forget* it, but I my indulge in "forget"ing it. > :-) How about a couple of fields in the driver source itself, along the lines of http://publicsource.apple.com/projects/headerdoc/ If it's part of the source that the developers are working with, then it's more likely to stay "right". Of course we all know that comment bugs exist. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MS CHAP v2 in -current?
On Sat, Jul 22, 2000 at 08:29:23AM -0400, Nathan Binkert wrote: > The patch does work for client side. I have verified that I can connect > to a windows server using chap v2, but I forgot to do something for > server. Shouldn't take me long. If you need the server part before > Brian gets back, let me know. Out of interest, is there any code relationship, beyond the ijppp ancestor, between mpd-netgraph and ppp? I switched to mpd-netgraph recently when I was having problems getting pptp to work against a recent-ish NT server, and it's sort of working (keeps dropping out: I'll mail some traces to Archie soon.) It does do the authentication thing, though. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People running with LOCALBASE set to something other than /usr/local?
On Wed, Aug 23, 2000 at 10:54:44PM -0700, Satoshi - Ports Wraith - Asami wrote: > However, note that you need to move LOCALBASE and X11BASE for *all* > ports, not one. (For instance, you can't expect an emacs-lisp package > to install correctly if you just try to move it while emacs is still > in /usr/local.) Set LOCALBASE and X11BASE in /etc/make.conf and > rebuild everything, including X. On the subject of rebuilding everything, is there a tool that will build a dependency-ordered list of all of the ports that are currently installed (or at least the current version of them)? I've been thinking that it would be a nice housekeeping proceedure every so often to move /usr/local aside, and rebuild all of the ports that I use, after a successful build of world and kernel. At least that would help to keep track of things that I've gratuitously added to /usr/local, outside of the ports mechanism. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with /usr/bin/awk
On Thu, Aug 24, 2000 at 05:19:34PM +0200, Sheldon Hearn wrote: > So I'm a bit stumped as far as formulating an easy How-To-Repeat is > concerned. :-( How about wedging a printenv into the makefile, before the call to awk, so that you can re-create the environment when testing it? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
On Mon, Mar 26, 2001 at 05:24:14PM +0930, Greg Lehey wrote: > On Sunday, 25 March 2001 at 23:48:10 -0800, Doug Barton wrote: > > Greg Lehey wrote: > >> > >> On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > >>> The Portmapper binary has been renamed from `portmap' to `rpcbind'. > >> > >> Why? > > > > So we can be more like sysV > > This is good? If it's the best path to NFS over IPv6, which seems to be the issue, then sure it's good. Play the ball, not the man. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Experiences with new dir allocation on FFS?
On Sun, Apr 29, 2001 at 12:50:08AM -0300, Rik van Riel wrote: > For the people wanting to turn on write caching ... it WILL break > the write ordering needed by softupdates and journaling filesystems, > so don't do it unless you know what you're doing. > > I guess it would be better to do this kind of write caching at the > kernel level, because the OS has a much better idea of when to write > which data to platter than a harddisk can ever have. However, on ATA without tagged queuing, turning off write caching (on my own UDMA33 system) reduces write performance by a factor of two. From 12MB/s to 6MB/s on my system. That is almost certainly because (a) ATA limits individual transfers to 64k, and (b) you can't get the next 64k into the drive before you miss the opportunity to stream the data into the next sector, so you lose a revolution _every_ write. I think I'll rely on the power system and my nightly backups, and leave .wc=1, thanks. Sure, on my next system I'll either go back to SCSI or find some ATA tagged queuing drives, but at the moment, I have to use what I've got... -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 12:31:10PM -0600, Mike Meyer wrote:
> Not /usr/local - that's for locally maintained software. I'd rather it
> go on /usr, so I don't like /opt. When I got to choose, I chose
> /usr/opt. But anything other than /usr/local on /usr would do as well.
So do you also put the configurations in ${PREFIX}/etc, or
/usr/local/etc? Even though you got them from a readily
replaceable source, you can't retrieve your local configurations
that way.
> That's true. But if it's packaged, it belongs in an area reserved for
> *packages*. FreeBSD is the only system I know of that coopts
> /usr/local for packages, instead of reserving it for things that are
> locally maintained. Whether that locally maintained software is
> written locally or comes from a third party is irrelevant to this
> discussion.
Well, I'll just stick my oar in for /usr/local. I count myself
among the aesthetically dismayed when I first encountered /opt
on a SunOS box. (Or was that Solaris? Time fades...)
> The critical difference is the "requires local src configuration"
> line. For FreeBSD or any of the ports or packages, I can blow away the
> source tree without worrying about needing it back; I can always get
> it back from FreeBSD again. For the same reason, I don't worry much
> about the binaries. For locally written software, if I lose ths
> source, I'm SOL.
Don't you keep the source that you write somewhere in your home
directory? I do.
> For true third party software, how screwed I am
> depends on how hard it was getting the thing to build on FreeBSD. As a
> general rule, I always save them. The binaries get the same
> treatment. Having to figure out which is which is *much* easier if the
> two are in different directory hierarchies.
Whenever I have to build something outside the ports hierarchy,
I finish by diffing the orig and modified source trees. I put
the source tarball into /usr/ports/distfiles, in case someone at
FreeBSD gets around to building a port of it, and stick the
diffs in my $HOME/src directory.
> Clearly, a package is *not* the same as either third party or locally
> written software. For people who don't care about any of those
> differences, packages co-opting /usr/local doesn't matter. For people
> who do, there's PREFIX - except it doesn't work very well, and can't
> work for binary builds (and with the CDROM set no longer having
> distfiles on it, that's a major PITA).
I agree that PREFIX/LOCALBASE should work: you can't legislate
taste. I'm going to keep it to /usr/local and /usr/X11R6,
though, thanks all the same.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: > Fixing broken things is a good thing. Your argument about moving it > from /usr/local to show how broken is a good test procedure, but turning > it into policy is something completely different. > > I think the 'tradition' of FreeBSD installing packages in /usr/local is > enough to leave things the way they are, especially since non-broken > packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. The default setup for locally built ports can stay exactly as it is. (On the subject of third-party software the installs in /usr/local, the only binary thing that I run is StarOffice5.2, and it installed itself in /usr/local/office52, but I think that it's pretty agnostic about where it lives.) -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, Apr 21, 2010 at 05:23:38PM +0200, Roman Divacky wrote: > On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: > > i might have stumbled upon a problem with clang. i've compiled a kernel from > > the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. > > i'm now experiencing audio problems with mp3s and certain video files. > > playback is awfully slow and the audio output gets distorted massively. > > `top` > > however reports no high cpu load and `vmstat -i` doesn't report anything > > unusual either. > > > > this problem doesn't occur with a regular gcc-kernel. > > > > both kernels are running under a regular (gcc) world. > > > > i thought it might be a problem with acpi, but disabling acpi > > (hint.acpi.0.disabled=1) gives me a system freeze. > > I've heard about this problem but did not manage to reproduce that. > > can you try to bisect what file is being miscompiled? ie. compile > half of the kernel with gcc and half with clang and bisect this > way to a single file. The FreeBSD sound subsystem has a sample-rate converter built into the feeder that (from a cursory look) is probably quite carefully tweaked to be able to perform well (or at all). I've added -multimedia to the CC line, because they're the guys who are going to know the details. It's possible that some GCC-specific manifest constants are being tested-for, with sub-optimal fall-back code being run, instead. In the mean-time, Alexander, are there any sound-related sysctls that you can tweak so that the audio playback that you're doing does *not* involve sample rate conversion? Cheers, -- Andrew ___ 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"
usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?)
Hi all, Sorry to interrupt this thread with an off-topic question, but it seems vaguely related, and you folk seem to be the right ones to ask: I've recently done a drive upgrade in a 1U rack machine that only had space for the two active drives that were in it, and I couldn't afford the down-time that it would take to install from scratch. So I formatted and populated the first replacement drive in an external USB cradle, and when it was looking like a good replacement for the (gmirror'd) image that was running, I did the physical swap, and all was good, as expected. All except that that the identical drive that I inserted as the second element of the mirror would *not* accept a copy of the first disk's MBR block (with fdisk). It said that the calculated geometry was incompatible. Luckily for me (I think) the calculated geometry was a megabyte or so *larger* than the first drive, so I was still able to bsdlabel it to match, and slot it into the gmirror as planned. Was this the result of the umass/da driver having a different synthetic geometry calculation routine than the SATA driver? This was all on an 8-STABLE system about 400 days old, fwiw. Should I expect any on-going badness as a result of this difference in "geometry" between two identical drives? Cheers, -- Andrew ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Sun, Apr 25, 2010 at 12:06:49PM +0200, Alexander Best wrote: > i was able to pinpoint the > exact function which is causing the problem: > > it's snd_xbytes(). This is an odd-looking function. Its purpose is to compute the size of a target buffer for a block of audio samples that might be sample-rate-converted or format changed. It has a loop to compute the gcd of the second two arguments (from, to), so that it can divide by that common factor so that it can then do v * (to/x) / (from/x). It's not immediately obvious to me why it bothers to find the gcd, since the division by the original from should work anyway, as it's using a 64-bit numerator... The only difference that I can see when this is compiled with cc vs clang on my amd64 system is that the latter uses a divq in the loop and the former uses a divl. I haven't figured out why, yet. Hmm. If the same division logic is being used in the i386 version of clang, then it's possible that this is resulting in a call to an extended precision divide subroutine, which could slow things down a bit. Cheers, -- Andrew ___ 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: Panic @r207433: "System call fork returning with the following locks held"
Hi all, I'm not sure if it's related (I get my src via csup, so I don't have svn reveision numbers), but I upgraded about 16 hours ago again a few hours after that, and my two-core AMD64 system has been (seemingly) quite unstable. I've had a few boot cycles that have failed and dumped me out into kdb, rebooting through single-user (to check file systems) seems to get me "up", but my logs are completely full of: Calling uiomove() with the following non-sleepable locks held: exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0x80e60a00) locked @ /nb/src/sys/vm/vm_pageout.c:452 exclusive sleep mutex page lock (page lock) r = 0 (0x80e59e00) locked @ /nb/src/sys/vm/vm_pageout.c:451 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c2 uiomove() at uiomove+0x52 ffs_write() at ffs_write+0x32d VOP_WRITE_APV() at VOP_WRITE_APV+0x103 vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5 vnode_pager_putpages() at vnode_pager_putpages+0x97 vm_pageout_flush() at vm_pageout_flush+0x1ad vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470 vm_object_page_clean() at vm_object_page_clean+0x408 vfs_msync() at vfs_msync+0xef sync_fsync() at sync_fsync+0x12a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff803ebbad30, rbp = 0 --- or this slightly different version: uma_zalloc_arg: zone "g_bio" with the following non-sleepable locks held: exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0x80e60a00) locked @ /nb/src/sys/kern/vfs_bio.c:3571 exclusive sleep mutex page lock (page lock) r = 0 (0x80e5fb80) locked @ /nb/src/sys/vm/vm_pageout.c:451 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c2 uma_zalloc_arg() at uma_zalloc_arg+0x335 g_vfs_strategy() at g_vfs_strategy+0x28 ufs_strategy() at ufs_strategy+0x45 bufstrategy() at bufstrategy+0x43 bufwrite() at bufwrite+0x108 cluster_wbuild() at cluster_wbuild+0x1cd cluster_write() at cluster_write+0x2f5 ffs_write() at ffs_write+0x66b VOP_WRITE_APV() at VOP_WRITE_APV+0x103 vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5 vnode_pager_putpages() at vnode_pager_putpages+0x97 vm_pageout_flush() at vm_pageout_flush+0x1ad vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470 vm_object_page_clean() at vm_object_page_clean+0x19d vfs_msync() at vfs_msync+0xef sync_fsync() at sync_fsync+0x12a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff803ebbad30, rbp = 0 --- I'll be doing another csup/rebuild ASAP, in the hope of picking up the fixes mentioned here. Just thought I'd add another "me too" and a bit of data. Cheers, -- Andrew ___ 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: Panic @r207433: "System call fork returning with the following locks held"
Hi Kip,
Sorry for the delay: it's been a tussle...
On Fri, Apr 30, 2010 at 04:42:12PM -0700, K. Macy wrote:
> Does FBSDID get expanded when checking out with csup?
Looks like it:
> __FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30
> 22:31:37Z kmacy $");
My version says:
__FBSDID("$FreeBSD: src/sys/vm/vm_pageout.c,v 1.316 2010/04/30
22:31:37 kmacy Exp $");
> line 451 is part of a KASSERT on this version.
Yep.
About half an hour after sending the previous message my system
siezed up again, and I've been coaxing it back to health since.
Must make a note to myself to be more careful... I managed
to find a boot configuration that was stable enough to grab
the latest updates off the local cvs server. Then back to
single-user mode to build the kernel, and all was sweetness and
puppies after that. Thanks for the fixes!
All? Not quite: about simultaneous with the vm_pageout
weirdness (which means something (else?) committed in the last
week), my courier-authdaemond has been dying on startup thusly:
May 1 22:29:06 duncan authdaemond: /var/run/authdaemond/socket:
Cross-device link
It never used to die like that before, and I haven't changed
anything in its configuration. The socket in question is
presumably the one listed: instead there's a socket in that
directory called socket.tmp, but the process itself is long
gone.
I don't suppose that that rings a bell? Anything change with
respect to unix-domain sockets or in the last week?
Cheers,
--
Andrew
___
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: Interpreted language(s) in the base
On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: > got any other suggestions? This is very much a "sorry I asked" question, but is none-the less quite a good one, given the size of the hole to be plugged. I think that a reasonable answer for this sort of thing might be one of the dynamic languages that compiles to C, like (perhaps) one of the schemes (chicken, gambit-C, bigloo, etc). You get the benefit of flexibility and dynamism with good regexp and data structure ability, good performance, and only requiring the build tools available in the base system, as long as you don't want to be the developer: just ship the C code (as well as the source, of course). Unfortunately it seems that quite a lot of people have issues with lisp syntax these days. There are some other compile-to-C languages that might work too. [Aside: I think that the answer to this question might get a *lot* more interesting once we have llvm in the base system (it comes along with clang). There are (and I'm sure will be more) languages that compile down to llvm byte-code without the contortions required in going through C.] Cheers, -- Andrew ___ 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: Interpreted language(s) in the base
Hi Luigi, On 19/08/2010, at 00:28 , Luigi Rizzo wrote: > slightly off topic but I disagree on the latter part. I didn't expect everyone to agree. Not sure that I do, necessarily, either. (A neat, small language like TCL or Lua is probably better for most of the uses we're discussing here.) Just making a low-impact suggestion to the problem of making use of a higher-level language than C while not dragging large lumps of code into core, or accumulating maintenance issues. > The whole point of having source code is to be able to make > modifications, small or large, private or ones to be contributed > back. As a teacher, i am very concerned about the ease-of-use for > non-developer types: it is important to make it easy for people to > experiments, as this is one of the ways people learn things. I'm not making any suggestion about preventing or discouraging tinkering. After all, we used to carry f2c around in the base, in order to support Fortran code. There's no particular reason *not* to provide the front-end for (whatever language), but so long as it's readily available in ports, and build-able form a base config, I don't see that being in base is essential. > Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' > tool is almost as bad as having no source. This is an opinion I certainly don't share. There are many languages that I don't like but that doesn't make them useful, or even best-for-purpose in their niche. (a) I'm not suggesting that we don't provide source, and (b) learning a new language is an excellent excellent exercise for students, and one that they're going to have to go through often, for the rest of their careers. > (in fact, it is like the > joke of supplying source for the GPL'd software in your brand new > LCD tv or appliance. I'd like to know who will ever be able to build > an updated image and upload it to the appliance) It's nothing of the sort, of course. In the scenario I suggested, the task of updating the putative program would involve the editors available in base, to edit the source shipped with the system. Only the compilation of the edited source might or might not be gated by installing the port for the putative compiler. Several of the examples I gave originally come with an interpreter and debugging environment, so even that potential argument need not be a blocker. Not a high bar to entry, I suggest. Cheers, -- Andrew ___ 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: Interpreted language(s) in the base
I didn't want to prolong this now mostly off-topic discussion
too much, but:
On Thu, Aug 19, 2010 at 06:00:54PM +0200, C. P. Ghost wrote:
> +1 for a scheme shell, but not for the heavy-weight variety that
> compiles to C, as that would tie them to a subset of ${ARCH}es.
Why do you say that? Most of the C-generators that I know of
produce fairly standards-compliant C code that should just work
anywhere. Sure there are some (with sophisticated memory
managers, mostly) that get intimate with the platform, but
presumably we would have to stay away from those for this sort
of exercise...
Cheers,
--
Andrew
___
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: Interpreted language(s) in the base
On Thu, Aug 19, 2010 at 06:40:37PM +0200, Ivan Voras wrote: > Will have to disagree on that - part of the point of having such a > thing would be to attract young developers, and while the CS crowd > will be happy with LISP, anyone starting programming after the first > .com bubble will probably be repulsed by non-Algol-like syntaxes. I suspect that you're right, though that disappoints me somewhat. The only other language that I'm aware of that does a reasonable compiles-to-C and has an algol-like syntax is Eiffel (specifically SmartEiffel), but I haven't used it for years, and don't know how it's travelling. It's also nowhere near as dynamic and "fun" a programming experience, IMO. Cheers, -- Andrew ___ 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: TTY task group scheduling
On Thu, Nov 18, 2010 at 06:23:24PM +, Alexander Best wrote: > you think so? judging from the videos the changes are having a huge impact > imo. On Linux. Have you ever seen those sorts of UI problems on FreeBSD? I don't watch much video on my systems, but I haven't seen that. FreeBSD has always been good at keeping user-interactive processes responsive while compiles or what-not are going on in the background. Cheers, -- Andrew ___ 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: swap-related problems
On Wed, Apr 14, 1999 at 02:55:27PM -0500, Anthony Kimball wrote: > > : > All I want is that a program gets NULL from malloc if there is no memory > : > available. I find that to be a very fundamental thing about malloc. > > : Do you have a solution? We don't. > > Make an sbrk variant which will pre-allocate backing store. > setenv MALLOC_PREALLOCATE > > Not so hard. You could do this yourself, I think, by: 1) create your own backing file of the appropriate size 2) mmap it into your address space 3) tell your own malloc() routine that that's where it should get memory from. Any problems with that? (besides not being the system standard, and the reduction of swapping efficiency caused by going through the file system). -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: tcp_wrapper in contrib and ports?
On Mon, Jun 07, 1999 at 04:34:53PM +0100, Dom Mitchell wrote: > On 7 June 1999, Ben Rosengart proclaimed: > > I am curious as to why tcp_wrappers are present in /usr/src/contrib as > > well as in the ports collection. Can someone please enlighten me? TIA. > > To support 2.2.x users? Maybe 3.x users actually want tcpd too. I'm running -STABLE, and qmail, and discovered that tcp_wrappers was somehow part of the system when things started misbehaving. Oddly, tcpd itself is _not_ built by the system, it seems. The libwrap that is built (or at least the man page for tcpdchk) seems to think that the control files hosts.access and hosts.deny still live in /usr/local/etc/, rather than where you would expect a system component to put them: /etc. My current source of confusion is with the tcpd from ports, which doesn't mention what level it is syslogging at: I can't find any of it's log messages... -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
Just to prefix with my config: FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #7: Sat May 29 11:20:54 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64 Current source tree was csupped about half an hour ago. I don't think that my hardware has gone dodgy: everything else seems to be working properly. cc itself seems to work OK when compiling my own code, too. But make buildworld --> /nb/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c:128: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /nb/src/cddl/usr.bin/sgsmsg. Also, if I run buildworld with -j4 (my usual config), then a different compile crashes the same way : /nb/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/string_table.c:467: internal compiler error: Bus error: 10 but in that case it was not the first compile which broke, and several (parallel, I assume) broke at the same time. So: is anyone else seeing this? Is it likely that heisenbugs have found their way into the compiler in the last week, or perhaps in the kernel's page table handling code? More importantly: any thoughts about how I can proceed from here? Re-install from a snapshot? Cheers, -- Andrew ___ 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: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
On Mon, 31 May 2010 16:30:04 +0300
Andriy Gapon wrote:
> Have you been playing with clang or other alternative compilers?
I have them all installed, but none are used by the build
process. My make.conf is relatively clean.
> If not, then I think that it's your hardware.
I did too at first. Compiler crashes are usually "fix the
hardware" problems. I'm not so sure any more: I restored /boot
and /usr/{not local or home} from backup from about a week ago,
and using that compiler on the same hardware, I was able to get a
build and install to complete without problem. Heisenbug
somewhere, perhaps? The other hit against the hardware problem
suggestion is that the failure was in specific, repeatable places
in certain system source files. I could compile a chunk of my
own code without problems, though.
I'm now on:
FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon May 31
02:39:59 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64
based on a csup from the australian mirror from yesterday morning
(or perhaps Sunday night), and it all seems to be back to normal.
Very odd.
Cheers,
--
Andrew
___
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: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
On Mon, 31 May 2010 21:17:41 -0700 Garrett Cooper wrote: > What _is_ your make.conf though? Just this: #CC=clang CFLAGS+=-g CXXFLAGS+=-g KERNCONF=DUNCAN NO_LPR=YES NO_SENDMAIL=YES WITH_GTK2=yes WITH_CUPS=yes WITH_GECKO=libxul #WITH_DEBUG=yes A4=yes QT4_OPTIONS=CUPS NAS QGTKSTYLE PORTSDIR=/nb/ports PORTSSUPFILE=/root/ports-supfile SUPFILE=/root/standard-supfile SUPHOST=cvs.au.freebsd.org SUP_UPDATE=yes SUP=cvsup # OOo needs a really large TMPDIR, use this for OOo: TMPDIR=/nb/tmp/ # added by use.perl 2010-05-15 17:53:15 PERL_VERSION=5.10.1 my DUNCAN kern conf is just: include GENERIC ident DUNCAN It used to have more frobs in it than that! Just in case it matters: the kernel/userland/cc that was giving me grief had been built with a make.conf that said NO_KERBEROS=yes, something I'd added to try to work around the MD2_foo crypto linking problems. I can't imagine why that would be a problem, but I'm not risking it any more... Cheers, -- Andrew ___ 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: [TESTING]: ClangBSD branch needs testing before the import to HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 31 May 2010 17:01:15 +0100 Matthew Seaman wrote: > Is it really such a bad thing to have gcc as a build-dependency > for various ported applications? There are already ports that have gcc-4.4.4 as a dependency, and a few that still require gcc-3.4.6. [on my system, that's : ffmpeg-0.5.1_3,1 gegl-0.1.2_1 gimp-app-2.6.8_3,1 ufraw-0.16_3 x264-0.0.20100222_1 xsane-0.996_3 blas-1.0_4 lapack-3.2.1_1 py26-numpy-1.4.1,1 totem-2.30.1 vinagre-2.30.1 vino-2.28.2 and ...hmm... maybe I've already de-installed whatever was depending on 3.4.6...] Anyway, I don't see this trend slowing down any time soon, so I don't think that being able to compile all of ports is a reasonable constraint on bringing clang into the tree. I've changed my mind about bringing things into the tree since my last post on the subject. Being in-tree helps a lot with the ability to cross-build, which matters now that reasonably priced "beasty" machines are so much faster than reasonably-priced "puny" machines. Also, I've learned to love tmux... Also, the ability to have NO_LLVM in make.conf should (just like the other, similar switches) answer the rebuild-time issue. Just a few cents from the peanut gallery. FWIW I'm in favour, but I do understand Kostik's concern. I've been bitten by my share of compiler bugs and hardware bugs. Perhaps, even for a while after introduction, there should be a rule like "don't report a bug unless you've reproduced it on a system built with cc(=gcc)", just to keep those two issues separate. Perhaps with a side order of: any bug that you find in a clang-compiled system that goes away when re-built with gcc should be reported to the clang folk... Cheers, - -- Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwEklYACgkQgzZZe5eEKMIf4ACffE00q3RsyElRE64q3tOFovI8 Dh0An2tQLYwVc74tvXJD72bbsul0j68V =oTaO -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: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
Hi Garrett, On Mon, 31 May 2010 21:36:23 -0700 Garrett Cooper wrote: > Ok... there appear to be some interesting bits here, but I'm > curious... when was the last time that you did a build with clang, and > did you properly clean out /usr/obj, etc since your last compile? I don't think that I ever have (compiled with clang). I did pull the pieces together when Roman first suggested it, but it didn't work then, and I need this machine to be more "up" than "down", so I've shelved it for a while. At that time clang also had a bug that was a show-stopper for me, in that it wouldn't compile my own code (compile time constant expressions with conditionals were not recognised as constant, or something like that.) Long since fixed, but I don't have enough time to keep up. I do regularly nuke /usr/obj before rebuilding. Not always, but often. Cheers, -- Andrew ___ 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"
Anyone running GNOME on 9-CURRENT? How do you convince evolution-data-server to build?
I've been trying on-and-off for weeks, and haven't been able to crack it. The configure script goes looking for Kerberos 5 and can't find it, even though it's in the base. Cheers, -- Andrew ___ 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: Anyone running GNOME on 9-CURRENT? How do you convince evolution-data-server to build?
Hi there, On Fri, Jun 18, 2010 at 06:57:56AM +0800, Buganini wrote: > I'm using it without problem, > do you have any of *_HEIMDAL or *_KERBEROS in make.conf/src.conf? No. The problem, as far as I can tell, is that the search for krb5 in the configure script tests three options, (mit, heimdal and sun) all of which fail. The heimdal test *should* have succeeded, because the linker flags are (correctly) generated by a call to `/usr/bin/krb5-config gssapi --libs` (this is one of the port patches against the up-stream script. The problem is that those flags haven't actually worked for quite a while (on my system, anyway). Vis: configure:16119: cc -o conftest -O2 -pipe -g -DLDAP_DEPRECATED -fno-strict-aliasing -I/usr/local/include -I/usr/local/include/db4 1 -L/usr/local/lib -pthread conftest.c -L/usr/lib -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lro ken -lcrypt >&5 /usr/lib/libhx509.so: undefined reference to `MD2_Init' /usr/lib/libhx509.so: undefined reference to `MD2_Final' /usr/lib/libhx509.so: undefined reference to `MD2_Update' configure:16119: $? = 1 Now what I don't understand is why the linker fails to find those symbols, given that they *are* defined in libcrypto, which is also listed on the linker command line there. I suspect that it has something to do with the way that shared libraries are constructed: they seem to contain their own list of dependencies, and somehow /usr/lib/libhx509.so.10 does *not* know that it depends on /lib/libcrypto.so.6 (ldd shows only a dependency on /lib/libc.so.7). I regret that I don't know enough linker fu or make infrastructure fu to know where to suggest a tweak, but I believe that the necessary tweak is to the base system build of libhx509.so, rather than the ports in question. What I *really* don't understand is why this seems to be working for everyone else... (My system was last re-built from csup'd source on Thursday 17 June, by the way, so it's not out of date.) Cheers, -- Andrew ___ 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: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: > in /etc/src.conf - WITHOUT_LPR=yes > > and these symbolic links in /usr/bin > lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -> > /usr/local/bin/lp > lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -> > /usr/local/bin/lpoptions > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq -> > /usr/local/bin/lpq > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr -> > /usr/local/bin/lpr > lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm -> > /usr/local/bin/lprm > lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat -> > /usr/local/bin/lpstat > > and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. Cheers, -- Andrew ___ 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: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Hi Kostik, On 06/07/2010, at 18:54 , Kostik Belousov wrote: > You need to gather and show exact command that fails. There's some a little more info in PR: ports/145769, although the "fix" that I suggest there is almost certainly a wrong turn (I nuked all reference to MD2_* from libhx509, there). I can't easily recreate the problem, now that I've patched my copy of /usr/src/kerberos5/lib/libhx509/Makefile, but the fault seems to be fairly consistent in the configure script of any port configured to use GSSAPI, such as fetchmail or evolution-data-server. From memory, the failing program is a one-line main() that calls MD2_Init(), and attempts to link it with a command line derived from `krb5-config --lib gssapi`. > Shared object that references a symbol but does not record a dependency > on the object providing the symbol is the bug in the build of that object > (usually). That is what /usr/lib/libhx509.so.10 seems to do (see the undefined refs to MD2_* with nm /usr/lib/libhx509.a, and see the lack of dependency on /lib/libcrypto.so.6 with ldd), and yet this hasn't been widely reported, I suspect, because it still seems to work in 8-STABLE. Don't know why. The exact command that fails, in summary, is: get a 9-current system. cd /usr/ports/mail/fetchmail (or /usr/ports/databases/evolution-data-server, but that has lots of other dependencies that might take a while to build) make config # and tell it to enable GSSAPI (and NTLM) which isn't the default. make # watch the configure fail with a report of missing KRB5, but inspection of the configure.log will show that the real failure was a failure to link against the system-supplied shared libraries, specifically libhx509.so. Repeat the process on an 8-STABLE system and see that the config and build proceeds successfully, despite the fact that libhx509.so.10 has undefined symbols for MD2_* just as on -current. Please let me know if there's any other info that I can provide. Cheers, -- Andrew ___ 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: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Hi Kostik,
On 06/07/2010, at 22:33 , Kostik Belousov wrote:
> "Install evolution-data-server" as a reference to the command is a sure way
> to not get any help.
Why, because no-one uses ports?
> I asked for explicit command that fails, PR does not contain this information.
> It is not even clear whether the issue is from the static or run-time linker.
The specific command that fails is in the PR, to whit:
cc -o conftest -O2 -pipe -g -DLDAP_DEPRECATED -fno-strict-aliasing
-I/usr/local/include -I/usr/local/include/db41 -L/usr/local/lib -pthread
conftest.c -L/usr/local/lib -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509
-lcom_err -lcrypto -lasn1 -lroken -lcrypt
where, in this instance, conftest.c is something like (extracted from the
configure script from evolution-data-server):
/* contentes of confdefs.h, whatever that is, probably at least: */
#include
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char krb5_init_context ();
int
main ()
{
return krb5_init_context ();
;
return 0;
}
(fetchmail uses a conftest with a call to gss_check_version(), but the result
is the same.)
And the cc fails with
/usr/lib/libhx509.so: undefined reference to `MD2_Init'
/usr/lib/libhx509.so: undefined reference to `MD2_Final'
/usr/lib/libhx509.so: undefined reference to `MD2_Update'
as reported in the PR.
It doesn't do this on my system any more, because I've fixed it with the patch
attached to that PR.
Cheers,
--
Andrew
___
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: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Hi Kostik, Thanks for looking at this, On 06/07/2010, at 23:46 , Kostik Belousov wrote: > Ok, this is useful. But, on the HEAD from Jul 2, I cannot reproduce it, > with conftest.c and command line above. As well as on the stable/8 that > is approx. one month old. > > On both systems, MD2_* symbols are resolved by libcrypto.so. Check > your instance, do the symbols appear in the library ? On both my 8- and -current (Jul 3) base systems, libcrypto.so has the MD2_* symbols, and libhx509.so doesn't (but requires to them). /usr/local/lib/libcrpto.a does *not* have the MD2 symbols. > As a long shot, do you have openssl 1.0 installed from ports ? My -current box does. My 8.1-RC doesn't. > Note the -L /usr/local/lib switch, that causes -lcrypto to be resolved > from /usr/local/lib, if present. AFAIR, 1.0 removed MD2. Ah-ha. So I guess the situation properly is: Not having heimdal installed from ports, the ones that look for gssapi libs use the base system, and the /usr/bin/krb5-config gssapi --libs includes -lhx509, which has unresolved MD2_* symbols. The -L/usr/local/lib on the command line (presumably for other ports dependencies) makes the linker look in /usr/local/lib/libcrypto, which is there because of the openssl-1.0 port, and which doesn't have the MD2_ sybmols. My two "fixes" both kind of work: removing the MD2 references from the base system's libhx509 make it compatible with the -lcrypto in ports; adding an explicit dependency on the base system's libcrypto also works, because that does have the MD2 references. My 8-stable system presumably works because it doesn't have openssl-1.0 installed from ports. So: how should I "fix" this, properly, on my -current system? Is it as simple as installing heimdal from ports? I can't remove openssl-1.0: that has 191 ports listed in its REQUIRED_BY file. Should ports/security/heimdal be listed as a dependency of the ports that use GSSAPI? Is it OK for the base system libhx509.so to *not* have an explicit dependency on libcrypto, even though there seems to be one, and adding such a dependency seems to "fix" this problem? Cheers, -- Andrew ___ 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: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
On Tue, Jul 06, 2010 at 08:00:20PM +0100, Matthew Seaman wrote: > On 06/07/2010 15:14:28, Andrew Reilly wrote: > > So: how should I "fix" this, properly, on my -current system? Is it > > as simple as installing heimdal from ports? I can't remove openssl-1.0: > > that has 191 ports listed in its REQUIRED_BY file. > > Rebuild the port of openssl-1.0.0 after modifying the OPTIONS to include > MD2=on ? OK. I've done that, and backed out my patch to the base libhx509 build, and lo: fetchmail rebuilt entirely happily. But now I'm confused, because ldd fetchmail before the change and ldd fetchmail after the change are identical. I don't understand how that can be. I think that I need to tear things down and start from scratch. Or at least think about it a bit longer... Here's ldd fetchmail, after (same as before): fetchmail: libintl.so.9 => /usr/local/lib/libintl.so.9 (0x800681000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x80078a000) libopie.so.6 => /usr/lib/libopie.so.6 (0x800984000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x800a8d000) libmd.so.5 => /lib/libmd.so.5 (0x800ba6000) libkvm.so.5 => /lib/libkvm.so.5 (0x800cb3000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x800dbc000) libssl.so.7 => /usr/local/lib/libssl.so.7 (0x800ebe000) libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x801016000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x8012b2000) libheimntlm.so.10 => /usr/lib/libheimntlm.so.10 (0x8013bc000) libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x8014c1000) libhx509.so.10 => /usr/lib/libhx509.so.10 (0x801631000) libasn1.so.10 => /usr/lib/libasn1.so.10 (0x801771000) libroken.so.10 => /usr/lib/libroken.so.10 (0x8018f3000) libc.so.7 => /lib/libc.so.7 (0x801a05000) I would have thought that the "before" would be using /lib/libcrypto.so.6, because that's what libhx509.so.10 told it to... Cheers, -- Andrew ___ 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"
Samba wedged: what does it mean?
Hi there, I've been providing a light-use samba server on my freebsd-current box, mostly for secondary storage my wife's laptop. It's worked mostly-fine for a dozen years. I've never seen anything like this before, and am not sure where to start poking it. Here's the output of netstat and ps, for the suspicious bits. It's been sitting like that for just shy of twelve hours. Nothing else on the system seems to be broken. I've stopped samba: only these wedged copies exist. Any way out, short of a reboot? This is on: FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Fri Jul 9 21:05:44 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64 The samba34 server was serving an un-journalled UFS2+SU file system. Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 263 0 duncan.microsoft-dsirulan.51095 CLOSED tcp4 278 0 duncan.microsoft-dsirulan.51094 CLOSED tcp4 515 0 duncan.microsoft-dsirulan.50915 CLOSED tcp4 82 0 duncan.microsoft-dsirulan.50869 CLOSED tcp4 194 0 duncan.microsoft-dsirulan.50800 CLOSED tcp4 419 0 duncan.microsoft-dsirulan.50596 CLOSED tcp4 194 0 duncan.microsoft-dsirulan.50572 CLOSED tcp4 337 0 duncan.microsoft-dsirulan.50551 CLOSED tcp41024 0 duncan.microsoft-dsirulan.50546 CLOSED tcp4 680 0 duncan.microsoft-dsirulan.50442 CLOSED tcp4 82 0 duncan.microsoft-dsirulan.50410 CLOSED tcp4 360 0 duncan.microsoft-dsirulan.49285 CLOSED root 119 0.0 0.2 49904 7816 ?? D 6:17am 0:00.77 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 187 0.0 0.2 49692 7016 ?? D 6:55am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 188 0.0 0.3 49904 7896 ?? D 6:56am 0:01.93 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 212 0.0 0.2 49692 7096 ?? D 7:06am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 215 0.0 0.3 49904 8268 ?? D 7:07am 0:03.59 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 233 0.0 0.2 49692 7052 ?? D 7:16am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 234 0.0 0.3 49904 8040 ?? D 7:17am 0:01.11 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 252 0.0 0.2 49692 7080 ?? D 7:25am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 253 0.0 0.2 49692 7060 ?? D 7:26am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 254 0.0 0.3 49904 7844 ?? D 7:27am 0:00.29 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 447 0.0 0.2 49692 7268 ?? D 7:52am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 448 0.0 0.2 49692 7240 ?? D 7:53am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf Cheers, -- Andrew ___ 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: Samba wedged: what does it mean?
Hi all, Just another note: the system logs this morning had a couple of LOR reports that I haven't seen before: +lock order reversal: + 1st 0xff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0x80e5bdc0 ifnet_rw (ifnet_rw) @ /nb/src/sys/net/if.c:225 + 1st 0xff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0xff000283faf8 radix node head (radix node head) @ /nb/src/sys/net/route.c:362 + 1st 0xff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0xff00027e53c0 if_afdata (if_afdata) @ /nb/src/sys/net/if_llatbl.c:129 + 1st 0xff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0xff80002f6020 nfe0 (network driver) @ /nb/src/sys/dev/nfe/if_nfe.c:2549 Not sure if those are relevant or not. Also, it seems that for whole time of the samba blockage I wasn't receiving any mail (via fetchmail --> local qmail smtp server), but had no trouble connecting to the system over ssh, or doing most other things. On Tue, Jul 13, 2010 at 06:50:25PM +1000, Andrew Reilly wrote: > This is on: > FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Fri Jul 9 > 21:05:44 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64 > Cheers, -- Andrew ___ 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: fast bcopy...
On Wed, May 02, 2012 at 08:25:57PM +0200, Luigi Rizzo wrote: > as part of my netmap investigations, i was looking at how > expensive are memory copies, and here are a couple of findings > (first one is obvious, the second one less so) Most C compilers (well, the ones I regularly use) inline small, constant-length memcpy operations of the sort you're describing here. I would expect techniques like that to beat any amount of hand-tuning in a elf-linkage bcopy subroutine. Sure, you want a good implementation for your variable-length copies, and data layout and alignment is tremendously important these days, so there's no single silver bullet here. Cheers, -- Andrew ___ 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: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC
On Fri, Jan 05, 2018 at 02:27:40AM +0800, blubee blubeeme wrote: > I'd love to see if RISC-V is vulnerable to this? > > I think they are in the best position to capitalize on this clusterfk... It's a micro-architecture flaw, not an instruction set flaw, so just as for ARM and amd64, it will depend on the specific version. The only RISC-V hardware that I'm aware of is in-order (no speculation) so unlikely to be affected. There aren't any data-centre-scale RISC-V systems yet, but some are being worked-on. Will be interesting to see if they suddenly push out roadmaps while they go back to re-design to avoid this... Cheers, Andrew ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Since last week (today) current on my Ryzen box is unstable
Hi, I do a weekly build to track changes, on 12-current since I gave my fileserver this new Ryzen motherboard a few months ago. I switched to current because there was some badness in 11-stable that I attributed to new processor twitchiness (wouldn't reboot, temperature sensors not working.) A month or so of 12- has been lovely, for the most part. Today's rebuild has given me uptimes of below an hour, usually. The box will stay up in single user mode long enough to rebuild world/kernel, but multi-user it is panicking at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1592 The backtrace shows that it gets to this panic from a sendfile() syscall. The line above is in the middle of a big edit that's part of svn revision 329363. The tripping assertion seems to suggest that m->valid != 0, for whatever that's worth. Anything that I should be trying? On a side-note, the new devmatch workings are giving me 43 boot warnings about "Malformed NOMATCH string: ''?'', and devmatch_enable="NO" in /etc/rc.conf doesn't seem to help, and the new matching is very very keen to load cc_vegas.ko, a lot. Here's the output of devmatch -v, in case that helps: $ devmatch -v Searching acpi bus at handle=\_PR_.P008 for pnpinfo _HID=none _UID=0 Searching acpi bus at handle=\_PR_.P009 for pnpinfo _HID=none _UID=0 Searching acpi bus at handle=\_PR_.P00A for pnpinfo _HID=none _UID=0 Searching acpi bus at handle=\_PR_.P00B for pnpinfo _HID=none _UID=0 Searching acpi bus at handle=\_PR_.P00C for pnpinfo _HID=none _UID=0 Searching acpi bus at handle=\_PR_.P00D for pnpinfo _HID=none _UID=0 Searching acpi bus at handle=\_PR_.P00E for pnpinfo _HID=none _UID=0 Searching acpi bus at handle=\_PR_.P00F for pnpinfo _HID=none _UID=0 Searching pci bus at slot=0 function=2 dbsf=pci0:0:0:2 handle=\_SB_.PCI0.IOMA for pnpinfo vendor=0x1022 device=0x1451 subvendor=0x1022 subdevice=0x1451 class=0x080600 Searching pci bus at slot=0 function=0 dbsf=pci0:9:0:0 for pnpinfo vendor=0x8086 device=0x24fb subvendor=0x8086 subdevice=0x2110 class=0x028000 Searching pci bus at slot=0 function=1 dbsf=pci0:11:0:1 for pnpinfo vendor=0x1002 device=0xaab0 subvendor=0x174b subdevice=0xaab0 class=0x040300 Searching pci bus at slot=0 function=0 dbsf=pci0:17:0:0 for pnpinfo vendor=0x1022 device=0x145a subvendor=0x1022 subdevice=0x145a class=0x13 Searching pci bus at slot=0 function=2 dbsf=pci0:17:0:2 handle=\_SB_.PCI0.GP17.APSP for pnpinfo vendor=0x1022 device=0x1456 subvendor=0x1022 subdevice=0x1456 class=0x108000 cc_vegas.ko Searching pci bus at slot=0 function=0 dbsf=pci0:18:0:0 for pnpinfo vendor=0x1022 device=0x1455 subvendor=0x1022 subdevice=0x1455 class=0x13 Searching acpi bus at handle=\_SB_.PCI0.SBRG.PIC_ for pnpinfo _HID=PNP _UID=0 Searching acpi bus at handle=\_SB_.PCI0.SBRG.SPKR for pnpinfo _HID=PNP0800 _UID=0 Searching acpi bus at handle=\_SB_.GPIO for pnpinfo _HID=AMDI0030 _UID=0 Searching acpi bus at handle=\_SB_.PTIO for pnpinfo _HID=AMDIF030 _UID=0 Searching acpi bus at handle=\AOD_ for pnpinfo _HID=PNP0C14 _UID=0 I can't tell if this is related to the zfs problem or not. As far as I'm aware, cc_vegas.ko was not loaded into the kernel before today. FWIW uname -a says: FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #6 r329450: Sat Feb 17 22:36:19 AEDT 2018 root@:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I'll attach the dmesg.boot from the boot that I had to do while composing this message... Cheers, Andrew dmesg.boot Description: Binary data ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Since last week (today) current on my Ryzen box is unstable
I've applied the patch, and the boot process is quiet now, but it's still loading cc_vegas.ko, seemingly in response to seeing this device: (from pciconf -l -v) none4@pci0:17:0:2: class=0x108000 card=0x14561022 chip=0x14561022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Family 17h (Models 00h-0fh) Platform Security Processor' class = encrypt/decrypt (from devmatch -v) Searching pci bus at slot=0 function=2 dbsf=pci0:17:0:2 handle=\_SB_.PCI0.GP17.APSP for pnpinfo vendor=0x1022 device=0x1456 subvendor=0x1022 subdevice=0x1456 class=0x108000 cc_vegas.ko The output above suggests that there isn't a driver attached to that device anyway, though. Cheers, Andrew Reilly > On 18 Feb 2018, at 00:06 , Hans Petter Selasky wrote: > > On 02/17/18 13:42, Hans Petter Selasky wrote: >> On 02/17/18 13:16, Andrew Reilly wrote: >>> On a side-note, the new devmatch workings are giving me 43 boot warnings >>> about "Malformed NOMATCH string: ''?'', and devmatch_enable="NO" in >>> /etc/rc.conf doesn't seem to help, and the new matching is very very keen >>> to load cc_vegas.ko, a lot. Here's the output of devmatch -v, in case that >>> helps: >> Hi, >> Does the attached patch solve the devmatch issue? Just apply it directly on >> /etc and reboot. >> --HPS > > Please find updated patch attached. > > --HPS > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12-Current panics on boot (didn't a week ago.)
Hi all, For reasons that still escape me, I haven't been able to get a kernel dump to debug, sorry. Just thought that I'd generate a fairly low-quality report, to see if anyone has some ideas. The last kernel that I have that booted OK (and I'm now running) is: FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r331064M: Sat Mar 17 07:54:51 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 The machine is a: CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.46-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Kernels built from head as of a couple of hours ago get through launching the other CPUs and then stops somewhere in random, apparently: SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1497223020 Hz quality 1000 random: entpanic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/subr_bus.c:617 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe4507a0 vpanic() at vpanic+0x18d/frame 0xfe450800 doadump () at doadump/frame 0xfe450880 __mtx_lock_flags() at __mtx_lock_flags+0x163/frame 0xfe4508d0 devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame 0xfe450900 g_dev_taste() at g_dev_taste+0x370/frame 0xfe450a10 g_new_provider_event() at g_new_provider_event+0xfa/frame 0xfe450a30 g_run_events() at g_run_events+0x151/frame 0xfe450a70 fork_exit() at fork_exit+0x84/frame 0xfe450ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe450ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 14 tid 100052 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why db> dump Cannot dump: no dump device specified. db> Now dumping worked fine the last time the kernel panicked: I have dumpdev=AUTO in rc.conf and I have swap on nvd0p3 (first) and /dev/zvol/root/swap (second, larger than the first.) Root on the nvd0p2 is ZFS, and ther's a four-drive raidZ with user directories and what-not on them, and another ZFS on an external USB drive that I use for backups, unmounted. In the new kernels, we clearly aren't even getting as far as finding the hubs and controllers, let alone the drives. I've attached dmesg.boot from the last boot from last week's good kernel. (While briefly in yoyo mode I turned the SMT back on, so now there are 16 cores instead of the eight mentioned in the crash dump. Didn't help, but I haven't turned it back off yet.) Cheers, Andrew Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #1 r331064M: Sat Mar 17 07:54:51 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.46-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x7 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33272578048 (31731 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) x 2 hardware threads random: unblocking device. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20180313/tbfadt-796) ioapic0: Changing APIC ID to 17 ioapic1: Changing APIC ID to 18 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard SMP: AP CPU #12 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #11 Launched! Timecounter "TSC-low" frequency 1497228045 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8101f5c0, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 netmap: loaded module nexus0 vtvga0: on motherboard cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on
Re: 12-Current panics on boot (didn't a week ago.)
Hi Warner, The breakage was in 331470, and at least one version earlier, that I updated past when it panicked. I'm guessing that kdb's inability to dump would be down to it not having found any disk devices yet, right? So yes, bisecting to narrow down the issue is probably the best bet. I'll try your r331464: if that works that leaves only four or five revisions. Of course the breakage could be hardware specific. Cheers, -- Andrew On 25 March 2018 1:14:40 am AEDT, Warner Losh wrote: >Also, what rev failed? I booted r331464 last night w/o issue. > >Warner > >On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly >wrote: > >> Hi all, >> >> For reasons that still escape me, I haven't been able to get a kernel >dump >> to debug, sorry. >> >> Just thought that I'd generate a fairly low-quality report, to see if >> anyone has some ideas. >> >> The last kernel that I have that booted OK (and I'm now running) is: >> FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r331064M: >Sat >> Mar 17 07:54:51 AEDT 2018 >root@Zen:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> >> The machine is a: >> CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.46-MHz >K8-class >> CPU) >> Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 >Stepping=1 >> Features=0x178bfbff> APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> >> >> Kernels built from head as of a couple of hours ago get through >launching >> the other CPUs and then stops somewhere in random, apparently: >> >> SMP: AP CPU #2 Launched! >> Timecounter "TSC-low" frequency 1497223020 Hz quality 1000 >> random: entpanic: mtx_lock() of spin mutex (null) @ >> /usr/src/sys/kern/subr_bus.c:617 >> cpuid = 0 >> time = 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe4507a0 >> vpanic() at vpanic+0x18d/frame 0xfe450800 >> doadump () at doadump/frame 0xfe450880 >> __mtx_lock_flags() at __mtx_lock_flags+0x163/frame 0xfe4508d0 >> devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame >0xfe450900 >> g_dev_taste() at g_dev_taste+0x370/frame 0xfe450a10 >> g_new_provider_event() at g_new_provider_event+0xfa/frame >> 0xfe450a30 >> g_run_events() at g_run_events+0x151/frame 0xfe450a70 >> fork_exit() at fork_exit+0x84/frame 0xfe450ab0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe450ab0 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> KDB: enter: panic >> [ thread pid 14 tid 100052 ] >> Stopped at kdb_enter+0x3b: movq$0,kdb_why >> db> dump >> Cannot dump: no dump device specified. >> db> >> >> Now dumping worked fine the last time the kernel panicked: I have >> dumpdev=AUTO in rc.conf and I have swap on nvd0p3 (first) and >> /dev/zvol/root/swap >> (second, larger than the first.) >> >> Root on the nvd0p2 is ZFS, and ther's a four-drive raidZ with user >> directories and what-not on them, and another ZFS on an external USB >drive >> that I use >> for backups, unmounted. >> >> In the new kernels, we clearly aren't even getting as far as finding >the >> hubs and controllers, let alone the drives. >> >> I've attached dmesg.boot from the last boot from last week's good >kernel. >> (While briefly in yoyo mode I turned the SMT back on, so now there >are 16 >> cores >> instead of the eight mentioned in the crash dump. Didn't help, but I >> haven't turned it back off yet.) >> >> Cheers, >> >> Andrew >> >> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >"freebsd-current-unsubscr...@freebsd.org" >> >> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12-Current panics on boot (didn't a week ago.)
So, r331464 crashes in the same place, on my system. r331064 still boots OK. I'll keep searching. One week ago there was a change to randomdev to poll for signals every so often, as a defence against very large reads. That wouldn't have introduced a race somewhere, or left things in an unexpected state, perhaps? That change (r331070) by cem@ is just a few revisions after the one that is working for me. I'll start looking there... Cheers, Andrew On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote: > Hi Warner, > > The breakage was in 331470, and at least one version earlier, that I updated > past when it panicked. > > I'm guessing that kdb's inability to dump would be down to it not having > found any disk devices yet, right? So yes, bisecting to narrow down the > issue is probably the best bet. I'll try your r331464: if that works that > leaves only four or five revisions. Of course the breakage could be hardware > specific. > > Cheers, > -- > Andrew ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12-Current panics on boot (didn't a week ago.)
OK, I've completed the search: r331346 works, r331347 panics somewhere in the initialization of random. In the 331347 change (Add the "TCP Blackbox Recorder") I can't see anything obvious to tweak, unfortunately. It's a fair chunk of new code but it's all network-stack related, and my kernel is panicking long before any network activity happens. Any suggestions? Cheers, Andrew On Sat, Mar 24, 2018 at 05:23:18PM -0600, Warner Losh wrote: > Thanks Andrew... I can't recreate this on my VM nor my real hardware. > > Warner > > On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly > wrote: > > > So, r331464 crashes in the same place, on my system. r331064 still boots > > OK. I'll keep searching. > > > > One week ago there was a change to randomdev to poll for signals every so > > often, as a defence against very large reads. That wouldn't have > > introduced a race somewhere, > > or left things in an unexpected state, perhaps? That change (r331070) by > > cem@ is just a few revisions after the one that is working for me. I'll > > start looking there... > > > > Cheers, > > > > Andrew > > > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote: > > > Hi Warner, > > > > > > The breakage was in 331470, and at least one version earlier, that I > > updated past when it panicked. > > > > > > I'm guessing that kdb's inability to dump would be down to it not having > > found any disk devices yet, right? So yes, bisecting to narrow down the > > issue is probably the best bet. I'll try your r331464: if that works that > > leaves only four or five revisions. Of course the breakage could be > > hardware specific. > > > > > > Cheers, > > > -- > > > Andrew > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12-Current-r331347 panics on boot (r331346 and earlier didn't.)
OK, I've completed the search: r331346 works, r331347 panics somewhere in the initialization of random. In the 331347 change (Add the "TCP Blackbox Recorder") I can't see anything obvious to tweak, unfortunately. It's a fair chunk of new code but it's all network-stack related, and my kernel is panicking long before any network activity happens. Any suggestions? Cheers, Andrew On Sat, Mar 24, 2018 at 08:14:40AM -0600, Warner Losh wrote: > Also, what rev failed? I booted r331464 last night w/o issue. > > Warner > > On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly > wrote: > > > Hi all, > > > > For reasons that still escape me, I haven't been able to get a kernel dump > > to debug, sorry. > > > > Just thought that I'd generate a fairly low-quality report, to see if > > anyone has some ideas. > > > > The last kernel that I have that booted OK (and I'm now running) is: > > FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r331064M: Sat > > Mar 17 07:54:51 AEDT 2018 > > root@Zen:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > > amd64 > > > > The machine is a: > > CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.46-MHz K8-class > > CPU) > > Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 > > Features=0x178bfbff > APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > > Kernels built from head as of a couple of hours ago get through launching > > the other CPUs and then stops somewhere in random, apparently: > > > > SMP: AP CPU #2 Launched! > > Timecounter "TSC-low" frequency 1497223020 Hz quality 1000 > > random: entpanic: mtx_lock() of spin mutex (null) @ > > /usr/src/sys/kern/subr_bus.c:617 > > cpuid = 0 > > time = 1 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe4507a0 > > vpanic() at vpanic+0x18d/frame 0xfe450800 > > doadump () at doadump/frame 0xfe450880 > > __mtx_lock_flags() at __mtx_lock_flags+0x163/frame 0xfe4508d0 > > devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame 0xfe450900 > > g_dev_taste() at g_dev_taste+0x370/frame 0xfe450a10 > > g_new_provider_event() at g_new_provider_event+0xfa/frame > > 0xfe450a30 > > g_run_events() at g_run_events+0x151/frame 0xfe450a70 > > fork_exit() at fork_exit+0x84/frame 0xfe450ab0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfe450ab0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > KDB: enter: panic > > [ thread pid 14 tid 100052 ] > > Stopped at kdb_enter+0x3b: movq$0,kdb_why > > db> dump > > Cannot dump: no dump device specified. > > db> > > > > Now dumping worked fine the last time the kernel panicked: I have > > dumpdev=AUTO in rc.conf and I have swap on nvd0p3 (first) and > > /dev/zvol/root/swap > > (second, larger than the first.) > > > > Root on the nvd0p2 is ZFS, and ther's a four-drive raidZ with user > > directories and what-not on them, and another ZFS on an external USB drive > > that I use > > for backups, unmounted. > > > > In the new kernels, we clearly aren't even getting as far as finding the > > hubs and controllers, let alone the drives. > > > > I've attached dmesg.boot from the last boot from last week's good kernel. > > (While briefly in yoyo mode I turned the SMT back on, so now there are 16 > > cores > > instead of the eight mentioned in the crash dump. Didn't help, but I > > haven't turned it back off yet.) > > > > Cheers, > > > > Andrew > > > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12-Current panics on boot (didn't a week ago.)
Hi Jonathan, all, I've just compiled and booted a kernel derived from current-GENERIC but with nooptions TCP_BLACKBOX, and much to my surprise it boots. Possible link to network-related activities is that the next line of boot output that was not being displayed during the crash is: [ath_hal] loaded That's vaguely network-shaped: could it be an issue? Please let me know if there's anything else that I could test or poke, in order to find the real culprit. My make.conf says: KERNCONF=ZEN WRKDIRPREFIX=/usr/obj/ports MALLOC_PRODUCTION=yes My /usr/src/sys/amd64/conf/ZEN says: include GENERIC nooptions TCP_BLACKBOX Uname -a says: FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331768M: Sat Mar 31 10:47:52 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/ZEN amd64 Cheers, Andrew Here's the top part of the new dmesg.boot, FYI: Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r331768M: Sat Mar 31 10:47:52 AEDT 2018 root@Zen:/usr/obj/usr/src/amd64.amd64/sys/ZEN amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.45-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x7 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33271214080 (31729 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) random: unblocking device. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20180313/tbfadt-796) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1497224985 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8109f600, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 netmap: loaded module nexus0 vtvga0: on motherboard cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 350 Event timer "HPET2" frequency 14318180 Hz quality 350 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 amdsmn0: on hostb0 amdtemp0: on hostb0 On Sun, Mar 25, 2018 at 04:35:31AM +, Jonathan Looney wrote: > For now, you can update through r331485 and then take TCP_BLACKBOX out of > your kernel config file. That won’t really “fix” anything, but should at > least get you a booting system (assuming the new code from r331347 is > really triggering a problem). > > > I’ll take another look to see if I missed something in the commit. But, at > the moment, I’m hard-pressed to see how r331347 would cause the problem you > describe. > > > Jonathan > > On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly > wrote: > > > OK, I've completed the search: r331346 works, r331347 panics > > somewhere in the initialization of random. > > > > In the 331347 change (Add the "TCP Blackbox Recorder") I can't see > > anything obvious to tweak, unfortunately. It's a fair chunk of new > > cod
