Re: less and vi fail on file whose name begins with +
from Glen Barber : > 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: 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: on bge0 > brgphy0: 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: 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: on bge1 > brgphy1: 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: 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: 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 > pci0:1:0:1 > map[18]: type Prefetchable Memory, range 64, base 0xd51e, > size 16, enabled > pcib2: allocated pre
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" To: 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 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 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" wrote: >On 16 July 2012 19:33, Trent Nelson 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"
Re: The MFC process...
On 16 July 2012 22:35, Trent Nelson wrote: > On 7/16/12 11:19 PM, "Eitan Adler" wrote: > >>On 16 July 2012 19:33, Trent Nelson 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 ;-) Of interest to me: if it could be limited to just the commits I made and optionally show me the log message and diff it would be very helpful. On a general note: be careful with any level of automation with this script though. Sometimes there are good reasons that a commit wasn't MFCed. -- 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"
