Re: BIND update?
On 2008-Jul-10 11:40:06 +0200, Oliver Brandmueller <[EMAIL PROTECTED]> wrote: >shouldn't there be a very urgent BIND update somewhere around? There has been a very long thread about this in -security. Leaving out the trolls and flaming, the salient points are: - The bind port has been updated to include the relevant patches - The security team is aware of the issue and is working on a fix. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpy72N3Uj0PF.pgp Description: PGP signature
Re: FreeBSD-6.3 (amd64) mergemaster problem
On 2008-Jul-12 10:58:00 +0200, Roar Pettersen <[EMAIL PROTECTED]> wrote: >Trying to upgrade my FreeBSD-6.3-Stable (amd64) to FreeBSD-7.0-stable >(amd64), and after I have csup'ed the source and execute a >"mergemaster -i" then this error message occur : Maybe you left out a few steps but you need to do an installworld before you run 'mergemaster -i' - refer to /usr/src/UPDATING -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpyOyx7VmzH6.pgp Description: PGP signature
Re: Pseudoterminals increase: compilation error
On 2008-Jul-18 18:38:36 -0700, Unga <[EMAIL PROTECTED]> wrote: >As per FAQ, http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, I >tried to increase the number of ptys: > "10.19.1 > Build and install a new kernel with the line in the > configuration file: > device pty N > where N is the number of requested pseudoterminals." That has been obsolete for a while. Do you actually have a problem with insufficient PTYs? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpgdPMmJSPjj.pgp Description: PGP signature
Re: Pseudoterminals increase: compilation error
On 2008-Jul-19 19:44:18 -0700, Unga <[EMAIL PROTECTED]> wrote:
>truss -o truss.log -f expect -c "spawn ls"
>
> 1178: open("/dev/ptyp0",O_RDWR,027757763030)ERR#5 'Input/output error'
> 1178: open("/dev/ptyp1",O_RDWR,027757763030)ERR#5 'Input/output error'
> 1178: open("/dev/ptyp2",O_RDWR,027757763030)= 5 (0x5)
> 1178: fstat(5,{mode=crw-rw-rw- ,inode=178,size=0,blksize=4096}) = 0 (0x0)
> :
> :
> 1178: chown("/dev/ttyp2",1002,4)ERR#1 'Operation not
> permitted'
This is definitely wrong. expect should not be calling chown(2),
it should be calling pt_chown.
>I'm using Expect-5.43.0 compiled from sources.
>
>So, it looks like some sort of a misconfiguration. Still investigating.
Have you built the FreeBSD port or used your own build configuration?
If the latter, I suggest you build the port - it works for me.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpJWcB8BpLRs.pgp
Description: PGP signature
Re: DigiBoard Xem with 2 extenal modules
On 2008-Aug-04 13:49:58 -0300, Alexandre Biancalana <[EMAIL PROTECTED]> wrote: >Modems connected but they only work on ports of the first module, any >decice connected on ports of second module does not work. ISTR the problem I ran into was that the octet read out of the driver bore little resemblance to the serial data written into the port. The bit-rate would match and framing was reported as correct but I would get nonsense in the top or bottom 4 bits. My notes are at work and I'll try and dig them up tomorrow. >Any other idea ? All I can suggest is comparing the Linux driver with the FreeBSD one (and maybe someone needs to confirm if it works in Linux). I couldn't find a difference but maybe someone will see something I missed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpUvI9NuauSF.pgp Description: PGP signature
Re: i386 vs amd64?
On 2008-Aug-08 14:36:42 +0200, Oliver Fromme <[EMAIL PROTECTED]> wrote: >For example, in amd64 mode there are twice as many CPU >registers available, enabling better optimizations for >the C compiler. Furthermore those registers are twice >as long, which means that 64bit quantities can be handled >with single processor instructions. OTOH, this means roughly 4 times as much processor state to save and restore on a context switch. It also means that longs and pointers are 64-bits instead of 32-bits, which makes executables larger (if you compare executables and libraries on disk between FreeBSD/i386 and FreeBSD/amd64, the latter are 10-15% larger). The VSZ of amd64 executables _appears_ significantly larger due to a bug in binutils and our rtld but this space is never referenced. >That doesn't necessarily mean that code will always run >faster in amd64 mode. There have been reports of certain >edge cases. But in general, amd64 code is faster. As always, the best benchmark is your own application mix. >Bottom line: Install FreeBSD/amd64, unless you have >_specific_ reasons to stay with i386. Keep in mind that, for most things, FreeBSD/amd64 can happily run 32-bit Linux and FreeBSD/i386 executables (though there's no easy way to build FreeBSD/i386 executables on FreeBSD/amd64). This does not extend to KLDs so 3rd-party 32-bit KLDs (eg the nVIDIA graphics driver). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpCU0aTvVdWo.pgp Description: PGP signature
Re: lagg(4) and failover
On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein <[EMAIL PROTECTED]> wrote: >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. As far as I can tell, not especially well :-(. It doesn't seem to detect much short of layer 1 failure. In particular, shutting down the switch port will not trigger a failover. >> The manpage isn't quite clear: >> >> failover Sends and receives traffic only through the master port. >> If >> the master port becomes unavailable, the next active port >> is >> used. The first interface added is the master port; any >> interfaces added after that are used as failover devices. >> >> What is meant by "becomes unavailable"? Is it just the physical link which >> needs to become unavailable to trigger a failover? It seems to be, >Yes. It seems you need lacp protocol described later in the manual. Actually, lacp and failover are used differently: lacp is primarily used to increase the bandwidth between the host and the switch whilst failover is used for redundancy. With lacp, all the physical interfaces must be connected to a single switch. With failover, the physical interfaces will normally be connected to different switches (so a failure in one switch will not cause the loss of all connectivity. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpGk05yQX4JR.pgp Description: PGP signature
Re: lagg(4) and failover
On 2008-Aug-12 13:43:29 +0200, Marian Hettwer <[EMAIL PROTECTED]> wrote: >> lagg is to handle failover at the physical layer for when one of your >> ether ports fails, or someone unplugs a cable. If I understand you >> >Thats unfortunate... I tend to agree. >bonding in Linux is capable of doing this and solaris too. It shouldn't be too difficult to create something that behaves functionally similarly to Slowaris ipmpd (and with marginally more effort, you could create something that could be configured to behave sensibly). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgph5IlfzxY1r.pgp Description: PGP signature
Re: the future of sun4v
[Replies re-directed to freebsd-sun4v] On 2008-Aug-21 14:42:55 -0700, Kip Macy <[EMAIL PROTECTED]> wrote: >I believe that there is a general expectation by freebsd users and >developers that unsupported code should not be in CVS. Although sun4v >is a very interesting platform for developers doing SMP work, I simply >do not have the time or energy to maintain it. If someone else would >like to step up and try his hand I would be supportive of his efforts. >In the likely event that no one steps forward by the time that 7.1 is >released I will ask that it be moved to the Attic. Since there are no other current SPARC CPUs that FreeBSD can run on (the US-II has been obsolete for about 6 years and FreeBSD won't run on any more recent sun4u chips), that will also remove the justification for maintaining a SPARC64 port. I don't have the knowledge or available time to maintain the sun4v port by myself but would be happy to be part of a team doing so. One impediment I have is that I don't have a T-1 or T-2 system that I can dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but since FreeBSD doesn't support either the virtual disk or virtual network, actually getting FreeBSD running there presents somewhat of a challenge. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpYZcaPY2ZT8.pgp Description: PGP signature
Re: sun4v arch
On 2008-Aug-22 17:04:00 +0200, Kris Kennaway <[EMAIL PROTECTED]> wrote: >Just so everyone is on the same page, what is needed to keep sun4v >viable are people with experience with (or intention to learn about) low >level architectural and implementation details of the FreeBSD kernel What documentation is currently accurate for this beyond the source code? The only things I can quickly find are: "Design & Implementation of FreeBSD 5.2" and "FreeBSD Architecture Handbook". The former is getting quite old and I'm not sure how up-to-date the latter is kept. >the sun4v hardware platform, Is the documentation at http://www.opensparc.net/opensparc-t1/index.html and http://www.opensparc.net/opensparc-t2/index.html adequate for this or is there additional information that is needed? Is there any tutorial style documentation on the low-level T1/T2 details? > who know their way around things like >pmap.c and other MD places where the kernel interfaces with the "bare >metal", I've poked around the low-level details of FreeBSD/i386 and /Alpha in the past, though I'm nothing like an expert at it. sun4v/sun4v is only about twice the size of a 6th Edition kernel... > and who are willing to make a long term (multi-year) commitment >to supporting the platform. Yes. Is there a summary of the open issues somewhere? There are no sun4v PRs open. http://wiki.freebsd.org/FreeBSD/sun4v effectively hasn't been touched since November 2006 and suggests that the only critical issue is lack of serial port support. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpBk7ynbGdXo.pgp Description: PGP signature
Re: sun4v arch
On 2008-Aug-23 22:40:55 -0500, Mark Linimon <[EMAIL PROTECTED]> wrote: >My understanding is the the port is in a pre-alpha state due to unfinished >work in the kernel, so expecting there to be any userbase is premature. Except that the wiki gives a far more optimistic picture. >All of our 'new' architectures which are in this state have so few non- >developer users that there is hardly any reason to submit PRs. AFAICT >the active developers already know what's missing :-) That makes it very difficult for someone outside that group to come up to speed. I can't find anything in the freebsd-sun4v archvies. I was hoping that there would be a list somewhere of what state various subsystems were in and what remained to be done. wiki.freebsd.org sounds like the ideal place for this. On 2008-Aug-23 20:39:29 -0700, Garrett Cooper <[EMAIL PROTECTED]> wrote: >Maybe some time should be spent looking at stuff from NetBSD to see >whether or not they've solved some already critical porting pieces >that FreeBSD lacks in this architecture? I can't find anything that suggests NetBSD runs on sun4v. Their sparc64 port only covers the US-I/II families and there's no mention of sun4v. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpoen3snXqeK.pgp Description: PGP signature
Re: sun4v arch
On 2008-Aug-23 21:39:34 -0700, Kip Macy <[EMAIL PROTECTED]> wrote: >There really isn't any magic to bringing up a port. You compile it, >install it, and then run it until it breaks. Once it breaks you spend >a lot of time instrumenting the code to track down what went wrong. About what I expected. I've just bumped into your bsdtalk interview: http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk086.mp3 This appears to give a useful overview into the sun4v port. One thing you mention is that you'd started work on a virtual network driver. How far did this get and can you point me to the code, It seems that the latest OpenBSD runs on sun4v. I haven't investigated how well supported it is. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpP83c1ntCdU.pgp Description: PGP signature
Re: Is it safe to delete /bin/[ && /usr/bin/false?
On 2008-Sep-02 10:49:43 -0700, [EMAIL PROTECTED] wrote: >Well, I en devoured to install a copy of 7 as an effort to upgrade >one of our servers. After installing a few ports, I began to notice: >[: -le: argument expected messages being emitted during the configure/make >process. This probably indicates badly written configure scripts that have things like "[ 23 -le $x ]" but don't set $x. The solution is to write patches for the configure scripts and feed them back upstream. > I've already invested a fair amount of time on this upgrade, >and /really/ don't want to wipe the disk(s) and start all over. I'm not sure how this will help. > This >issue is not new to me - see thread:[: -le: argument expected for details. You haven't mentioned where this thread exists - definitely not here. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp1y0WTnMeFm.pgp Description: PGP signature
Re: FreeBSD 7.1 Content
On 2008-Sep-03 10:36:11 -0600, Dan Allen <[EMAIL PROTECTED]> wrote: >Also, and I am sure I am not the only one with one of these, my new >$500 Dell Inspiron 1525 is not supported well by BSD RELENG_7: the >Intel 4965 wireless and the Marvell 88E80xx Ethernet are both NOT >supported so I have a great new laptop which cannot connect to the >outside world with BSD. :-( Ubuntu supports these and lots more. Your patches to add support for the i4965 and your Marvell 88E80xx must have been stripped by the mailing list software. Can you please re-send them. WiFi chip support is very hit-and-miss. Vendors won't release programming information because of regulatory issues and this makes supporting them very difficult. Have you tried using ndis? A large number of Marvell 88E80xx chips are supported by msk(4). If yours isn't, you are going to need to provide more details on what chip you have. >I would like to see FreeBSD 7.1 add to its disc1: > >1) X.org >2) icewm >3) firefox-3.0 >4) support for Intel 4965 wireless drivers >5) support for Marvell 88E8040 ethernet driver Disc1 is full. What do you suggest should be removed from disk1 to make space for the above? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp0pnQt3pGGi.pgp Description: PGP signature
Re: FreeBSD 7.1 Content
On 2008-Sep-03 15:53:30 -0600, Dan Allen <[EMAIL PROTECTED]> wrote: >I see. I was thinking of FreeBSD 7.0 whose disc1 is 509 MB in size, >leaving almost 200 MB free for a standard 700 MB CD. I missed that the disc layous have been rearranged and disc1 is now somewhat emptier than when I last looked. However, you've missed a few points as well: 1) Currently, the contents of each disk is the same on each architecture. Changing this is possible but would be very confusing to users. sparc64 appears to be the largest and disk1 is over 600MB. 2) Traditionally, the ISO images have been sized to fit on 650MB CD-RWs. Maybe this should be revisited but during a release freeze is not the right time for that. 3) It's desirable to leave some slack so that a slight size increase in the final builds doesn't necessitate re-working the CD layouts. >Ubuntu 8.04 has room for [the kitchen sink] For most architectures, disc1 includes a live filesystem. This is very useful for recovery purposes. Since FreeBSD does not include cloop or similar compressed FS support, this takes a fair amount of space. And you've already pointed out that disc1 includes sources (which you want to keep). >Here is a quick list (not exhaustive or definitive) of the libraries >that Firefox 3.0 requires, and their sizes in bytes: Note that you need to include the space needed by the packages for all the FF3 dependencies, not just the shared libraries. >These total 27696575 bytes or 26.4 MB. Including the full list of runtime dependencies, FF3 needs 120 packages, totalling 89MB (already bzip'd) on i386. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpBlyRMOzsYq.pgp Description: PGP signature
Re: crossbuilding of RELENG_7 broken?
On 2008-Sep-15 18:18:28 +0200, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
>Peter Jeremy wrote:
>> On 2008-Sep-14 18:21:45 +0200, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
>>> Building them works fine, but when I nfs-mount /usr/obj and /usr/src on the
>>> target system, install does not work. Neiter installkernel nor installworld.
>>
>> You're going to have to give more detail - like your exact command and
>> the last few dozen lines of the make install{world,kernel} output.
>>
>
>So well, here it is:
>
>Command on the amd64 build machine:
>
># env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7 make -j4 buildworld buildkernel
>KERNCONF=VECTRA-7
>
>It builds without incident and yes I did try without -j4 and it didn't work
>either.
>
>On the i386 target machine, /usr/src and /usr/obj are NFS mounts:
>
>===
>
># env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 make installkernel
>KERNCONF=VECTRA-7
I didn't understand exactly what you were doing before. The
install{world,kernel} must be executed on the same architecture (and
similar FreeBSD version) as the build{world,kernel} because the
install{world,kernel} executes code that was built as part of the
buildworld.
Rather than NFS mounting the buildhost onto the target and running
install{world,kernel} on the target, you need to NFS mount the target
/ and /usr onto the buildhost and use DESTDIR to point the install at
the correct location. This will work, modulo some chflags issues
(chflags isn't supported over NFS - I don't recall offhand where this
is discussed but google should be able to help).
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpMesWTNa4uv.pgp
Description: PGP signature
Re: Rare problems in upgrade process (corrupted FS?)
On 2008-Sep-26 12:22:55 +0200, Jordi Espasa Clofent <[EMAIL PROTECTED]> wrote: >1) I do the sync process with csup(1); next I go into >/usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized >kernels) and this file doesn't exists. You might like to check your CVSup site against http://www.mavetju.org/unix/freebsd-mirrors/ to confirm it is updating correctly. GENERIC should exist. >* I reboot the machine (because of I suspect a very weird FS problem), >boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) >found and repair several errors. Epecially, one error claims my >attention: SUPERBLOCK. It might have been useful if you had kept a record of the exact messages. If you repeat the fsck, does it now report any problems? If you are using an up-to-date CVSup mirror, my next suggestion would be hardware problems. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpc1Ionz3bYP.pgp Description: PGP signature
Re: Rare problems in upgrade process (corrupted FS?)
On 2008-Sep-26 13:23:12 +0200, Jordi Espasa Clofent <[EMAIL PROTECTED]> wrote: >Connecting to cvsup.de.FreeBSD.org Edwin's script reports this as up-to-date. ># cd /usr/src ; ls -la >total 0 But something is obviously wrong. Can you post your supfile please. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpAG1RvfOlva.pgp Description: PGP signature
Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour!
Hi Anton, On 2008-Sep-26 15:13:19 +0300, Anton - Valqk <[EMAIL PROTECTED]> wrote: >you are right that the machine has *lots* ot hardware in it, >I was thinking of the power supply as a reason and measured the 5 and 12 >volts - seemd to be ok 11.8 and 5.2 with all hardware in it. A multimeter won't show noise or load spikes. That said, if the PSU is reasonably new and running well within its ratings, it shouldn't be a problem. >1. remove rl0 and run only one isp for the test. It's definitely worthwhile getting rid of rl(4) cards. Read the top of the driver source for reasons. >3. try to replace the ATA100 cables (the one with 80 wires) with an >older ones with only 40 cabels? I wouldn't recommend this. The 80-wire cables are electrically much better than the 40-wire ones. You might like to try a different cable. You should verify that the master/slave/MB sockets on the cable are plugged into the correct device. If you want to slow down the ATA bus, I suggest you do it in software. >4. ? anything else? Try disconnecting some of the disks and see if the problem goes away - this would help rule out PSU problems. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpMmVmLW3BJt.pgp Description: PGP signature
Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour!
On 2008-Sep-26 13:12:14 +0300, Anton - Valqk <[EMAIL PROTECTED]> wrote: >1. I get a lot of dma times outs. mostly on ad5 and ad7 where I keep ... >dmesg.today:ad7: FAILURE - WRITE_DMA48 status=51 >error=10 LBA=374303456 This is a bad sign and suggests dying disk but... >2. The other strange issue is that when (I guess) it starts timeouting >*sometimes* not everytime I'm loosing connection to xl0 or fxp0 You have an awful lot of hardware in this box. Are you sure the power supply and cooling is up to scratch? Sagging power could cause the problems you report, as could overheating. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpwR8dFmRPsS.pgp Description: PGP signature
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
On 2008-Sep-26 23:44:17 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: >On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote: >> As far as I know (at least ideally, when write caching is disabled) ... >FreeBSD atacontrol does not let you toggle such features (although "cap" >will show you if feature is available and if it's enabled or not). True but it can be disabled via the loader tunable hw.ata.wc (at least in theory - apparently some drives don't obey the cache disable command to make them look better in benchmarks). >Users using SCSI will most definitely have the ability to disable >said feature (either via SCSI BIOS or via camcontrol). Soft-updates plus write caching isn't an issue with tagged queueing (which is standard for SCSI) because the critical point for soft-updates is knowing when the data is written to non-volatile storage - which tagged queuing provides. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp72bNCQab19.pgp Description: PGP signature
Re: sysctl maxfiles
On 2008-Sep-27 22:14:09 +0200, Miroslav Lachman <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] ~/# fstat -u www | wc -l > 9931 >[EMAIL PROTECTED] ~/# fstat -u root | wc -l > 718 >[EMAIL PROTECTED] ~/# fstat | grep httpd | wc -l > 6379 >[EMAIL PROTECTED] ~/# fstat | grep httpd | wc -l > 6002 >[EMAIL PROTECTED] ~/# fstat -u www | wc -l > 4691 >[EMAIL PROTECTED] ~/# sysctl kern.openfiles >kern.openfiles: 846 kern.openfiles reflects the total number of open file structures within the kernel, whereas fstat (and lsof) report both open files and vnodes associated with each process. The differences are 1) File structures are shared via fork() etc so the same file structure can be reported multiple times. 2) fstat reports executable name, working directory and root Open files in fstat can be detected because they have numeric values (possibly with a '*' appended) in the FD column. Unfortunately, there doesn't appear to be any easy way to detect shared file structures (for inode-based files) using either fstat or lsof. In the case of apache, there are at least 6 file structures shared by each httpd process (and it looks like it might be about 15). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpFX8suq2Bn0.pgp Description: PGP signature
Re: sysctl maxfiles
On 2008-Sep-28 08:29:20 +1000, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: >I guess then I should ask the question a different way. How much >memory does each fd use and which pool of memory does it come from? 72 bytes for i386, 120 bytes for amd64. It's a UMA zone 'Files'. You can check with 'vmstat -z|grep Files' -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp96NLXV1r3U.pgp Description: PGP signature
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
Please wrap your mail before 80 columns. On 2008-Oct-06 06:19:34 -0700, Unga <[EMAIL PROTECTED]> wrote: >The FreeBSD stable comes with gcc-4.2.1 but the sources are scattered >over the /usr/src, therefore, I find it difficult to re-create the >gcc-4.2.1 to its original directory layout to make a patch. The original sources for gcc can be found in /usr/src/contrib/gcc - note that this is not a complete gcc 4.2.1 distribution as parts of gcc that are not relevant for FreeBSD have been deleted. Refer to the FREEBSD-* files for details. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpR6Xaf4xjLH.pgp Description: PGP signature
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
On 2008-Oct-07 02:06:03 -0700, Unga <[EMAIL PROTECTED]> wrote: >Now I unpacked the gcc-4.2.1.tar.bz2 into some other directory and applied >this FreeBSD-gcc.patch. Ran configure and compiled. It develop following error: >../../gcc-4.2.1/gcc/c-format.c:1780: error: 'flag_format_extensions' >undeclared (first use in this function) >../../gcc-4.2.1/gcc/c-format.c:1780: error: (Each undeclared identifier is >reported only once >../../gcc-4.2.1/gcc/c-format.c:1780: error: for each function it appears in.) >gmake[2]: *** [c-format.o] Error 1 Note that the FreeBSD gcc is not built using the gcc configure script. Instead, all the target-specific configuration is under /usr/src/gnu/usr.bin/cc -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpMQOa258nXA.pgp Description: PGP signature
Re: cvsup 7.0 STABLE checkout failure
On 2008-Oct-11 08:24:51 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: >csup and cvsup function the same, and they both rely on the same source >versioning system. Note that csup only supports a subset of cvsup functionality. The most obvious missing feature is CVS mode. >If you really want Windows and FreeBSD to "play well" together, your >best option is to run Samba on the FreeBSD box and use UFS2 filesystems, >then make the Windows machine mount shares from the FreeBSD machine. I agree in general but this can also lead to similar gotchas on the Windows side if the Unix side has files differing only in case. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgprbYRrbivYj.pgp Description: PGP signature
System hanging during dump
Last night, I attempted a full, compressed backup of my 181GB /home (on a PATA disk) to a remote system. The backup started at 2159 and everything appeared normal until about 0040 when the system became non-responsive and this lasted until the dump completed at 1033. This is the first full backup of /home I've made for several years (due to lack of space). I noticed the non-responsiveness at about 0500 when: - The dump, gzip and fifo pipeline were running normally. - A 'systat -v' I had started was running normally (though it reported an excessive number of 'D' processes). Other values all appeared normal. - No response to return key at a zsh prompt - No response to up/down arrows in mutt [above all done in pre-existing ssh sessions from another host] - telnet to port 22 connected but didn't produce a banner. The duration above is based on system logs - which show nothing happened during this period. At the end, there were various anomolous entries: Oct 15 10:33:27 server ntpd[750]: too many recvbufs allocated (40) Oct 15 10:33:30 server sshd[947]: error: accept: Software caused connection abort Oct 15 10:33:34 server kernel: TCP: [192.168.123.123]:59516 to [192.168.123.200]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Possibly useful information: The dump pipeline was: dump -uaL0 -C 32 -f - /home | reblock | gzip [stdout connected to socket to remote server] 'reblock' is basically a 200MB FIFO I wrote to desynchronise the (often I/O bound) dump from the CPU-bound gzip. server% uname -a FreeBSD server.vk2pj.dyndns.org 7.0-STABLE FreeBSD 7.0-STABLE #18: Sun May 18 15:02:39 EST 2008 [EMAIL PROTECTED]:/var/obj/k7/usr/src/sys/server i386 server% df -ki Filesystem 1024-blocks Used Avail Capacity iusedifree %iused Mounted on /dev/ad0s3d 204648864 181911710 636524697% 1703016 11353942 13% /home About the only think that happened at around this time was nightly updates. These start at 0005, fetching CTM cvs-cur updates, applying them to /home/ncvs, then cvs updating /home/ports. Looking at timestamps, /home/ports/graphics/icod/CVS/Entries was updated at 0042 and /home/ports/graphics/imlib2_loaders/CVS/Entries (the next entry) was updated at 1034. Whilst /home is fairly full, I can't see that the snapshot meta and rollback data would have occupied the 20GB free (and no 'out-of-space' messages were generated). Is there some limit on the number of inodes that can be updated whilst a snapshot exists? Has anyone else seen anything similar? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpNOZB8Q8ZWj.pgp Description: PGP signature
Re: System hanging during dump
On 2008-Oct-15 01:35:38 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: >On Wed, Oct 15, 2008 at 07:24:28PM +1100, Peter Jeremy wrote: >> Last night, I attempted a full, compressed backup of my 181GB /home >> (on a PATA disk) to a remote system. The backup started at 2159 and >> everything appeared normal until about 0040 when the system became >> non-responsive and this lasted until the dump completed at 1033. This >> is the first full backup of /home I've made for several years (due to >> lack of space). ... >It's a known problem documented in my Wiki -- see "dump/restore". Note >the part about UFS2 snapshot generation. I'm almost certain this is >what you're describing. No, my problem is not mentioned in your Wiki. You mention: * dump process frequently hangs In my case, the dump was progressing normally. The _rest_ of the system was hung. * UFS2 snapshot generation (mksnap_ffs, dump -L) takes too long; system is unusable during this time In my case, snapshot creation took ~4 minutes. The system was running normally for 2.6 hours after snapshot creation completed before it froze. * Filesystems not cleanly shut down if reboot performed while dump(8) still running Not applicable. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpTcDRKl5zyJ.pgp Description: PGP signature
Re: System hanging during dump
On 2008-Oct-15 02:08:48 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: >On Wed, Oct 15, 2008 at 07:58:43PM +1100, Peter Jeremy wrote: >> On 2008-Oct-15 01:35:38 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: >> >On Wed, Oct 15, 2008 at 07:24:28PM +1100, Peter Jeremy wrote: >> >> Last night, I attempted a full, compressed backup of my 181GB /home >> >> (on a PATA disk) to a remote system. The backup started at 2159 and >> >> everything appeared normal until about 0040 when the system became >> >> non-responsive and this lasted until the dump completed at 1033. This >> >> is the first full backup of /home I've made for several years (due to >> >> lack of space). >> ... >> >It's a known problem documented in my Wiki -- see "dump/restore". Note >> >the part about UFS2 snapshot generation. I'm almost certain this is >> >what you're describing. >> >> * UFS2 snapshot generation (mksnap_ffs, dump -L) takes too long; system is >> unusable during this time >> In my case, snapshot creation took ~4 minutes. The system was >> running normally for 2.6 hours after snapshot creation completed >> before it froze. > >Did you read the References, including the one from myself? Yes. In my case, dump started and ran mksnap_ffs. About 4 minutes later, actual dumping started and data streaming continued for about 12.6 hours. The system froze about 2.6 hours into the dump (after dump had written about 31GB). >Snapshot generation in some cases took only minutes, but *removal* of >the generated the snapshot took 1.5 hours or more, hanging the system >until the removal was complete. Based on progress reports from both dump and my fifo process, the snapshot removal began about 10 hours _after_ the system froze (during this time, dump wrote about 143GB). Given the timeline, it's fairly clear that neither mksnap_ffs nor the 'rm snapshot' were running at the time the system froze. I am therefore quite confident that the problem I saw is not related to either creation or removal of snapshots. I have been using FreeBSD snapshots for many years and am quite familiar with their quirks. I have never seen this particular problem before. (And FWIW, I _am_ using Doug Ambrisko's patch to ffs_snapshot.c). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpUGb0tzBynz.pgp Description: PGP signature
Re: System hanging during dump
On 2008-Oct-15 21:37:36 +0100, Kris Kennaway <[EMAIL PROTECTED]> wrote: >Peter, there was a bug causing dump to hang (completely unrelated to >UFS2 snapshot generation) merged to RELENG_7 a month or so ago. Can you >try updating? Well, dump wasn't hanging, rather it was hanging the rest of the system. In any case, I have upgraded to a recent -stable and am no longer able to reproduce the problem. I have built myself a looping 'ps -axl' which should let me gather more information if it does re-appear. (In the process, I've found that ps leaks memory, though that's not a problem until you wrap it in a loop). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpvU81MKcZ1y.pgp Description: PGP signature
Re: System hanging during dump
Sorry for the late reply.
On 2008-Oct-19 11:39:02 +0300, Kostik Belousov <[EMAIL PROTECTED]> wrote:
>> I have built myself a looping 'ps -axl' which should let me gather more
>> information if it does re-appear. (In the process, I've found that ps
>> leaks memory, though that's not a problem until you wrap it in a loop).
>
>What memory ? Kernel one ? How did you noted this ? Could you add
>vmstat -z and vmstat -m to the loop and watch what allocation grows ?
ps(1) malloc's memory and doesn't free it. This isn't an issue in
normal operation because it's a once-through program. I hacked ps to
turn the guts of main() into a while(1){} loop and this showed the
process was growing. There were a couple of superfluous strdup()
calls that could be removed but I don't think it's worth making it
exhaustively clean up after itself (my hacking included hard-wiring
the options so I'm not sure my cleanup code is complete in the general
case). As a low priority, I'll create a PR covering the strdup's.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpDJgpu89NBs.pgp
Description: PGP signature
Re: System deadlock when using mksnap_ffs
On 2008-Nov-12 20:47:37 -0800, Doug Ambrisko <[EMAIL PROTECTED]> wrote: >I plan to commit it tomorrow since I sent it to Tim to test. The 10 can >be tuned but it has kept a bunch of machines at work up. Glad people >don't think it is that it is to wrong :-) It probably could be made >a little more dynamic but I wonder if it would show any real performance >difference and might risk more bugs. FWIW, I've been running the patch since I first saw Doug post it in Feb 2006 and don't recall ever having problems with mksnap_ffs since applying it (I did before) -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpXbZklXqxzU.pgp Description: PGP signature
Re: _nyssin undefined
On 2008-Nov-15 12:55:12 -0500, "J. W. Ballantine" <[EMAIL PROTECTED]> wrote: >Yesterday AM, 11/14, I cvs'ed the 7-stable sources and did a >system build/install. Now all I get is: > /lib/ld-elf.so.1: /lib/libc.so.7: Undefined symbol _nyssin. I don't recognize and can't find that symbol in my (older) 7-STABLE sources so I'm not sure what might have triggered it. However, I don't have ld-elf.so.1 in /lib - it's in /libexec. Is that a typo on your part? At what point do you get that error? Can you get to a single user mode shell? The previous ld-elf.so.1 is saved as /libexec/ld-elf.so.1.old - you can use tools in /rescue to rename it (you will need to use chflags to clear the schg flag on /libexec/ld-elf.so.1 before you can overwrite it). Unfortunately, there's no backup of /lib/libc.so.7 so if that's the problem, you will need to recover it from backups or a live filesystem CD. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpEiIzafN6xO.pgp Description: PGP signature
Re: _nyssin undefined
On 2008-Nov-17 08:56:55 -0500, "J. W. Ballantine" <[EMAIL PROTECTED]> wrote: >The problem started during the install of a new system build using >the Friday AM CVS bits, and I can't get on the system in any >mode. If you try to boot to single-user, do you get the "enter shell pathname" prompt? If so, does specifying "/rescue/sh" give you a shell? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmSqvmvDY6d.pgp Description: PGP signature
Re: Possible regression in ifconfig under7.0 - removes validdefault route
On 2008-Nov-17 23:36:19 +0100, [EMAIL PROTECTED] wrote: >Oh yeah, since we're in wishful thinking mode, I want interface >descriptions too... Have you looked at the 'name' and 'group' keywords in ifconfig(8)? If this isn't what you want, please expand on your wish. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpUQ9NRz3MHu.pgp Description: PGP signature
Re: Integrated RTL8168/8111 NIC not assigned interface
On 2008-Nov-21 00:07:26 -0800, hamtilla <[EMAIL PROTECTED]> wrote: >I'm running 7.0-RELEASE-i386 on Jetway's NC92-N230 mainboard. The board has >one integrated RTL8168/8111 gigabit NIC as well as an expansion board with >three RTL8168/8111 NICs. Why would the three NICs work while the onboard NIC >does not? > >[EMAIL PROTECTED]:1:0:0: class=0x02 card=0x816810ec chip=0x816810ec >rev=0x02 hdr=0x00 >vendor = 'Realtek Semiconductor' >device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' >class = network >subclass = ethernet >[EMAIL PROTECTED]:2:4:0: class=0x02 card=0x10ec16f3 chip=0x816710ec >rev=0x10 >hdr=0x00 >vendor = 'Realtek Semiconductor' >device = 'RTL8169/8110 Family Gigabit Ethernet NIC' >class = network >subclass = ethernet ... The on-board NIC is a different type to your expansion cards (note the different 'chip=' values. Looking at the code, it appears that only some variants of the RTL8168 are supported in 7.x. Unfortunately, pciconf doesn't report the actual hardware revision, so you can't tell from the pciconf output whether it's supported or not. Can you report the output of 'pciconf -r pci0:1:0:0 0x40' (which should report the hw revision) and 'pciconf -r pci0:2:4:0 0x40' (which gives me a double-check). You could try booting -current and see if the on-board NIC works there - the range of supported NICs has changed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpIjKHCuZw8G.pgp Description: PGP signature
Re: RELENG_7_1: Laptop mouse (psm0) disappeared??!?
On 2008-Nov-25 12:09:07 -0800, David Wolfskill <[EMAIL PROTECTED]> wrote: >I was running the recently-tagged RELENG_7_1 on my laptop, doing stuff >involving switching among a small handful of xterms, when the mouse >became unresponsive. ... > psm0: failed to reset the aux device. > psm0: the aux device has gone! (reinitialize). My son's HP v6107 running 6.4-PRERELEASE/amd64 does this occasionally as well. I haven't found any solution other than reboot either. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp0Te6o1u289.pgp Description: PGP signature
Re: RELENG_7_1: Laptop mouse (psm0) disappeared??!?
On 2008-Nov-27 00:09:39 -0200, "Carlos A. M. dos Santos" <[EMAIL PROTECTED]> wrote: >On Wed, Nov 26, 2008 at 6:50 AM, Peter Jeremy ><[EMAIL PROTECTED]> wrote: >> My son's HP v6107 running 6.4-PRERELEASE/amd64 does this occasionally >> as well. I haven't found any solution other than reboot either. > >I'd suggest you to attempt upgrading the BIOS, if you did not make it >before. Version F.3D fixes some touchpad issues. Thanks for the suggestion but it's already running F.3D. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpc6gVyvKckF.pgp Description: PGP signature
Re: sysinstall automatic partition labelling/sizing problem
On 2008-Dec-03 15:42:04 +0900, Nathan Butcher <[EMAIL PROTECTED]> wrote: >Automatic labelling on 7.0 created about 360MB for my root partition on >a 8GB disk. After a buildkernel into 7.1-PRERELEASE, the root partition >was exhausted during the installkernel. Are you running i386 or amd64? 360MB _is_ a very tight fit for amd64 but you should make it unless you have some large, unexpected files lying around in your root partition. As a workaround, you could remove *.symbols from the old kernel files. >Maybe automatic labelling in sysinstall needs to allocate more than >360MB in the root (/) partition if it's going to stay big enough to >accomodate a buildkernel and installkernel from source. Looking at sysinstall, the default size is currently 512MB unless you have less than ~20GB, when it will start scaling down. Your options are: 1) Expand root (maybe use growfs and eat into your swap) 2) Avoid building unwanted modules via MODULES_OVERRIDE. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpDpdRtIhm2G.pgp Description: PGP signature
Re: lagg(4) and failover
On 2008-Dec-05 07:34:21 -0500, "Brian A. Seklecki" <[EMAIL PROTECTED]> wrote: >Well ... name a price for the development; HA L1/L2 is a feature the >community would gladly sponsor the development of. net/ifstated covers at least some of this. >Also, Peter, you should put a page up on the FreeBSD wiki with some of >those multi-catalyst LACP IOS config examples. This appears to be aimed at Pete French - I'm using stacked Alcatel-Lucent OS6850's which appear as single switches to LACP. >P.S., in my experience, system level redundancy/HA with a load balancer >is almost always less expensive then excessive component-level >redundancy/ha (RAID Disk, RAID RAM, Dual Power Supplies, Dual >Backplanes...) That's a different topic, but yes, you should evaluate your requirements at a system level, rather than just making every component HA. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgps6KI1leVrl.pgp Description: PGP signature
Re: visibility of release process
On 2008-Dec-08 20:57:37 +1100, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: >* subversion. Without checking out the whole repository, it is a >little hard to use this as a news source and emails to the commit list >still look more like cvs than svn so it is a bit hard to see which >branch commits are going to. [3] I'm not sure what you want here. The branch is clearly indicated in both the subject and body of commit messages. What do you mean as "news source"? Commits are inherently low level and it's difficult to see how a commit could be massaged into some sort of press release without a fair amount of meta information in the commit log. >* the bug tracker. Let's just say that FreeBSD's bug tracker is fairly >primitive and 'target release' is not an option. Agreed. This is an issue that comes up regularly but I don't believe a solution has been identified. I suspect one of the requirements would be that it be FOSS. >2. Some web based friendly end-user visibility on the commit process, >per branch. I presume you're aware of svn.freebsd.org. > People can see what is going in and being fixed, but not >what is left outstanding. If you mean open PRs, lists are regularly reported to various mailing lists and can be accessed via http://www.freebsd.org/cgi/query-pr.cgi Better integration of the PR and commit process might be nice but I'm not sure if it's practical with gnats. >[3] I've also made an attempt to have Atlassian use Fisheye to >produce an friendly overview of the repository, I've had a look at several of the fisheye sites and am not sure what it would buy the Project, other than some pretty graphs. I don't see how this is any more "friendly" than svn.freebsd.org. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpboYwVpAijm.pgp Description: PGP signature
Re: lagg(4) and failover
Please wrap your mail before 80 columns. On 2008-Dec-08 23:58:00 -0800, Tom Samplonius <[EMAIL PROTECTED]> wrote: > The Linux bonding driver supports probing the default gateway. This is the same brokenness as Solaris IPMP. I agree that probing an external IP address (probably, but not necessarily a gateway) is the way to go but you need to be able to configure this. Otherwise you need to jump through hoops where the interfaces you are protecting is not the default route (or there are multiple independent groups of interfaces being protected). > Now, it uses ARP for this (probably because the ARP who-has code is >also in the kernel and easily accessible), which also not so great, I don't see that it's necessary to have the interface failover code in the kernel. The kernel needs hooks to allow a daemon to bind to the physical interfaces and control which one is active, but the actual code that decides how to determine which interface is active should be in userland. (Note that routing works this way). >switches do not support multi-switch 802.3ad yet, and most probably >never well. So you are limited to a single switch. So 802.3ad is >good only for aggregation, and not for high availability. Keep in mind that higher-end switches as well as stacked lower-end switches have a reasonable amount of internal redundancy so 802.3ad within one distinct components of one physical switch may be adequate for many purposes. Keep in mind that you'll still need multiple FreeBSD boxes to prevent them being a single point of failure. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpRg83tFxR9k.pgp Description: PGP signature
Re: [ATA] and re(4) stability issues
On 2008-Dec-10 10:55:35 +0100, Søren Schmidt <[EMAIL PROTECTED]> wrote: >And you will not use 64bit DMA even if the chipset supports it. >However I have not seen any chipsets supporting this fail, YMMV as >usual :) There's a reference in wikipedia pointing to http://www.mail-archive.com/[EMAIL PROTECTED]/msg06694.html that claims the AMD/ATI SB600 lies about supporting 64-bit DMA in AHCI mode. I have a SB600 but it doesn't have >4GB to test on. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp1ifE19lUGB.pgp Description: PGP signature
Re: Problems installing FreeBSD 7.0
On 2008-Dec-23 20:32:38 +0100, Jack Raats wrote: >> Can you try to paste exactly what was on the screen before the "freeze" >> for >> both 6.4 and 7.0? > >How can I do this if the systeem freezes??? Take a photo and put it up somewhere (http://imagebin.ca/ if nowhere else). If scroll lock still works, you can take pictures of earlier output (and if caps/scroll/num lock don't work, that is a useful piece of information). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgprYHKTZaO5T.pgp Description: PGP signature
Re: Problems installing FreeBSD 7.0
On 2008-Dec-24 17:29:05 +0100, Jack Raats wrote: >Main problem is: >ad0: FreeBSD check1 failed This is produced when the ATA subsystem is trying to read RAID metadata off the disk and just means it failed to find any. It's not an error. Can you post more context please. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpcLL7lAZGbI.pgp Description: PGP signature
Re: rdump stuck in sbwait state (RELENG_7)
On 2008-Dec-29 20:28:41 -0500, Terry Kennedy wrote: > I upgraded a box (Dell Poweredge 1550, dual PIII processors) from a kernel + >world of December 8th to one from today (December 29th) and I am experiencing >a new problem with rdump. ... > A tcpdump on both the sending and receiving systems shows no packets >between them from the rdump processes. However, I can rshell both ways >and get the expected output, so the link isn't down. This is probably the critical piece of information - the TCP connection has stopped transferring data for some reason and the rdump is blocked waiting to send. Unfortunately, you need the last packets that were exchanged in order to identify which end has the problem (and hopefully provide some pointers as to why). If possible, can you repeat the dump whilst you run a tcpdump on the rdump flow and then post the last dozen or so packets in each direction. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpL79vKz7BI4.pgp Description: PGP signature
Re: rdump stuck in sbwait state (RELENG_7)
On 2008-Dec-30 05:48:26 -0500, Terry Kennedy wrote: >> Unfortunately, you need the last packets that were exchanged in order >> to identify which end has the problem (and hopefully provide some >> pointers as to why). If possible, can you repeat the dump whilst you >> run a tcpdump on the rdump flow and then post the last dozen or so >> packets in each direction. > > That could be pretty unpleasant - this happens at a random point while >dumping 4GB or so. If I have to, I'll do it but I was hoping there was >a better way. Sorry, I can't think of any - by the time you see it hung, whatever went wrong has already happened. You might glean some insight from the TCP socket state (on the FreeBSD side, use 'netstat -A' to print the PCB address and gdb to dump the contents but I'm not sure how to get this data out of OpenVMS). The '-C' and '-W' options to tcpdump will help. > Shouldn't this get torn down by a keepalive at some point? It has been >sitting for 9 hours or so at this point... On FreeBSD, keepalives are off by default. You change change the default with sysctl net.inet.tcp.always_keepalive but I think that only affects new connections. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpEhfcVex9gC.pgp Description: PGP signature
Interval timers firing early
I have some code that uses setitimer() to generate one-shot timers of
~60s (the intent is to fire ~10msec before the minute boundary).
On my amd64 laptop running 7.0-stable from mid-March the SIGALRM
arrives at the expected time. On a system running a recent amd64
-current, the SIGALRM arrives about 10msec late (which I'm not too
fussed about).
On two i386 systems running 7.1-PRE (from mid-Oct) and a fresh 7.1-RC2
install, the SIGALRM arrives early - ~11msec for the 7.1-PRE system and
~5msec for the 7.1-RC2 system.
All systems are running HZ=1000. Two of the systems (the one running
7.1-PRE and the one running -current) are running BOINC. All systems
are otherwise unloaded. I've looked at the timer code and can't
quickly see anything that would explain this. Does anyone have any
ideas?
The relevant code looks like the following:
while (1) {
struct timeval now;
struct itimervalit;
int usecs;
if (gettimeofday(&now, NULL) < 0) {
syslog(LOG_ERR, "gettimeofday: %m");
exit(1);
}
/* Set timer for just before next minute */
it.it_interval.tv_sec = 0;
it.it_interval.tv_usec = 0;
usecs = 5999 - ((now.tv_sec % 60) * 100 + now.tv_usec);
if (usecs < 1) /* allow 10msec slop */
usecs += 6000;
it.it_value.tv_sec = usecs / 100;
it.it_value.tv_usec = usecs % 100;
if (setitimer(ITIMER_REAL, &it, NULL) < 0) {
syslog(LOG_ERR, "setitimer: %m");
exit(1);
}
printf("%d.%06ld %2d.%06ld %d\n", now.tv_sec, now.tv_usec,
it.it_value.tv_sec, it.it_value.tv_usec, usecs);
/* do stuff here which is interrupted by SIGALRM */
}
On the 7.1-PRE system, I get output like:
1230776939.991464 59.998536 59998536
1230776999.978991 0.011009 11009
1230776999.991996 59.998004 59998004
1230777059.979532 0.010468 10468
1230777059.991538 59.998462 59998462
1230777119.979058 0.010942 10942
1230777119.991065 59.998935 59998935
1230777179.978597 0.011403 11403
1230777179.991610 59.998390 59998390
1230777239.979139 0.010861 10861
1230777239.991142 59.998858 59998858
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpmDepR2DE3I.pgp
Description: PGP signature
Re: "vr0: rx packet lost"
On 2009-Jan-10 19:15:22 -0800, David Ehrmann wrote: >Wow. That really is a lot, but I might just wait for the final release, >though with this command, it might not be such a big deal: > >freebsd-update upgrade -r 7.1-RC1 FreeBSD 7.1-RELEASE has been available for nearly a week. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp3TpPLsRLGi.pgp Description: PGP signature
Re: interrupt storm
On 2009-Jan-14 22:57:46 -0500, Dan Langille wrote: >Opening the case, reading the m/b: > > K9A2 Platinum MSI Tangentially related: For any decent M/B, kenv(8) should tell you this without needing to open the box. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpv26XRlNxyx.pgp Description: PGP signature
Re: System borked: loader stack overflow.
On 2009-Jan-17 22:09:52 -0500, Andrew Lankford wrote: >After rebuilding world from 7-stable after cvsup, I can no longer boot. >The loader tries to load the kernel but instead locks up with a stack >overflow. Wish I could send more details, but I'll have to find another >way to boot up my system first. If you press any key during the first spinner, you should get a prompt similar to the following: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: You can then enter the name of the program you wish to run - eg /boot/loader.old (or directly load /boot/kernel/kernel) See the following for a more complete description: http://www.freebsd.org/cgi/man.cgi?query=boot&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html Alternatively, you could boot off a "live filesystem" CD. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp6UN5GMnCSa.pgp Description: PGP signature
Re: [Stable 7] CPIO breakage/
On 2010-Jun-15 17:22:50 -0700, Xin LI wrote: >On 2010/06/15 17:05, Sean Bruno wrote: >> A little more background. It looks like symlinks are getting stripped >> of their '/' which sucks. Ideas? ... >> e.g. /home/foo/bar -> /opt/baz/blob >> >> becomes >> >> home/foo/bar -> opt/baz/blob >> >> Yuck. > >This is a security measurement I think. Can someone please explain how stripping a leading '/' off the destination of a symlink enhances security? The destination is not being written to. >--absolute-filenames disables this behavior. This definitely reduces security and would seem to be far more dangerous than being able to create symlinks to absolute pathnames. -- Peter Jeremy pgpiAgVPvZVj0.pgp Description: PGP signature
Re: 8.x grudges
On 2010-Jul-07 14:22:22 -0400, "Mikhail T." wrote: >In no particular order: > > 1. > A picture, that one of the systems was displaying at boot (and > then used as a screen-saver), stopped showing properly. The > colors are right, but the picture is distorted beyond recognition. > The relevant part of loader.conf is: > > splash_pcx_load="YES" > vesa_load="YES" > bitmap_load="YES" > bitmap_name="/boot/187426-9-quokka-dreaming.pcx" It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. > 3. > Likewise, having "device ugen" breaks config(8) -- another > undocumented incompatibility. Can you please advise where it is documented that "device ugen" is valid in a FreeBSD-8 config file? > 5. > One of the upgraded systems would repeatedly hang at boot, until I > disabled the on-board firewire-device through the BIOS... It was > not a problem under 7.x, although I don't know, whether the device > actually worked. I haven't seen this on any of my systems. Can you please provide details of your motherboard, BIOS and the output from a verbose boot up to the hang. Is there a BIOS update available and have you tried installing it? > 6. > Despite the reported improvements in the USB area, my USB keyboard > /still/ does not work during boot. It during POST and then after > the booting is complete. But in single-user mode -- no... Had to > fish-out the PS2 keyboard... I have had similar problems on one of my USB-only desktops. In my case, moving the keyboard to a different USB port solved the problem. All I can suggest is to work your way through all the USB ports you have available and see if they all behavee the same. -- Peter Jeremy pgpHkZwBBtkAL.pgp Description: PGP signature
Re: 8.x grudges
On 2010-Jul-08 18:10:48 -0400, "Mikhail T." wrote: >08.07.2010 17:06, Peter Jeremy написав(ла): >> On 2010-Jul-07 14:22:22 -0400, "Mikhail T." >> wrote>>>1. A picture, that one of the systems was displaying at boot (and >>> then used as a screen-saver), stopped showing properly. The >>> colors are right, but the picture is distorted beyond recognition. >I don't want to post it publicly for copyright reasons. I can e-mail it >to you (or anyone else) directly, though. I doubt I'm personally in a position to debug this and don't personally use splash screens. Can you reproduce it using an image that you can re-distribute? >>>3. Likewise, having "device ugen" breaks config(8) -- another >>> undocumented incompatibility. >It was a valid device for FreeBSD-7. The UPDATING-file enumerates a >number of things, that need to be changed, when updating to 8, but the >removal of "ugen" is not mentioned there. Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES but I agree that the ugen(4) man page is incorrect and a case could be made for having better details of USB2 in UPDATING. How would you like to write up patches and submit a PR? >>>5. One of the upgraded systems would repeatedly hang at boot, until I >>> disabled the on-board firewire-device through the BIOS... It was >No BIOS updates :-( I can e-mail boot's output to you directly (please, >confirm interest). It would be with the device disabled though, because >the boot never completes, if it is enabled. That's why I asked for the output up to the hang - which might show where the problem is. If you don't have a serial console, take a photo and put it up on the web. >>>6. Despite the reported improvements in the USB area, my USB keyboard >>> /still/ does not work during boot. It during POST and then after >> I have had similar problems on one of my USB-only desktops. In my >> case, moving the keyboard to a different USB port solved the problem. >> All I can suggest is to work your way through all the USB ports you >> have available and see if they all behavee the same. >> >I'll try that next time I reboot this system. Thanks, I'm not sure if you can actually move the keyboard and have it re-probe until the system is fully up. You might have to reset after you move the keyboard. BTW, in all writing you've done, you've never mentioned what FreeBSD version you are running beyond a vague "8.1 prerelease", what motherboard you have (despite my request for this) and only indirectly given the architecture (via the config file you posted). -- Peter Jeremy pgpvhRewGP7zw.pgp Description: PGP signature
Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
On 2010-Jul-11 11:25:12 -0700, Richard Lee wrote: >But when almost all of the memory is taken by disk cache (of non-zfs >file system), ZFS disks start threshing like mad and the write >throughput goes down in 1-digit MB/second. It can go a lot lower than that... Yes, this is a known problem. The underlying problem is a disconnect between the ZFS cache (ARC) and the VM cache used by everything else, preventing ZFS reclaiming RAM from the VM cache. For several months, I was running a regular cron job that was a slightly fancier version of the perl one-liner. I have been using the attached arc.patch1 based on a patch written by Artem Belevich (see http://pastebin.com/ZCkzkWcs ) for about a month. I have had reasonable success with it (and junked my cronjob) but have managed to wedge my system a couple of times whilst doing zfs send|recv. Whilst looking at that diff, I just noticed a nasty signed/unsigned bug that could bite in low memory conditions and have revised it to arc.patch2 (untested as yet). Independently, Martin Matuska committed r209227 that corrects a number of ARC bugs reported on OpenSolaris. Whilst this patch doesn't add checks on "inactive" or "cache", some quick checks suggest it also helps (though I need to do further checks). See http://people.freebsd.org/~mm/patches/zfs/head-12636.patch -- Peter Jeremy pgpqfU3ecAmS4.pgp Description: PGP signature
Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
On 2010-Jul-12 19:38:18 +1000, Peter Jeremy
wrote:
>I have been using the attached arc.patch1 based on a patch written by
>Artem Belevich (see http://pastebin.com/ZCkzkWcs )
>for about a month. I have had reasonable success with it (and junked
>my cronjob) but have managed to wedge my system a couple of times
>whilst doing zfs send|recv. Whilst looking at that diff, I just
>noticed a nasty signed/unsigned bug that could bite in low memory
>conditions and have revised it to arc.patch2 (untested as yet).
Let try actually attaching those patches... Sorry.
--
Peter Jeremy
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
===
RCS file: /usr/ncvs/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c,v
retrieving revision 1.22.2.6
diff -u -r1.22.2.6 arc.c
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c24 May 2010
20:09:40 - 1.22.2.6
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c12 Jun 2010
21:04:13 -
@@ -183,10 +183,15 @@
int zfs_arc_shrink_shift = 0;
int zfs_arc_p_min_shift = 0;
+uint64_t zfs_arc_bp_active;
+uint64_t zfs_arc_bp_inactive;
+
TUNABLE_QUAD("vfs.zfs.arc_max", &zfs_arc_max);
TUNABLE_QUAD("vfs.zfs.arc_min", &zfs_arc_min);
TUNABLE_QUAD("vfs.zfs.arc_meta_limit", &zfs_arc_meta_limit);
TUNABLE_INT("vfs.zfs.mdcomp_disable", &zfs_mdcomp_disable);
+TUNABLE_QUAD("vfs.zfs.arc_bp_active", &zfs_arc_bp_active);
+TUNABLE_QUAD("vfs.zfs.arc_bp_inactive", &zfs_arc_bp_inactive);
SYSCTL_DECL(_vfs_zfs);
SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_max, CTLFLAG_RDTUN, &zfs_arc_max, 0,
"Maximum ARC size");
@@ -195,6 +200,11 @@
SYSCTL_INT(_vfs_zfs, OID_AUTO, mdcomp_disable, CTLFLAG_RDTUN,
&zfs_mdcomp_disable, 0, "Disable metadata compression");
+SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_bp_active, CTLFLAG_RW|CTLFLAG_TUN,
&zfs_arc_bp_active, 0,
+"Start ARC backpressure if active memory is below this limit");
+SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_bp_inactive, CTLFLAG_RW|CTLFLAG_TUN,
&zfs_arc_bp_inactive, 0,
+"Start ARC backpressure if inactive memory is below this limit");
+
/*
* Note that buffers can be in one of 6 states:
* ARC_anon- anonymous (discussed below)
@@ -2103,7 +2113,6 @@
}
static int needfree = 0;
-
static int
arc_reclaim_needed(void)
{
@@ -2112,20 +2121,58 @@
#endif
#ifdef _KERNEL
- if (needfree)
- return (1);
+ /* We've grown too much, */
if (arc_size > arc_c_max)
return (1);
+
+ /* Pagedaemon is stuck, let's free something right away */
+ if (vm_pageout_pages_needed)
+ return 1;
+
+ /* Check if inactive list have grown too much */
+ if ( zfs_arc_bp_inactive
+&& (ptoa((uintmax_t)cnt.v_inactive_count) > zfs_arc_bp_inactive)) {
+ /* tell pager to reap 1/2th of inactive queue*/
+ atomic_add_int(&vm_pageout_deficit, cnt.v_inactive_count/2);
+ pagedaemon_wakeup();
+ return needfree;
+ }
+
+ /* Same for active list... */
+ if ( zfs_arc_bp_active
+&& (ptoa((uintmax_t)cnt.v_active_count) > zfs_arc_bp_active)) {
+ atomic_add_int(&vm_pageout_deficit, cnt.v_active_count/2);
+ pagedaemon_wakeup();
+ return needfree;
+ }
+
+
+ /* Old style behavior -- ARC gives up memory whenever page daemon
asks.. */
+ if (needfree)
+ return 1;
+
+ /*
+ We got here either because active/inactive lists are
+ getting short or because we've been called during voluntary
+ ARC size checks. Kind of gray area...
+ */
+
+ /* If we didn't reach our minimum yet, don't rush to give memory up..*/
if (arc_size <= arc_c_min)
return (0);
+ /* If we're really short on memory now, give it up. */
+ if (vm_page_count_min()) {
+ return (1);
+ }
+
/*
-* If pages are needed or we're within 2048 pages
-* of needing to page need to reclaim
+* If we're within 2048 pages of pagedaemon start, reclaim...
*/
- if (vm_pages_needed || (vm_paging_target() > -2048))
+ if (vm_pages_needed && (vm_paging_target() > -2048))
return (1);
+
#if 0
/*
* take 'desfree' extra pages, so we reclaim sooner, rather than later
@@ -2169,8 +2216,6 @@
return (1);
#endif
#else
- if (kmem_used() > (kmem_size() * 3) / 4)
- return (1);
#endif
#else
@@ -2279,7 +2324,7 @@
if (arc_eviction_list != NULL)
arc_do_user_evict
Re: 8.x grudges
On 2010-Jul-29 16:50:24 +0200, Oliver Fromme wrote: >Install ports/sysutils/dmidecode and type (as root): > ># dmidecode -t system -t baseboard > >It will tell you the vendor and product name, among >other things. kenv(1) (in the base) should as well. -- Peter Jeremy pgpbf8VH6Q3UB.pgp Description: PGP signature
Re: zfs destroy snapshot doesn't free space
On 2010-Aug-13 16:51:24 +0200, Andreas Mayer wrote: >If I take a snapshot again, this snapshot also references 623G. > >What can I do to reclaim this space? I have to do this before I can >set a quota (I have set quotas for all other file systems now :) ). Does a reboot resolve the problem? -- Peter Jeremy pgpbzS5ldbnfc.pgp Description: PGP signature
Re: 8.1R ZFS almost locking up system
On 2010-Aug-21 23:04:35 +0100, Tim Bishop wrote: >I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems >that ZFS gets in to an almost unresponsive state. Last time it did it >(two weeks ago) I couldn't even log in, although the system was up, this >time I could manage a reboot but couldn't stop any applications (they >were likely hanging on I/O). Unless you have a ZFS-only system, it's possible you are running out of free memory (see the "free" entry in top(1) or 'systat -v') - in which case r211581 (and r211599 which fixes a mismerge) should help. Your very high kstat.zfs.misc.arcstats.memory_throttle_count suggests this is your problem. I have a more extensive patch in http://www.freebsd.org/cgi/query-pr.cgi?pr=146410 -- Peter Jeremy pgpVn6Q2Ml3YY.pgp Description: PGP signature
Re: Freebsd 8.1 + xorg + radeonhd hang
On 2010-Sep-15 22:29:46 +0200, Eivind E wrote: >That has crossed my mind aswell, the only thing which makes me doubt >it is that after updating X number of months ago (probably about a >year and a half), it started to work with no problems whatsoever. >Now, after upgrading again, it has stopped working. Can I suggest adding a "Virtual 1280 1024" (or similar) to the 'SubSection "Display"' of 'Section "Screen"'. I ran into some wierd problems with multiple screens and found that the virtual size isn't correctly initialised unless it's explicitly specified. Also, specifying EXA acceleration is fairly mandatory: The default XAA acceleration is broken. -- Peter Jeremy pgpuqhaZGDnMJ.pgp Description: PGP signature
Re: SuperMicro i7 (UP) - very slow performance
On 2010-Sep-18 08:32:32 -0500, Bryce Edwards wrote: >I have a Supermicro with the C7X58 motherboard and an i7 930 cpu, and >it is nowhere near the performance it should be. A buildworld just >took 22.5 hours! That does sound a bit poor. I presume the system was basically unloaded during the buildworld. Can we see the output of: - vmstat -i - zpool status -v - df -k - mount -v - md5 -t [this will help determine if the problem is lack of CPU] - sysctl vm >I have tested the two system drives independently (currently a zfs >mirror), so it is not likely to be an hdd issue. How did you test them and what were the results? Do you know what revision your /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c is? (Or when/how did you last upgrade your source tree). -- Peter Jeremy pgpAFG55c53N0.pgp Description: PGP signature
Re: SuperMicro i7 (UP) - very slow performance
On 2010-Sep-21 20:02:09 -0700, Bryce wrote: >On Sep 20, 6:17 am, peterjer...@acm.org (Peter Jeremy) wrote: >> On 2010-Sep-18 08:32:32 -0500, Bryce Edwards wrote: >> >> >I have a Supermicro with the C7X58 motherboard and an i7 930 cpu, and >> >it is nowhere near the performance it should be. A buildworld just >> >took 22.5 hours! >> - md5 -t [this will help determine if the problem is lack of CPU] > >MD5 time trial. Digesting 10 1-byte blocks ... done >Digest = 766a2bb5d24bddae466c572bcabca3ee >Time = 5.421381 seconds >Speed = 184454848.00 bytes/second I think something is badly wrong here. That's less than 1/2 the speed of my Athlon 4850e (2.5GHz) and only 60% more than my Atom N270. None of the other figures you posted look anomolous. Are you sure the CPU is actually running at full speed and you haven't done something like disable the caches in BIOS? -- Peter Jeremy pgpHTZ8TL2ogA.pgp Description: PGP signature
Re: SuperMicro i7 (UP) - very slow performance
On 2010-Sep-22 01:43:10 -0700, Jeremy Chadwick wrote: >To the OP: ... 4) Check the CPU core temperature (via coretemp(4) or similar) and make sure the heatsink is correctly attached. -- Peter Jeremy pgp049hzGw1N5.pgp Description: PGP signature
Re: safe mode
On 2010-Oct-29 15:51:40 -0400, Stephen Clark wrote: >On 10/29/2010 01:40 PM, Jeremy Chadwick wrote: >> On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote: >>> I am supporting over 700 units in the field that are acting as >>> firewall/router/vpn devices, >>> that are running 6.3. It would not be feasible to upgrade them to a >>> new version of FreeBSD >>> remotely. Also if I was going to move to a later release of FreeBSD >>> for the new hardware >>> it would involve months of new testing and validation of the new >>> release, where putting a patched >>> 6.3 kernel is relatively straightforward. >>> >> I'm a little confused. Did you deploy over 700 field units running >> FreeBSD 6.3 without testing it first on this particular piece of >> hardware/setup? Or did you recently upgrade from FreeBSD X.Y to 6.3 and >> found that things broke? What I'm trying to find out is whether or not >> these systems ever worked for you, and if so, at what point did they >> stop working. >Sorry for the confusion. We have a mix of hardware in the field. The current >hardware platform we are shipping is going EOL from the vendor. I am testing >the vendors next generation of hardware. As with hardware, software goes EOL (or at least EOS) as well and the FreeBSD 6.x branch will not be supported by the FreeBSD project beyond the end of this month. Whilst you are free to continue using older code, you will not be able to rely on the FreeBSD project providing particularly security alerts and fixes. I would suggest that your testing to date shows that you will not be able to deploy your new hardware running the same software image as you currently deploy. Your new hardware would therefore seem to provide an ideal opportunity for you to also move to a newer OS (and still supported) version of FreeBSD. You could then choose whether to maintain the older software on the existing deployed base or validate the newer software on the older hardware and older units as required. -- Peter Jeremy pgpxRiAnUDqbI.pgp Description: PGP signature
Re: ZFS backups: retrieving a few files?
On 2010-Nov-23 23:45:43 +1100, Andrew Reilly wrote: >zfs send -vR tank/h...@0 | zfs receive -d /backup/snapshots > >in order to experiment with this strategy. > >One would then become alarmed when one discovered that the >receive mechanism also invoked the mountpoint= parameter of the >source filesystem, and the zfs propensity for just doing stuff, >and boom: you have a read-only version of your home directory >mounted *on top of* your actual home directory... Been there, done that. The undocumented '-u' option to receive will prevent the receive side performing mounts. The poorly documented '-R' option on import allows you to specify an alternative root mountpoint. Once you have done the initial transfer, you can also set 'canmount=noauto' on each fileset (it isn't inherited) to prevent ZFS automounting them on import. BTW, the entire export is performed at the current compression level - recompressing existing data. -- Peter Jeremy pgpJ45k6nVaUR.pgp Description: PGP signature
Re: ZFS backups: retrieving a few files?
On 2010-Nov-24 11:07:23 +0100, Alexander Leidinger wrote: >Quoting Peter Jeremy (from Wed, 24 Nov 2010 >06:32:07 +1100): > >> BTW, the entire export is performed at the current compression level - >> recompressing existing data. > >Are you sure the compression is done on the sending side, and not at >the receiving side? I would expect the later (as I can specify a >different compression level on an existing destination, if I remember >correctly). Sorry, that was poorly worded. The actual send stream is not compressed but the entire filesystem stream will be re-compressed on the receive side as specified by the "compression" parameter on the sending filesystem. -- Peter Jeremy pgpiHfu1rdR5j.pgp Description: PGP signature
idprio processes slowing down system
Since scheduler issues have been popular lately, I thought I'd investigate a ULE issue I've been aware of for a while... I normally have some boinc (ports/astro/boinc) applications running and I'd noticed that my nightly builds appear to end much sooner when there's no boinc work units (this has been common for setiathome). This morning, I timed 4 "make -j3 KERNCONF=GENERIC buildkernel" of 8-stable with the following results: boinc running: 1167.839u 287.055s 18:45.69 129.2%6140+1975k 1+0io 114pf+0w 1166.431u 288.265s 18:00.16 134.6%6139+1975k 0+0io 106pf+0w 1168.490u 287.599s 17:52.24 135.7%6137+1975k 0+0io 106pf+0w 1165.747u 287.641s 17:10.38 141.0%6138+1975k 0+0io 106pf+0w boinc stopped: 1165.052u 291.492s 15:54.72 152.5%6125+1972k 0+0io 106pf+0w 1166.101u 290.305s 15:42.54 154.5%6132+1973k 0+0io 106pf+0w 1165.248u 290.335s 15:35.93 155.5%6132+1974k 0+0io 106pf+0w 1166.100u 289.749s 15:26.35 157.1%6137+1974k 0+0io 106pf+0w Since the the results were all monotonically reducing in wallclock time, I decided to do a further 4 buildkernels with boinc running: 1168.242u 284.693s 17:33.05 137.9%6140+1975k 0+0io 106pf+0w 1167.191u 285.332s 17:19.27 139.7%6140+1976k 0+0io 106pf+0w 1224.813u 291.963s 20:14.90 124.8%6121+1966k 0+0io 106pf+0w 1213.132u 294.564s 19:48.98 126.8%6116+1967k 0+0io 106pf+0w ministat(1) reports there is no statistical difference in the user or system time: User time: x boinc_running + boinc_stopped +--+ | +* x | | +*xxx x| |||A_M___A___| | +--+ N Min MaxMedian AvgStddev x 8 1165.747 1224.813 1168.242 1180.2356 24.12896 + 4 1165.052 1166.1011166.1 1165.62530.55457454 No difference proven at 95.0% confidence System time: x boinc_running + boinc_stopped +--+ | + | |x xx xx x + ++ x x| | |_MA|___MA_|__|| +--+ N Min MaxMedian AvgStddev x 8 284.693 294.564 287.641 288.389 3.3142183 + 4 289.749 291.492 290.335 290.470250.73252412 No difference proven at 95.0% confidence But there is a significant difference in the wallclock time: x boinc_running + boinc_stopped +--+ |+ + + + x x xx x x x x| ||__AM_| |___MA___| | +--+ N Min MaxMedian AvgStddev x 8 1030.381214.9 1080.16 1100.5838 69.364795 + 4926.35954.72942.54 939.885 11.915879 Difference at 95.0% confidence -160.699 +/- 79.6798 -14.6012% +/- 7.23977% (Student's t, pooled s = 58.4006) Since all the boinc processes are running at i31, why are they impacting a buildkernel that runs with 0 nicety? System information: AMD Athlon(tm) Dual Core Processor 4850e (2511.45-MHz K8-class CPU) running FreeBSD/amd64 from just before 8.1-RELEASE with WITNESS and WITNESS_SKIPSPIN, 8GB RAM, src and obj are both on ZFS. -- Peter Jeremy pgpTYgNUsxZxp.pgp Description: PGP signature
Re: idprio processes slowing down system
On 2010-Nov-28 02:24:21 -0600, Adam Vande More wrote: >On Sun, Nov 28, 2010 at 1:26 AM, Peter Jeremy wrote: >> Since all the boinc processes are running at i31, why are they impacting >> a buildkernel that runs with 0 nicety? > >With the setup you presented you're going to have a lot of context switches >as the buildworld is going to give plenty of oppurtunities for boinc >processes to get some time. Agreed. > When it does switch out, the CPU cache is >invalidated, then invalidated again when the buildworld preempts back. Not quite. The amd64 uses physically addressed caches (see [1] 7.6.1) so there's no need to flush the caches on a context switch. (Though the TLB _will_ need to be flushed since it does virtual-to-physical mapping (see [1] 5.5)). OTOH, whilst the boinc code is running, it will occupy space in the caches, thus reducing the effective cache size and presumably reducing the effective cache hit rate. > This is what makes it slow. Unfortunately, I don't think this explains the difference. My system doesn't have hyperthreading so any memory stalls will block the affected core and the stall time will be added to the currently running process. My timing figures show that the user and system time is unaffected by boinc - which is inconsistent with the slowdown being due to the impact on boinc on caching. I've done some further investigations following a suggestion from a friend. In particular, an idprio process should only be occupying idle time so the time used by boinc and the system idle task whilst boinc is running should be the same as the system idle time whilst boinc is not running. Re-running the tests and additionally monitoring process times gives me the following idle time stats: x /tmp/boinc_running + /tmp/boinc_stopped ++ | + ++ + xx x x| ||__A_M___| |__AM| | ++ N Min MaxMedian AvgStddev x 4 493.3507.78501.69 499.765 6.3722759 + 4332.35392.08361.84 356.885 26.514364 Difference at 95.0% confidence -142.88 +/- 33.364 -28.5894% +/- 6.67595% (Student's t, pooled s = 19.2823) The numbers represent seconds of CPU time charged to [idle] (+) or [idle] and all boinc processes (x). This shows that when boinc is running, it is using time that would not otherwise be idle - which isn't what idprio processes should be doing. My suspicion is that idprio processes are not being preempted immediately a higher priority process becomes ready but are being allowed to continue to run for a short period (possibly until their current timeslice expires). Unfortunately, I haven't yet worked out how to prove or disprove this. I was hoping that someone more familiar with the scheduler behaviour would comment. [1] "AMD64 Architecture Programmer's Manual Volume 2: System Programming" http://support.amd.com/us/Processor_TechDocs/24593.pdf -- Peter Jeremy pgp9YwrxEtbQK.pgp Description: PGP signature
Re: 8.1 livelock/hangup: possible actions
On 2010-Dec-11 18:14:28 +0500, "Eugene M. Zheganin" wrote: >I'm having problems with 8.1-REL/zfs/amd64. It's a IMB x3250 m2 system, >1Gb RAM, dualcore intel e3110, two bge(4) and LSI1064e disk controller. 1GB RAM is really light on for ZFS and there are some known ARC issues in 8.1 that can lead to free memory starvation. The most obvious indicator of this issue is that "free" memory reported by "top" OR "systat -v" drops _very_ low although there is plenty of "cache" and "inactive" memory. If you can't update to 8-stable, try changing arc_memory_throttle() in /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c to have uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count + cnt.v_cache_count); instead of uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count); at the top of the function. This fixes the worst bug but there are lots of other fixes if you upgrade. -- Peter Jeremy pgpMi5QjNUH8u.pgp Description: PGP signature
Re: root mount error
On 2010-Dec-28 23:08:44 +0300, Michael BlackHeart wrote: >I'm jsut trying to say than recent changes in kernel or kernel-modules >broke up my HDD support and I'd like to notice developres to check >where the problem is. It doesn't work that way. The developers don't have a problem or it would have been fixed. You are going to need to provide more details and do some investigations yourself to help identify the problem. >Loader on it's own stage easily detects HDD and root partition so I >can just select old kernel and boot up, but I'm not shure how he gain >access to HDD to mfke any conclusion, probably through BIOS interrupts >but it's out of piont. Yes. Until the kernel starts, all I/O is via BIOS. >And for my pity I don't know how to dump demsg without having any >serial connection or usable disk drive, maybe to flash drive, but I >don't know how. And anyway there's no real kernel painc, it just asks >for root mountpoint. Best suggestion I can offer is to take photographs of the boot messages (you can use scroll-lock to let you scroll back) and post them somewhere. >If you need any aditional info I'll give it all, just ask. What is the SVN revision of a kernel that works? What is the SVN revision of a kernel that fails? Can you please post a verbose dmesg of a successful boot. Can you please post a dmesg of an unsuccessful boot (see above). -- Peter Jeremy pgpHUhVzb3Hvu.pgp Description: PGP signature
Re: slow ZFS on FreeBSD 8.1
On 2010-Dec-30 07:20:57 -0500, Dan Langille wrote: >The reason I've not installed ZFS on root is because of the added >complications. I run the OS on ufs (with gmirror) and my data is on >ZFS. We must be hanging out with different groups. Most of the people >I know don't have ZFS on root. My primary system at home is setup this way - primarily because at the time I built it (Nov 2008), I felt ZFS was a bit immature and wanted to have src and obj on UFS so I could do a rebuild if I lost access to ZFS for some reason. My experience has been that the UFS root has caused me far more headaches than the ZFS parts. I've since done some reconfiguration and plan to switch to ZFS root soon. Based on my experiences at home, I converted my desktop at work to pure ZFS. The only issues I've run into have been programs that extensively use mmap(2) - which is a known issue with ZFS. -- Peter Jeremy pgp9CvWOJe1I9.pgp Description: PGP signature
Re: slow ZFS on FreeBSD 8.1
On 2010-Dec-30 02:31:30 -0500, Adam Stylinski wrote: >I can tell you what the problem is right now, actually. ZFS performs >very poorly on low performance CPUs (i.e. your Atom N330). I would disagree. In this case, the op's most serious problem is a bug in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:arc_memory_throttle() which is leading to ARC starvation. The direct effect of this is very poor ZFS I/O performance. It can be identified by very high "inactive" and possibly "cache" memory (as reported by 'systat -v' or top) as well as very high kstat.zfs.misc.arcstats.memory_throttle_count This bug was fixed in r210427 on -current, r211599 on 8.x and r211623 on 7.x. > Try the >same system with a different CPU and you'll get a different result. Not until the above bug is fixed. That said, ZFS is far more CPU intensive than UFS and a more powerful CPU may help - especially if you want gzip compression and/or sha256 checksumming. -- Peter Jeremy pgpRE0BXxVZbL.pgp Description: PGP signature
Re: slow ZFS on FreeBSD 8.1
On 2010-Dec-31 15:47:47 -0800, Jeremy Chadwick wrote: >Is your ZFS root filesystem associated with a pool that's mirrored or >using raidzX? Currently, mirrored. I'm considering raidz1 at home. Note that my work system is a single pool, whereas I'll use a separate pool for root at home. > What about mismatched /boot content (ZFS vs. UFS)? Can you give me an example of what you mean here. > What about booting into single-user mode? I haven't run into any problems here, though I agree that starting ZFS in single-user mode is a lot messier than starting UFS. >error/mistake). Is it worth the risk? Most administrators don't have >the tolerance for stuff like that in the middle of a system upgrade or >what not; they should be able to follow exactly what's in the handbook, >to a tee. I've been using FreeBSD for long enough that I'm confident to upgrade or similar without blindly following a process. But I agree that FreeBSD should be usable without needing to be a guru. >There's a link to www.dan.me.uk at the bottom of the above Wiki page >that outlines "the madness" that's required to configure the setup, all >of which has to be done by hand. I don't know many administrators who >are going to tolerate this when deploying numerous machines, especially >when compounded by the complexities mentioned above. Root on ZFS is still very bespoke. I agree there's no way you could roll it out across lots of machines at present but I'm happy to hand- craft installs on a few machines. Hopefully, son-of-sysinstall will support ZFS installs (one prerequisite is someone being willing to do the work). >The mmap(2) and sendfile(2) complexities will bite an junior or >mid-level SA in the butt too -- they won't know why software starts >failing or behaving oddly (FreeBSD ftpd is a good example). It just so >happens that Apache, out-of-the-box, comes with mmap and sendfile use >disabled. mmap(2) is a design problem with ZFS - it's present on Solaris as well. IMHO, it's the biggest flaw in ZFS. The sendfile(2) issues haven't bitten me so I haven't studied them as much but I'm aware that some fixes were committed recently. Oh and one root-on-ZFS gotcha that I missed is the lack of gzip support. I spent about ½day tracking that down - not helped by the lack of any documentation or a useful error message (though there is a comment in the code when you eventually track it down). -- Peter Jeremy pgpObQwMbJjKU.pgp Description: PGP signature
Specifying root mount options on diskless boot.
[I'm not sure if -stable is the best list for this but anyway...] I'm trying to convert an old laptop running FreeBSD 8.0 into a diskless client (since its internal HDD is growing bad spots faster than I can repair them). I have it pxebooting nicely and running with an NFS root but it then reports locking problems: devd, syslogd, moused (and maybe others) lock their PID file to protect against multiple instances. Unfortunately, these daemons all start before statd/lockd and so the locking fails and reports "operation not supported". It's not practical to reorder the startup sequence to make lockd start early enough (I've tried). Since the filesystem is reserved for this client, there's no real need to forward lock requests across the wire and so specifying "nolockd" would be another solution. Looking through sys/nfsclient/bootp_subr.c, DHCP option 130 should allow NFS mount options to be specified (though it's not clear that the relevant code path is actually followed because I don't see the associated printf()s anywhere on the console. After getting isc-dhcpd to forward this option (made more difficult because its documentation is incorrect), it still doesn't work. Understanding all this isn't helped by kenv(8) reporting three different sets of root filesystem options: boot.nfsroot.path="/tank/m3" boot.nfsroot.server="192.168.123.200" dhcp.option-130="nolockd" dhcp.root-path="192.168.123.200:/tank/m3" vfs.root.mountfrom="nfs:server:/tank/m3" vfs.root.mountfrom.options="rw,tcp,nolockd" And the console also reports conflicting root definitions: Trying to mount root from nfs:server:/tank/m3 NFS ROOT: 192.168.123.200:/tank/m3 Working through all these: boot.nfsroot.* appears to be initialised by sys/boot/i386/libi386/pxe.c but, whilst nfsclient/nfs_diskless.c can parse boot.nfsroot.options, there's no code to initialise that kenv name in pxe.c dhcp.* appears to be initialised by lib/libstand/bootp.c - which does include code to populate boot.nfsroot.options (using vendor specific DHCP option 20) but this code is not compiled in. Further studying of bootp.c shows that it's possible to initialise arbitrary kenv's using DHCP options 246-254 - but the DHCPDISCOVER packets do not request these options so they don't work without special DHCP server configuration (to forward options that aren't requested). vfs.root.* is parsed out of /etc/fstab but, other than being reported in the console message above, it doesn't appear to be used in this environment (it looks like the root entry can be commented out of /etc/fstab without problem). My final solution was to specify 'boot.nfsroot.options="nolockd"' in loader.conf - and this seems to actually work. It seems rather unfortunate that FreeBSD has code to allow NFS root mount options to be specified via DHCP (admittedly in several incompatible ways) but none actually work. A quick look at -current suggests that the situation there remains equally broken. Has anyone else tried to use any of this? And would anyone be interested in trying to make it actually work? -- Peter Jeremy pgpVVITD1dFyb.pgp Description: PGP signature
Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks
On 2010-Dec-30 12:40:00 +0100, Damien Fleuriot wrote: >What are the steps for properly removing my drives from the zraid1 pool >and inserting them in the zraid2 pool ? I've documented my experiences in migrating from a 3-way RAIDZ1 to a 6-way RAIDZ2 at http://bugs.au.freebsd.org/dokuwiki/doku.php/zfsraid Note that, even for a home system, backups are worthwhile. In my case, I backup onto a 2TB disk in an eSATA enclosure. That's currently (just) adequate but I'll soon need to identify data that I can leave off that backup. -- Peter Jeremy pgpOSt5NCO7Do.pgp Description: PGP signature
Re: classes and kernel_cookie was Re: Specifying root mount options on diskless boot.
On 2011-Jan-09 10:32:48 -0500, Daniel Feenberg wrote:
>Daniel Braniss writes...
>> I have it pxebooting nicely and running with an NFS root
>> but it then reports locking problems: devd, syslogd, moused (and maybe
Actually, that was me, not Daniel.
>Are you mounting /var via nfs?
Yes. I'm using "diskless" in the traditional Sun workstation style -
the system itself is running with a normal filesystem which is all NFS
mounted from another (FreeBSD) server. I'm aware of the MFS-based
read-only approach but didn't want to use that approach.
>I note that the response to your message from "danny" offers the ability
>to pass arguments to the nfs mount command,
Actually, my original mail indicates that that I'm aware you can pass
options to the NFS mount command (passing nolockd will solve my
problem). My issue is that there are several incompatible approaches
and none of them work by default.
> but also seems to offer a fix
>for the fact that "classes" are not supported under PXE:
>
>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/90368
I wasn't previously aware of that PR but it is consistent with my
findings.
On 2011-Jan-10 10:52:34 +0200, Daniel Braniss wrote:
>I'm willing to try and add the missing pieces, but I need some better
>explanantion as to what they are, for example, I have no clue what the
>kernel_cookie is used for, nor what the ${class} is all about.
I'm also happy to patch the code but feel that both PXE and BOOTP should
be consistent and I'm not sure which is the correct approach.
>BTW, it would be kind if the line in the pxeboot(8):
> As PXE is still in its infancy ...
>can be changed :-)
Well, there are still some issues with PXE booting FreeBSD - eg as
discussed here. But, I agree, that comment can probably go.
--
Peter Jeremy
pgp1ovrNzYvjf.pgp
Description: PGP signature
Re: sed is broken under freebsd?
On 2011-Jan-12 02:32:52 +0100, Oliver Pinter wrote: >The freebsd versions of sed contained a bug/regression, when \n char >can i subsitue, gsed not affected with this bug: gsed contains non-standard extensions and you have been suckered into using them. Try using 'gsed --posix' and/or setting POSIXLY_CORRECT. This is part of the GNU/FSF "lockin" policy that encourages people to use their non-standard extensions to ensure that you don't have any choice other than to use their software. -- Peter Jeremy pgpd7zj0Dn2kG.pgp Description: PGP signature
Re: system crash during make installworld
On 2011-Feb-21 08:04:00 +, David J Brooks wrote: >As the subject suggests, my laptop crashed during make installworld. >The new kernel boots, but the ELF interpreter is not found and I >cannot get to a single user prompt. What is the least painful way to >proceed? My first suggestion would be to boot the previous kernel. If that doesn't help, try specifying /rescue/sh as the single-user shell. If neither of those work, please specify the exact error message you get and the point where you get it (if you don't have a serial console available, post a link to picture of the screen showing the issue). -- Peter Jeremy pgptX1VTtosbn.pgp Description: PGP signature
Re: Invitation to connect on LinkedIn
On 2009-Nov-18 10:13:17 -0600, David Kelly wrote: >On Wed, Nov 18, 2009 at 01:07:46AM -0800, Andrei Antoukh wrote: >> LinkedIn >> >> >> Andrei Antoukh requested to add you as a connection on LinkedIn: >> -- > >Why isn't LinkedIn in FreeBSD.org's spam blocker? I have raised this with postmaster@ and he is investigating how to block this spam. -- Peter Jeremy pgpnlACiig4DT.pgp Description: PGP signature
Re: 7.2 dies in zfs
On 2009-Nov-21 09:47:56 +0900, Randy Bush wrote: >imiho, zfs can not be called production ready if it crashes if you do >not stand on your left leg, put your right hand in the air, and burn >some eye of newt. FWIW, it's still very brittle on Solaris 10 and the Sun Support response to most issues is "restore from backup". The IMHO, the biggest issue with ZFS itself is lack of recovery tools prior to PSARC 2009/479 (in ZFS v21). On 2009-Nov-21 11:36:43 -0800, Jeremy Chadwick wrote: >RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. Not in my repository. I still have v13 in sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h in last night's RELENG_7, RELENG_8 and -current. >RELENG_7 and RELENG_8 both, more or less, behave the same way with >regards to ZFS. Both panic on kmem exhaustion. No one has answered my >question as far as what's needed to stabilise ZFS on either 7.x or 8.x. My understanding is that the problem is more that the FreeBSD VM system doesn't gracefully handle running low or out of memory. -- Peter Jeremy pgpK1zEro2kG1.pgp Description: PGP signature
Re: Non-responsive 8.0-RC1 (now 8.0-STABLE)
On 2009-Nov-30 19:13:30 +1100, Peter Jeremy wrote: >On 2009-Nov-29 08:56:55 +0100, Thomas Backman wrote: >> >>On Nov 28, 2009, at 10:22 PM, Peter Jeremy wrote: >> >>> My main server is running 8.0/amd64 from between RC1 and RC2 and I've >>> recently had a couple of long-duration hangs on it during which time >>> processes doing I/O will stop responding. ... >It actually "hung" again just after I sent the original mail. This >time I managed to get console access and could check the kernel state. >This showed that a number of processes were blocked on ZFS locks. >The most commonly reported state was 'tx->tx_quiesce_done_cv)'. I've upgraded to 8-STABLE from 30-Nov and the problem is still present, even after disabling the boinc processes. This seems to leave race conditions inside ZFS as the only option. Has anyone else seen anything like this? -- Peter Jeremy pgpTWa66KHyiZ.pgp Description: PGP signature
New LOR: allproc/zfs
Just found a new LOR on 8-STABLE/amd64 from 30-Nov. It's possible that it was associated with 'vmstat -m'. Reported as kern/142489 lock order reversal: 1st 0x807417c0 allproc (allproc) @ /usr/src/sys/vm/vm_meter.c:130 2nd 0xff002c263ba8 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x66f __lockmgr_args() at __lockmgr_args+0x475 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x52 _vn_lock() at _vn_lock+0x47 vrele() at vrele+0xc3 vm_object_deallocate() at vm_object_deallocate+0x1ad _vm_map_unlock() at _vm_map_unlock+0x70 vm_map_remove() at vm_map_remove+0x6f vmspace_free() at vmspace_free+0x56 vmtotal() at vmtotal+0x3d5 sysctl_root() at sysctl_root+0xa1 userland_sysctl() at userland_sysctl+0x158 __sysctl() at __sysctl+0xaa syscall() at syscall+0x1ac Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x800bc5a9c, rsp = 0x7fffdaf8, rbp = 0x7fffdb08 --- -- Peter Jeremy pgpLY23ALYtRM.pgp Description: PGP signature
Re: Multiple serial consoles via null modem cable
On 2010-Jan-12 08:08:16 -0800, Jeremy Chadwick wrote: [serial to TCP/IP adapters] >As far as present-day devices go, the ones I can recommend are the ... > >You can also consider looking for used hardware -- either Xyplex devices DECservers are good for this sort of thing as well. AFAIK we're still using them at work. I've also used the Digiboard Xem adapters quite successfully on both FreeBSD and Solaris. Unfortunately, they are a bit tempramental on FreeBSD: They can't share interrupts (you get interrupt storms if you attempt it), digi(4) is limited to 16 ports (no expansion boxes) and digi(4) hasn't been adapted to the new TTY subsystem and so won't work on FreeBSD 8. >There's two ports which can make interfacing/using these devices, or a >multiport serial card, much easier -- Conserver[3]. I work with the guy >who wrote it, so I'm biased. :-) I can also thoroughly recommend conserver-com - as well as handling local serial devices, it can talk to serial-over-TCP ports, handles logging, distributed master/client hosts and allowed multiple people to connect to a single serial port (though only one person has write access at a time). Note that it's embedded in the LOM processor on (eg) Sun v20Z. -- Peter Jeremy pgpQuOWSWr7aw.pgp Description: PGP signature
Re: Drive light on all the time on 8-STABLE.
On 2010-Jan-18 17:11:48 +1300, Jonathan Chen wrote: >On Mon, Jan 18, 2010 at 07:20:08AM +1300, Jonathan Chen wrote: >> On Sun, Jan 17, 2010 at 12:28:04PM +0200, Alexander Motin wrote: >> > Jonathan Chen wrote: >> > > On the weekend, I moved my 8-STABLE installation (csup'd late Dec 2009) >> > > onto a new drive, a Seagate ST31000528AS CC3; and while the transfer was >> > > successful, I've noticed that the drive light is solidly on all the time, >> > > even if it boots into single-user. ... >I've rebooted the box a few times, and have observed that the drive >LED flickers normally up until: > >> atapci0: port >> 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem >> 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 I have exactly the same behaviour on my Gigabyte GA-MA770-DS3 with 3 Samsung HD103UJ HDDs and a Pioneer DVR-215 DVD-RW. I'm running 8.0-STABLE/amd64 from the end of November. It looks like it might be a bug in the IXP600 SATA driver. -- Peter Jeremy pgpDcthDHgy03.pgp Description: PGP signature
New zfs/bufwait LOR
I had the following crop up recently in 8-STABLE/amd64 from end of November. It's been reported as kern/143184. lock order reversal: 1st 0xff002f7fb270 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:533 2nd 0xff80803a26e0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:311 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x66f __lockmgr_args() at __lockmgr_args+0x475 initpbuf() at initpbuf+0xb9 getpbuf() at getpbuf+0xdc swap_pager_getpages() at swap_pager_getpages+0x1aa vm_fault() at vm_fault+0x5f7 trap_pfault() at trap_pfault+0x128 trap() at trap+0x379 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8049497b, rsp = 0xff809a427830, rbp = 0xff809a4278b0 --- copyout() at copyout+0x3b dmu_read_uio() at dmu_read_uio+0x98 zfs_freebsd_read() at zfs_freebsd_read+0x56f VOP_READ_APV() at VOP_READ_APV+0x44 vn_read() at vn_read+0x149 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x55 syscall() at syscall+0x1ac Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x8008ce86c, rsp = 0x7ffeb718, rbp = 0x805b41d18 --- -- Peter Jeremy pgplTEgQ6sgMF.pgp Description: PGP signature
uma_zalloc_arg complaining about non-sleepable locks
I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am now getting regular (the following pair of messages about every minute) compaints as follows: kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kernel: _witness_debugger() at _witness_debugger+0x2c kernel: witness_warn() at witness_warn+0x2c2 kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d kernel: nfs_realign() at nfs_realign+0x5f kernel: fha_assign() at fha_assign+0x2d8 kernel: svc_run_internal() at svc_run_internal+0x1ee kernel: svc_thread_start() at svc_thread_start+0xb kernel: fork_exit() at fork_exit+0x112 kernel: fork_trampoline() at fork_trampoline+0xe kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffe6d8, rbp = 0x5 --- kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kernel: _witness_debugger() at _witness_debugger+0x2c kernel: witness_warn() at witness_warn+0x2c2 kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d kernel: nfs_realign() at nfs_realign+0x5f kernel: fha_assign() at fha_assign+0x2d8 kernel: svc_run_internal() at svc_run_internal+0x1ee kernel: svc_thread_start() at svc_thread_start+0xb kernel: fork_exit() at fork_exit+0x112 kernel: fork_trampoline() at fork_trampoline+0xe kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffe6d8, rbp = 0x5 --- It looks like NFS is missing some lock/unlock pairs. Has anyone else seen this? And does anyone have a fix? -- Peter Jeremy pgpG6eQRJNanL.pgp Description: PGP signature
Re: uma_zalloc_arg complaining about non-sleepable locks
On 2010-Jan-26 15:10:59 -0500, John Baldwin wrote: >On Tuesday 26 January 2010 1:37:56 pm Marius Strobl wrote: >> On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: >> > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: >> > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am >> > > now getting regular (the following pair of messages about every >> > > minute) compaints as follows: >> > > >> > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable >> > > locks held: >> > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 >> > > (0xff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 ... >> Could you please give the following patch a try? >> http://people.freebsd.org/~marius/fha_extract_info_realign2.diff That seems to have fixed it - I've booted the new kernel and generated some NFS activity and am not getting any messages. Also, vfs.nfs.realign_test is incrementing nicely though vfs.nfs.realign_count remains at zero. >Hmm, the old code was already using M_DONTWAIT, so now I don't see why you >were getting the witness warning. Actually, there were two nfs_realign() definitions in the kernel - one in nfsclient/nfs_krpc.c (which used M_DONTWAIT) and another in nfsserver/nfs_srvkrpc.c (which used M_WAIT). It was the server code that was being exercised here. -- Peter Jeremy pgpAkH2N4MLeY.pgp Description: PGP signature
Re: uma_zalloc_arg complaining about non-sleepable locks
Sorry for the delay, I was trying to avoid rebooting my server. I've setup a similar environment in VirtualBox to test it. On 2010-Jan-27 12:52:29 +0100, Marius Strobl wrote: >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to >be a NOP on architectures without strict alignment requirements >for performance reasons. That's generally fine but unfortunately >that way you don't actually exercise the code which caused the >problem before (unfortunately I still don't manage to hit the >unaligned case myself). >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count >counter should also increase then. I'm not sure what triggers the unaligned case either - I tried roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and that caused some unaligned accesses (but also completely wedged the VBox host). I also tried copying a pile of files off my NFS client (FreeBSD-8.x/i386) and that also triggered some unaligned accesses without any errors being reported. Currently, I have: vfs.nfs.realign_count: 12 vfs.nfs.realign_test: 188817 I'd say that your patch works. -- Peter Jeremy pgpo9qRNnpyHO.pgp Description: PGP signature
Kernel probe order issues
Whilst trying to boot a brand new FreeBSD 8-stable/amd64 kernel, I ran into an unfortunate nasty with the kernel probe order. This particular box has no PS/2 ports so I have a USB keyboard and have removed atkbd et al from my kernel config. Unfortunately, whilst trying to merge changes from 5 different sources, I also accidently deleted my HDD controller. Quite reasonably, the lack of disk controller made the kernel spit out an error message and "mountroot>" prompt. Unfortunately, this occurs after the kernel has switched from BIOS to its own drivers but _before_ ukbd(4) is probed so I didn't have any keyboard. (Some experimenting with a serial console confirmed that ukbd is probed after the root device). This strikes me as undesirable. Is there some way to bump up the probe/attach priority of console input devices to ensure that they exist before the kernel tries to read input? -- Peter Jeremy pgpije7UV1cSy.pgp Description: PGP signature
Re: Kernel probe order issues
On 2010-Feb-01 11:37:33 +0200, Andriy Gapon wrote: >> This strikes me as undesirable. Is there some way to bump up the >> probe/attach priority of console input devices to ensure that they >> exist before the kernel tries to read input? > >It seems to be a problem with either your keyboard or your USB controller. >USB keyboard can be discovered much earlier than mountroot if the hardware is >ready. No magical software priority bump can help here. I've tried a couple of different USB ports (controllers) with no change in behaviour. I'll try another keyboard if I can find one. It _does_ work as expected on 7.x so this is a regression. -- Peter Jeremy pgpniZsRcRtHw.pgp Description: PGP signature
Re: Kernel probe order issues
On 2010-Feb-02 08:39:34 +0200, Andriy Gapon wrote: >on 02/02/2010 08:36 Peter Jeremy said the following: >> On 2010-Feb-01 11:37:33 +0200, Andriy Gapon wrote: >>>> This strikes me as undesirable. Is there some way to bump up the >>>> probe/attach priority of console input devices to ensure that they >>>> exist before the kernel tries to read input? >>> It seems to be a problem with either your keyboard or your USB controller. >>> USB keyboard can be discovered much earlier than mountroot if the hardware >>> is >>> ready. No magical software priority bump can help here. >> >> I've tried a couple of different USB ports (controllers) with no >> change in behaviour. I'll try another keyboard if I can find one. It >> _does_ work as expected on 7.x so this is a regression. > >Unfortunately you keep being low on hardware details. Sorry. The box is a Dell GX620 (P4 with ICH7 chipset). The keyboard is a Dell SK-8115 connected directly to a motherboard port. I've also tried a Dell SK-8135 (which is the "multimedia" variant and has a builtin hub) which behaves the same. I've uploaded full details as follows: FreeBSD 7.x verbose dmesg: http://pastebin.ca/1776339 FreeBSD 8.x verbose dmesg: http://pastebin.ca/1776359 "pciconf -lv" (same in 7 & 8): http://pastebin.ca/1776363 The output from 'usbdevs -v' on FreeBSD 7 is: Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 addr 2: low speed, power 70 mA, config 1, Dell USB Keyboard(0x2003), Dell(0x413c), rev 2.00 Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered And the output from "usbconfig list" on FreeBSD 8 is: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen2.2: at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON The alternate keyboard shows up as: port 2 addr 2: full speed, power 100 mA, config 1, Dell USB Keyboard Hub(0x1003), Dell(0x413c), rev 2.00 port 1 addr 3: full speed, power 50 mA, config 1, Dell USB Keyboard(0x2010), Dell(0x413c), rev 2.00 port 2 addr 4: low speed, power 100 mA, config 1, product 0x3010(0x3010), vendor 0x413c(0x413c), rev 2.30 port 3 powered -- Peter Jeremy pgpBEzGRR2Wy6.pgp Description: PGP signature
Re: Inmutable bit in some binaries
On 2010-Feb-06 12:11:08 +0100, Pascal Stumpf wrote: >just another idea: You may want to take a look at integrity checking systems >as an alternative, i.e. tripwire. Note that mtree(8) supports the integrity checking functionality of tripwire and is in the base system. (It doesn't have all the bells and whistles of tripwire and so isn't suitable for all cases). If you do go for an integrity checking system, remember to ensure that everything that your integrity checking system relies on (ie executable, database, shared libraries) is immutable - as well as the shell/cron that runs it and however the results are reported. -- Peter Jeremy pgpNTKkUgGATK.pgp Description: PGP signature
Re: Kernel probe order issues
Hi Andriy, On 2010-Feb-05 00:40:24 +0200, Andriy Gapon wrote: >Unfortunately, I don't see any explanation for what you are experiencing. > >I came up with some things with which you can try to experiment: > >1. Boot with hw.pci.usb_early_takeover="0" in loader.conf. > >2. Comment out the following line in sys/dev/usb/controller/uhci_pci.c: >pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); hps@ suggested a ukbd patch as well. Unfortunately, something has come up and I won't be able to check either suggestion until late March. -- Peter Jeremy pgp54yCHzO6zK.pgp Description: PGP signature
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On 2010-Feb-10 20:33:46 +0200, Andriy Gapon wrote: >I've long thought that xorg server should be linked with libthr regardless of >HAL >option. Unfortunately, I never came up with patch, nor have anyone else. >Xorg server really uses pthreads when doing DRM and HAL brings in libthr >dependency only as an accident. Try Ports/139011 - this adds an option to enable GLX TLS - which appears to be the underlying problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=139011 -- Peter Jeremy pgpQUbC0jKHAF.pgp Description: PGP signature
Re: Hello and a small problem with 8.0-RELEASE (amd64)
On 2010-Feb-11 14:00:57 -0700, Sean McCullough wrote: > This machine runs FreeBSD 7.2 (amd64 version) without the > slightest problem; but when I attempt to load 8.0 onto the machine, I > can't even get sysinstall to put the kernel on to boot it. How are you doing this? Normally you would only use sysinstall to install a fresh system from CD/DVD. Note that (at least last time I looked) actually copying the kernel to disk is one of the last steps it does and isn't explicitly selected from the menus. > Attempting to > compile and install the 8.0 kernel from source code results in a kernel > which locks up at boot time after emitting a message stating "attempting > to mount volumes"; Is this the exact message or is it "Trying to mount root"...? Can you provide the exact boot messages? Either setup a serial console or use ScrollLock, scroll back, photograph each screen of boot messages, post them somewhere and mail a URL. > a reboot of this system results in a bootloader > prompt and an error message stating that no bootable kernel can be found. Can you provide details of your hardware setup? Motherboard, what the boot disk is (PATA/SATA) and what the physical disk address is (which controller/channel). -- Peter Jeremy pgpPemVrezk0a.pgp Description: PGP signature
Re: Kernel probe order issues
On 2010-Feb-05 00:40:24 +0200, Andriy Gapon wrote: >I came up with some things with which you can try to experiment: > >1. Boot with hw.pci.usb_early_takeover="0" in loader.conf. > >2. Comment out the following line in sys/dev/usb/controller/uhci_pci.c: >pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); Sorry for the delay in responding. Neither of these made any difference. I have also tried asking in FreeBSD-usb and hps@ suggested trying ukbd.c Rev 43 from p4 - which also didn't help. -- Peter Jeremy pgpWTVHac3Cua.pgp Description: PGP signature
Re: ZFS tuning [was: hardware for home use large storage]
On 2010-Feb-16 09:59:46 -0800, Jeremy Chadwick wrote:
>On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote:
>> maybe something like this tacked on the end of the script (excuse my
>> Perl, I'm a Python guy).
>>
>>
>> Loader Settings #
>> open(LOADER, '/boot/loader.conf');
>> print "\n/boot/loader.conf settings:\n";
>> while (){
>> chomp;
>> if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){
>> print "\t$_\n";
>> }
>> }
>>
>
>Major problems with the above code:
>
>1) Opens /boot/loader.conf for rw access; should be read-only
Wrong. It opens /boot/loader.conf read-only, as it should.
>2) Makes the assumption /boot/loader.conf exists
Accepted but it was offered as a proof-of-concept.
>3) Does not close the fd
This is hardly a "major problem" in a short once-through script.
>4) Excessively quotes variables for no justified reason
If you mean including the $_ inside "", this is a standard perl idiom.
>5) Makes some bad assumptions about the contents of the file (ex.
> comments with the word "zfs" in them would match)
Wrong. It only matches "zfs" as the first non-blank text on
a line - which means it can't be a comment.
So that's one real deficiency in a proof-of-concept script written by
someone who does not claim to be comfortable with perl.
>The code should really be something like what's below. This should
>be much more manageable as well (@tunables that is), although I always
>worry when using grep()...
Whilst we are picking nits, your script has the following issues:
- unnecessary trailing wildcard matches in the regexps
- "grep" misused as "map"
- "die" is probably not appropriate for embedding into another script
- No useful error message if /boot/loader.conf can't be opened.
- Doesn't correctly handle optional whitespace around "="
- No heading to explain what is being reported.
- Doesn't allow for "zfs" as a top-level identifier
Overall, Barry's script makes an excellent proof-of-concept - which is
what he was offering.
--
Peter Jeremy
pgpI6dXwSO06C.pgp
Description: PGP signature
Re: ntpd struggling to keep up - how to fix?
On 2010-Feb-17 20:03:22 +0100, Torfinn Ingolfsen wrote: >On Wed, 17 Feb 2010 19:49:27 +0100 >Torfinn Ingolfsen wrote: > >> Unfortunately, it isn't enough to keep the machine in sync all the time. >> But it is better than HPET so I'll keep it. Did you delete /etc/ntp.drift between timecounter changes? >This thread is interesting: >http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/01356.html > >Is there a way in FreeBSD to perform adjustmenst like adjtimex? There's ntptime(8) but it doesn't have a "self-calibrate mode". Based on the messages log you gave, and assuming the ntpd PLL is sane, your acpi-safe clock is about 2500ppm slow (the steps reflect about 2000ppm and the ntpd PLL should be compensating for a further 500ppm) - this is really bad, even for consumer-grade stuff. Are you running non-standard clock speeds or multipliers? If there's nothing obvious, I'd follow John Hay's suggesion and force set either your TSC or ACPI frequency in sysctl.conf (you can't override the HPET frequency). Take either the TSC or ACPI frequency reported by "sysctl machdep", reduce it by 2500ppm and set that in /etc/sysctl.conf. Assuming a "standard" (3.58MHz) ACPI, the latter would look like: machdep.acpi_timer_freq=3570596 kern.timecounter.hardware=ACPI-safe The stop ntpd, delete /var/db/ntp.drift and either reboot or manually set the above sysctl's and restart ntpd. [I think I've got the adjustment direction correct in the above, if I've stuffed up, you need to adjust in the other direction] -- Peter Jeremy pgpcm7bDQJdjP.pgp Description: PGP signature
Re: ntpd struggling to keep up - how to fix?
On 2010-Feb-19 00:38:44 +0100, Torfinn Ingolfsen wrote: >r...@kg-f2# sysctl machdep.acpi_timer_freq=3577045 >machdep.acpi_timer_freq: 3579545 -> 3577045 Looks reasonable. Let us know the results. I'd be interested in the output from "ntpdc -c loopi -c sysi". -- Peter Jeremy pgpJFAUKCAoRd.pgp Description: PGP signature
Re: ntpd struggling to keep up - how to fix?
On 2010-Feb-20 22:32:01 +0100, Torfinn Ingolfsen wrote: >On Sat, 20 Feb 2010 12:53:51 +1100 >Peter Jeremy wrote: > >> Looks reasonable. Let us know the results. I'd be interested in >> the output from "ntpdc -c loopi -c sysi". > >Ok, here we go (the server panic'ed again last night): >r...@kg-f2# uptime >10:28PM up 2:26, 3 users, load averages: 0.00, 0.00, 0.00 >r...@kg-f2# sysctl machdep.acpi_timer_freq >machdep.acpi_timer_freq: 3577045 >r...@kg-f2# tvlm >Feb 20 20:06:41 kg-f2 ntpd[942]: kernel time sync status change 2001 >Feb 20 20:21:49 kg-f2 ntpd[942]: time reset +1.118880 s >Feb 20 20:37:53 kg-f2 ntpd[942]: time reset +1.188538 s >Feb 20 20:53:03 kg-f2 ntpd[942]: time reset +1.121903 s >Feb 20 21:09:00 kg-f2 ntpd[942]: time reset +1.179924 s >Feb 20 21:24:57 kg-f2 ntpd[942]: time reset +1.178490 s >Feb 20 21:39:58 kg-f2 ntpd[942]: time reset +1.110647 s >Feb 20 21:55:53 kg-f2 ntpd[942]: time reset +1.177292 s >Feb 20 22:11:44 kg-f2 ntpd[942]: time reset +1.172358 s >Feb 20 22:26:48 kg-f2 ntpd[942]: time reset +1.114350 s That's definitely not good - though it's marginally better than before. I have checked on a local machine and the timecounter frequency definitely needs to be adjusted in the opposite direction to the ntpd drift. I think I see the problem: I suggested 3579545Hz - 2500ppm, which gives an ACPI frequency of 3570596Hz. There was some miscommunication and you have set an ACPI frequency of 3577045Hz which is 2500Hz (or 698ppm) lower. The drift reported by the time resets has gone from +1930ppm (14.5s in 2:05:17) to +1233ppm (8.4s in 2:20:06) - which is 697ppm - fairly close to the change you made. (The PLL is running at +500ppm so the actual clock offset is 500ppm more than the "time reset" reports suggest. Having re-checked my maths, using both your "time reset" results, can you please try: sysctl machdep.acpi_timer_freq=3570847 That should result in a drift of close to zero (well within NTP's lock range of +/- 300ppm). >frequency:500.000 ppm And this is definitely not good. >Not synced at all. Not good. :-/ >Perhaps I should give it more time? No. Once ntpd decides to continuously step, something is broken. I've done some double-checking and On 2010-Feb-20 22:55:21 +0100, Torfinn Ingolfsen wrote: >This output looks ... wrong ... somehow to my eyes: ... >Shouldn't ntpq and ntpdc be in agreement? I'm not sure which particular bits you are concerned about but ntpq reports delay/offset/jitter in msec whilst ntpdc reports them in sec. Note that I can't explain why the loopi offset is zero - ntpdc(8) states that this is the "last offset given to the loop filter by the packet processing code". For me it's non-zero but doesn't quite match the offset reported by 'ntpq -p'. -- Peter Jeremy pgpZax0MQojXe.pgp Description: PGP signature
