Re: less and vi fail on file whose name begins with +
from Glen Barber g...@freebsd.org: less(1) is expecting '+' to be followed by additional arguments. If you use 'less -- +DESC', for example, it should work fine. Same with vi(1). Yes, that works, as does less ./+DESC. Somehow I thought I had successfully done less +CONTENTS successfully before, but I must have preceded filename by path. Less and vi failing when used directly on filename beginning with + is also true for Linux, I checked on Slackware 13.0. Thanks to you and others for helpful responses. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL
on 13/07/2012 19:31 Sean Bruno said the following: Well this is new. I haven't a clue what Dell has done on this R620, but this popped up today after I did a boat load of BIOS updates and tried to install stable/9 from our yahoo tree. If anyone sees the obvious solution here, I'd love to figure it out. found- vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=2, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd50d, size 16, enabled pcib1: allocated prefetch range (0xd50d-0xd50d) for rid 10 of pci0:2:0:1 map[18]: type Prefetchable Memory, range 64, base 0xd50e, size 16, enabled pcib1: allocated prefetch range (0xd50e-0xd50e) for rid 18 of pci0:2:0:1 map[20]: type Prefetchable Memory, range 64, base 0xd50f, size 16, enabled pcib1: allocated prefetch range (0xd50f-0xd50f) for rid 20 of pci0:2:0:1 pcib1: matched entry for 2.0.INTB pcib1: slot 0 INTB hardwired to IRQ 36 bge0: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem 0xd50a-0xd50a,0xd50b-0xd50b,0xd50c-0xd50c irq 34 at device 0.0 on pci2 bge0: APE FW version: NCSI v1.0.80.0 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 bge0: using IRQ 264 for MSI bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: MII bus on bge0 brgphy0: BCM5720C 1000BASE-T media interface PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0036, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: 18:03:73:fd:9e:36 bge1: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem 0xd50d-0xd50d,0xd50e-0xd50e,0xd50f-0xd50f irq 36 at device 0.1 on pci2 bge1: APE FW version: NCSI v1.0.80.0 bge1: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 60 bge1: using IRQ 265 for MSI bge1: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge1: Disabling fastboot bge1: Disabling fastboot miibus1: MII bus on bge1 brgphy1: BCM5720C 1000BASE-T media interface PHY 2 on miibus1 brgphy1: OUI 0x001be9, model 0x0036, rev. 0 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: bpf attached bge1: Ethernet address: 18:03:73:fd:9e:37 pcib2: ACPI PCI-PCI bridge irq 53 at device 1.1 on pci0 pcib0: allocated type 3 (0xd880-0xd8ff) for rid 20 of pcib2 pcib0: allocated type 3 (0xd510-0xd51f) for rid 24 of pcib2 pcib2: domain0 pcib2: secondary bus 1 pcib2: subordinate bus 1 pcib2: memory decode 0xd880-0xd8ff pcib2: prefetched decode 0xd510-0xd51f pci1: ACPI PCI bus on pcib2 pci1: domain=0, physical bus=1 found- vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=1, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd51a, size 16, enabled pcib2: allocated prefetch range (0xd51a-0xd51a) for rid 10 of pci0:1:0:0 map[18]: type Prefetchable Memory, range 64, base 0xd51b, size 16, enabled pcib2: allocated prefetch range (0xd51b-0xd51b) for rid 18 of pci0:1:0:0 map[20]: type Prefetchable Memory, range 64, base 0xd51c, size 16, enabled pcib2: allocated prefetch range (0xd51c-0xd51c) for rid 20 of pci0:1:0:0 pcib2: matched entry for 1.0.INTA pcib2: slot 0 INTA hardwired to IRQ 35 found- vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=1, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd51d, size 16, enabled pcib2: allocated prefetch range (0xd51d-0xd51d) for rid 10 of
8.2 -8.3 regression on disk writes
Hello, using 8.2 the machine runs fine, using 8.3 or higher, not so much. In laymans terms, if I do too many writes/time just once, the machine can't do any disk access for a couple of hours. As in: What's already running stays running, no crashes or anything, but as soon as I need to read from disk (login, start program not cached in memory from previous run), I'm all out of luck. I killed the testing ftp-transfer about 15 seconds after the transfer speed dropped, now I'm waiting for 10+ minutes for ``top'' to start. I can install ports and kernels and world fine, but ezjail-admin install or transferring a few GB of files from another machine sends it to limbo. The next step would likely be to go through the kernel changes between 8.2 and 8.3 to narrow it down, I'd appreciate pointers as to what kernel changes to look out for, or other suggestions on what to do. Verbose dmesg: http://gurder.ross.cx/misc/dmesg.txt TIA, Michael Postscript: That's the same problem I wrote about in Trouble with gmirror and device ada, turns out using gmirror just makes the problem appear much faster as opposed to eventually. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.2 -8.3 regression on disk writes
- Original Message - From: Michael Ross g...@ross.cx To: freebsd-stable@freebsd.org Sent: Monday, July 16, 2012 2:23 PM Subject: 8.2 -8.3 regression on disk writes Hello, using 8.2 the machine runs fine, using 8.3 or higher, not so much. In laymans terms, if I do too many writes/time just once, the machine can't do any disk access for a couple of hours. As in: What's already running stays running, no crashes or anything, but as soon as I need to read from disk (login, start program not cached in memory from previous run), I'm all out of luck. I killed the testing ftp-transfer about 15 seconds after the transfer speed dropped, now I'm waiting for 10+ minutes for ``top'' to start. I can install ports and kernels and world fine, but ezjail-admin install or transferring a few GB of files from another machine sends it to limbo. The next step would likely be to go through the kernel changes between 8.2 and 8.3 to narrow it down, I'd appreciate pointers as to what kernel changes to look out for, or other suggestions on what to do. Verbose dmesg: http://gurder.ross.cx/misc/dmesg.txt You have some strangeness there: I see: real memory = 17179869184 (16384 MB) avail memory = 2050920448 (1955 MB) So even though you have 16GB ram your only using 2GB of it which will likely cause slowness under ZFS including disabling prefetch ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add vfs.zfs.prefetch_disable=0 to /boot/loader.conf. Is this a VM or something? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Build failure xorg-drivers with Clang
On Sun, 15 Jul 2012 14:50:13 +0200 Dimitry Andric d...@freebsd.org wrote: On 2012-07-10 15:41, Robert wrote: ... Complete attempt at build (xorg-drivers.log) can be viewed at pastebin.com/u/traveling08 Aha, I hadn't realized this wasn't yet fixed for clang. Please try the attached patch. If I applied this correctly then it has not changed anything. Please correct me if I have done this improperly. I placed your patch in /usr/ports/x11-servers/xorg-server/files as seen below -rw-r--r-- 1 root wheel 5536 Apr 21 10:03 extra-arch-ia64 -rw-r--r-- 1 root wheel 438 May 4 2010 extra-arch-powerpc -rw-r--r-- 1 root wheel 3487 Apr 24 10:28 extra-dix_events.c -rw-r--r-- 1 root wheel 2382 Apr 21 10:03 extra-hw_dmx_glxProxy_compsize.h -rw-r--r-- 1 root wheel 1815 Apr 21 10:03 extra-hw_dmx_glxProxy_glxcmds.h -rw-r--r-- 1 root wheel 799 Apr 21 10:03 extra-include_eventstr.h -rw-r--r-- 1 root wheel 645 Apr 21 10:03 extra-patch-os-utils.c -rw-r--r-- 1 root wheel 966 Jul 15 16:43 patch-Xserver-hw-xfree86-common-compiler.h ^^ -rw-r--r-- 1 root wheel 384 May 19 2007 patch-Xserver-hw-xfree86-common-xf86Config.c -rw-r--r-- 1 root wheel 469 May 19 2007 patch-Xserver-hw-xfree86-os-support-bsd-i386_video.c -rw-r--r-- 1 root wheel 402 Mar 31 2009 patch-Xserver-hw-xfree86-os-support-bsd-sparc64_video.c -rw-r--r-- 1 root wheel 350 May 19 2007 patch-Xserver-os-xprintf.c -rw-r--r-- 1 root wheel 320 May 19 2007 patch-servermd.h -rw-r--r-- 1 root wheel 471 May 19 2007 patch-xorgconf.cpp And it shows up in :/usr/ports/x11-servers/xorg-server/work/xorg-server-1.7.7/x11-servers/xorg-server/files % ls -l total 4 -rw-r--r-- 1 root wheel 481 Jul 15 18:23 patch-Xserver-hw-xfree86-common-compiler.h -rw-r--r-- 1 root wheel 0 Jul 15 18:23 patch-Xserver-hw-xfree86-common-compiler.h.orig I checked on a different computer that is running 9 Stable.I did a make from /usr/ports/x11-servers/xorg-server and there was not a directory /x11-servers/ under /work/xorg-server-1.7.7/ Thanks again and I can provide anything if you need more information. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Graphics Performance with the new KMS Driver...
Hi, I just installed FreeBSD 9-stable on a new desktop machine equipped with an i3 2120 CPU (HD Graphics 2000). I compiled xorg with WITH_NEW_XORG=true and WITH_KMS=true, following the instructions on http://wiki.freebsd.org/Intel_GPU . Xorg seems to be running without crashing and I have confirmed that direct rendering is enabled using glxinfo, which is great. However, I only get about 9 fps with GLPlanet and I can't play (non-HD) Youtube videos fullscreen on a 1080p monitor without severe noticeable hangs. I was wondering if it is normal to observe this not so great performance. I could not do a direct comparison on the same machine unfortunately, but I get a drastically better graphics performance with GLPlanet from my laptop running Gentoo and equipped with an i7 2860QM CPU (HD Graphics 3000). I get a frame rate of about 60 fps fullscreen on a 1080p monitor with that laptop. So basically I would be interested to know: -Is it normal to obtain that kind of performance from these i3 CPUs when running FreeBSD? -How does the graphics performance compare between Linux and FreeBSD with the new KMS driver? Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
MFC for ZFS fix?
I've been seeing a panic on my FreeBSD/ZFS server (running 9-STABLE built on 6/28), where the relevant line appears to be: avl_find() succeeded inside avl_add() I found a patch pjd committed to trunk (r230454), which apparently was supposed to be MFC'd a week later, but it doesn't appear to be in FreeBSD 9-STABLE yet. I rebuilt my kernel with this patch applied and the server has been fairly stable for over 24h now, and the things I was doing that caused it to kernel panic previously are now working fine. The filesystems were created with 'zfs recv' from an older OpenSolaris installation. Any chance this might make it into FreeBSD for 9.1? -clee ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
The MFC process...
There are currently no automated MFC systems in place, correct? I.e. the onus is completely on the developer that made the change to head to merge back to stable? Do the RELENG team do anything in particular to check that changes for MFC actually make it back to stable? Reason for asking, I noticed a bit of disparity between dev/isp between head and stable/9: % svn mergeinfo --show-revs eligible \ svn://svn.freebsd.org/base/head/sys/dev/isp \ svn://svn.freebsd.org/base/stable/9/sys/dev/isp r227126 r227548 r228914 r237210 r237537 r237544 r238486 I'm currently running a local tree with those revs merged in manually (simply via `svn merge svn://svn.freebsd.org/base/head/sys/dev/isp .` in /usr/src/sys/dev/isp), but it'd be nice to get them into 9.1, as they're all past their recommend soak time (except for that last one, which is a typo fix). Anyway, that got me thinking about the MFC process, especially leading up to another release, hence this e-mail. What's the preferred way for non-committers to bring outstanding MFCs to the attention of committers? Regards, Trent. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: The MFC process...
On 16 July 2012 19:33, Trent Nelson tr...@snakebite.org wrote: There are currently no automated MFC systems in place, correct? I.e. the onus is completely on the developer that made the change to head to merge back to stable? Correct. Do the RELENG team do anything in particular to check that changes for MFC actually make it back to stable? As far as I am aware, they do not. Reason for asking, I noticed a bit of disparity between dev/isp between head and stable/9: ... I'm currently running a local tree with those revs merged in manually (simply via `svn merge svn://svn.freebsd.org/base/head/sys/dev/isp .` in /usr/src/sys/dev/isp), but it'd be nice to get them into 9.1, as they're all past their recommend soak time (except for that last one, which is a typo fix). We are currently in a code freeze for 9.1 so no unapproved MFCs may be committed. Anyway, that got me thinking about the MFC process, especially leading up to another release, hence this e-mail. What's the preferred way for non-committers to bring outstanding MFCs to the attention of committers? Exactly the way you did it here: a polite email. :) -- Eitan Adler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 9.1-BETA1 Available...
The first test build of the 9.1-RELEASE release cycle is now available on the FTP servers for amd64, i386, powerpc64, and sparc64. The MD5/SHA256 checksums are at the bottom of this message. The ISO images and, for architectures, that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/ (or any of the FreeBSD mirror sites). We hope this will be the only BETA build, to be followed by two Release Candidate builds and then the release itself. The original schedule is available here: http://www.freebsd.org/releases/9.1R/schedule.html but we're a bit behind schedule already. I'll adjust the schedule within the next couple of days. If you notice any problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you would like to use csup/cvsup mechanisms to do a source-based update of an existing system the branch tag to use is RELENG_9. If you would like to use SVN instead use stable/9. Note that if you do an update that way the system will call itself 9.1-PRERELEASE. Checksums: MD5 (FreeBSD-9.1-BETA1-amd64-bootonly.iso) = ff296912b6b4135476d3012ff020a55e MD5 (FreeBSD-9.1-BETA1-amd64-disc1.iso) = 60c82350efa8a45cb6376fcefe4e1c84 MD5 (FreeBSD-9.1-BETA1-amd64-memstick.img) = 2baf4398cbcdd733cbef381b78fc1d88 MD5 (FreeBSD-9.1-BETA1-i386-bootonly.iso) = 483f2efb2ed46ded418a404d47bdf98d MD5 (FreeBSD-9.1-BETA1-i386-disc1.iso) = 244e526aa109b1dbbe1a0f25d40de4bf MD5 (FreeBSD-9.1-BETA1-i386-memstick.img) = 98f687ad1ef71b1bf3c8b82362b9bf49 MD5 (FreeBSD-9.1-BETA1-powerpc64-bootonly.iso) = 9dd0c70d52fab38a87d5fc01eb078af1 MD5 (FreeBSD-9.1-BETA1-powerpc64-memstick) = 4c4ec197755d5732788fc1c11d6baf7d MD5 (FreeBSD-9.1-BETA1-powerpc64-release.iso) = 44cbe2ea14e41cc23ee633cb8e619730 MD5 (FreeBSD-9.1-BETA1-sparc64-bootonly.iso) = f7cb375c6d941d62abd8260e6ce42d3d MD5 (FreeBSD-9.1-BETA1-sparc64-disc1.iso) = aa450e7772e09bfa79d6d19be6a0fba5 SHA256 (FreeBSD-9.1-BETA1-amd64-bootonly.iso) = babf94070c798e06d93923fa84e5d1c1fa37ab4bef7959d68c73bf40d1568418 SHA256 (FreeBSD-9.1-BETA1-amd64-disc1.iso) = f895c688dac933e13bfaa4c02ed73ac2e21752b257693cbbe416077fdf255331 SHA256 (FreeBSD-9.1-BETA1-amd64-memstick.img) = 977fa2772a86156c2c61f2b80173b15b95ebcf38f9ad5a7d2b78727f5bf13d0b SHA256 (FreeBSD-9.1-BETA1-i386-bootonly.iso) = 353ff599a55af0664f52ecaa8c7b5f497b94a9d3e043dc616107b5ddf46e53f2 SHA256 (FreeBSD-9.1-BETA1-i386-disc1.iso) = 29c36dfab60261f0823ca5620e838f8347a267d40af0b56f4d5a881c559cf2c2 SHA256 (FreeBSD-9.1-BETA1-i386-memstick.img) = 1b14bd8bd47be80bf3cb8b63e3ee27d74d00cb32a4c5203ee9fabef39a58d3a7 SHA256 (FreeBSD-9.1-BETA1-powerpc64-bootonly.iso) = e9deebc21bd815fd61162a419bcb01bd6c2ca254f8268c4858f168af5add3f58 SHA256 (FreeBSD-9.1-BETA1-powerpc64-memstick) = bda64320367c1ef5dac1a3e24d3f20979908cb7e23f0a80f17433b41f6a04601 SHA256 (FreeBSD-9.1-BETA1-powerpc64-release.iso) = 7171c7a1c14f06644ab6706af8afd0a0b8330bd32ce71d01d823aae8bdf90b73 SHA256 (FreeBSD-9.1-BETA1-sparc64-bootonly.iso) = c6a869beeb2d5afab8a93363c34c434751bf4252cc798e940bd1cb74786a14b4 SHA256 (FreeBSD-9.1-BETA1-sparc64-disc1.iso) = 5b04e7989d8ab26ad788f989009e2f5a493858e3b4e67256d3774e68e0073431 -- Ken Smith - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: 8.2 -8.3 regression on disk writes
Have you tried switching your scheduler to 4BSD? -- Change is hard. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: The MFC process...
On 7/16/12 11:19 PM, Eitan Adler li...@eitanadler.com wrote: On 16 July 2012 19:33, Trent Nelson tr...@snakebite.org wrote: There are currently no automated MFC systems in place, correct? I.e. the onus is completely on the developer that made the change to head to merge back to stable? Correct. Do the RELENG team do anything in particular to check that changes for MFC actually make it back to stable? As far as I am aware, they do not. Sounds like a what-hasn't-been-MFC'd-back-to-stable-yet script could be quite useful, then ;-) Thanks for the info. Trent. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
