Re: kern/143370: splash_txt ASCII splash screen module
On Thu, Jun 30, 2011 at 12:47:45PM +1000, Antony Mawer wrote: > On Thu, Jun 30, 2011 at 11:33 AM, jhell wrote: > > Youve been running this in production... How often do these servers > > reboot ;¿ and is it to identify what is actually running on the machine > > so they are not confused with surrounding equipment ? > > > > Most admins that I know don't bother with things like splash screens on > > 'production' equipment because its irrelevant to the actual server > > usage and unneeded overhead since the actual boot messages prove much > > more useful than some random ascii or bmp/pcx. > > They're embedded-style server systems at remote client sites, about > 1200 of them. The splash module is just a visual "nicety" which is > displayed during startup - at least providing some feedback as to what > the system is doing. These are systems aimed at a non-tech audience, > so those "niceties" count. > > The alternative to that was either standard kernel messages during > boot, or a silent boot, both of which tend to confuse the crap out of > non-tech end users. > Yeah I agree. I originally downloaded your patch, I think it was for a 6.X system back then ~2008-09ish possibly even 7.X and twiddled with it for a bit playing around with all the funkiness of TheDraw and getting that good ole feeling of BBS days. But that's usually about as far as I go with things like that as you could probably tell from above ;) I was going through my archive file directory probably last month and came across the copy of the program which made me remember that patch, funny coincidence that it comes back up now ;) I must say though having to use a reproducible .bin file over trying to figure out all the complexities of making a proper gzip'd xpm,bmp,pcx file was NICE! My first attempt ever making a splash image bmp was a fail due to manual reading problems but needless to say it was a pain. TheDraw nearly painless but how long can we seriously hold on to that program and will there ever be anything to replace it ? ___ 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: kern/143370: splash_txt ASCII splash screen module
On Wed, Jun 29, 2011 at 07:04:31PM +0200, Torfinn Ingolfsen wrote: > On Wed, 29 Jun 2011 22:50:15 +1000 > Antony Mawer wrote: > > > Hi all, > > > > Not sure if this is the right place to post it -- about 6 years ago I > > put together a module which displays an ASCII splash screen on boot > > (rather than the graphical splash_pcx and splash_bmp modules). We have > > been running it in production since that time without issue. > > So, the difference between this and loader.conf's loader_logo construct is > that > a) this is a proper splash screen module > b) you can / must design your splash screen with a separate program (compared > to write / modify Forth code) > > Is my understanding correct? Sorry but I can never resist... Youve been running this in production... How often do these servers reboot ;¿ and is it to identify what is actually running on the machine so they are not confused with surrounding equipment ? Most admins that I know don't bother with things like splash screens on 'production' equipment because its irrelevant to the actual server usage and unneeded overhead since the actual boot messages prove much more useful than some random ascii or bmp/pcx. Again though my view of a production box/blade may be quite a bit different than your usage so all-in-all nice contribution, Im just that guy that doesn't waste time covering up usefulness. ___ 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: Change in behavior to stat(1)
On Mon, 28 Feb 2011 12:15, stephen@ wrote:
I had a little script that would remove broken links. I used to do it like
this:
if ! stat -L $link > /dev/null; then rm $link; fi
But recently (some time in February according to the CVS records) stat was
changed so that stat -L would use lstat(2) if the link is broken.
So I had to change it to
if stat -L $link | awk '{print $3}' | grep l > /dev/null;
then rm $link; fi
but it is a lot less elegant.
What is the proper accepted way to remove broken links?
Stephen
You might find sysutils/symlinks interesting. I have been using it a long
time and have not had to consider adjusting much in the way of shell
scripting to remove dirty links.
-c == change absolute/messy links to relative
-d == delete dangling links
-o == warn about links across file systems
-r == recurse into subdirs
-s == shorten lengthy links
-t == show what would be done by -c
-v == verbose (show all symlinks)
Quite interesting though how such a little tweak has caused a massive
expansion of your command line and required utils.
Good luck,
--
jhell
___
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-RELEASE pf rules not loading
On Fri, 25 Feb 2011 17:31, freebsd@ wrote: On Fri, Feb 25, 2011 at 10:23:58PM +, Vincent Hoffman wrote: On 25/02/2011 17:35, Josh Carroll wrote: Hi All, Just upgraded my home machine to 8.2-RELEASE via freebsd-update remotely (spare time at work.) and on reboot my pf ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted does start it fine though. Any suggestions on debugging or shall i just try a verbose boot and watch the console when I get home? I still have pf_enable="YES" # Set to YES to enable packet filter (pf) pflog_enable="YES" # Set to YES to enable packet filter logging in /etc/rc.conf Is your interface dynamic (e.g. using DHCP)? If so, you might try changing: ifconfig_="DHCP" to ifconfig_="SYNCDHCP" It's possible the network hasn't come up properly yet or there is no IP assigned. Failing that, you can set: rc_debug="YES" in rc.conf then watch at boot time if there are any odd messages when it attempts to start pf. It turns out that its sort of related to this. I have an IPv6 tunnel from H.E. (tunnelbroker.net) and from looking at the boot output, it looks like the IPv6 addresses (for any of my imterfaces) aren't applied until after pf starts. I'd say this is a bug, Oddly this didnt happen for the release candidate I tried, although I think I may have modified my rules and not rebooted until I upgraded. the rules in question are: pass in quick on $gif_if inet6 proto udp to $ext_if port $udp_services keep state and pass in quick on $gif_if inet6 proto tcp to $ext_if port $tcp_services $sf_tcp (ext_if = "ue0") I'll try changing $ext_if to the ipv6 address and see if that helps. Please look at pf.conf(5) and search for the word "parentheses" (should be under the "from x to x" section. This might resolve your problem. Adding to this and as someone else has already advised in a different way is to use synchronous_dhclient="YES" in rc.conf(5) will most likely result in your rules loading properly. -- jhell ___ 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: New ZFSv28 patchset for 8-STABLE: Kernel Panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/28/2010 18:20, Martin Matuska wrote: > Please don't consider these patches as production-ready. > What we want to do is find and resolve as many bugs as possible. I completely agree with Martin here. If your running it then your willing to loose what you have if you have not taken precaution to save your data somewhere else. Even though with that said ZFS does a pretty fine job of ensuring that nothing happens to it, it is still best practice to have a copy somewhere other than "IN THAT BOX" ;) Another note too, I think I read that you mentioned using the L2ARC and slog device on the same disk You simply shouldn't do this it could be contributing to the real cause and there is absolutely no gain in either sanity or performance and you will end up bottle-necking your system. > > To help us fix these bugs, a way to reproduce the bug from a clean start > (e.g. in virtualbox) would be great and speed up finding the cause for > the problem. > > Your problem looks like some sort of deadlock. In your case, when you > experiene the hang, try running "procstat -k -k PID" in another shell > (console). That will give us valuable information. > Martin, I agree with the above that it may be some sort of live or dead lock problem in this case. It would be awesome to know if some of the following sysctl(8)'s values are and how this reacts when set to the opposite of their current values. vfs.zfs.l2arc_noprefetch: vfs.zfs.dedup.prefetch: vfs.zfs.prefetch_disable The reason why I say this is on one of my personal systems that I toy with the box cannot make it very long with prefetch enabled on either v15 or v28 after some 'unknown' commit to world on stable/8. Now this may actually be just a contributing factor that makes it happen sooner than it normally would but probably also directly relates to the exact problem. I would love to see this go away as I had been using the L2ARC with prefetch enabled for a long time and now all of a sudden just plainly does not work correctly. I also have about 19 core.txt.NN files from when this started happening with various stack traces. If you would like these just let me know and Ill privately mail them to you. Regards, - -- jhell,v - JJH48-ARIN -BEGIN PGP SIGNATURE- iQEbBAEBAgAGBQJNGsDLAAoJEJBXh4mJ2FR+TqkH8wVFQKiU/C6L+F4Y3/ClScQD b4s0IkC1B+bHl9eD6Hhxif/1iKj1w9clYvuLt8ageDF98KTB9GCRjuh48VswdtPQ FQtDRTj1pGzWPxmOn2Nrf7qrFnymqZk+qoTBX8A1nDvrSe41Mqp82ue9E7nZ1ipg Dz9k5F8J+WxUAZYLHxtxLvYEa19/hvG1K5LOpRKIU0iycsqaywezFflTGDcR5lT8 A50ic9sZ21jr87CK45TLv1Wmu+kDgpy2j1x77bYTDGoAzQMlPcOENO8st8EobcWB eIwwXIjtRwOKF4rSxoqwwYxOM4ek+tK4p6ZnO1uLipNXMB+zJTjs//GV6Xp3TA== =Io4+ -END PGP SIGNATURE- ___ 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: New ZFSv28 patchset for 8-STABLE: Kernel Panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/26/2010 23:17, Jean-Yves Avenard wrote: > Responding to myself again :P > > On 27 December 2010 13:28, Jean-Yves Avenard wrote: >> tried to force a zpool import >> >> got a kernel panic: >> panic: solaris assert: weight >= space && weight <= 2 * space, file: >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c, >> line: 793 >> >> cpuid = 5 >> KDB: stack backtrace >> #0: 0xff805f64be at kdb_backtrace >> #1 .. panic+0x187 >> #2 .. metaslab_weight+0xe1 >> #3: metaslab_sync_done+0x21e >> #4: vdev_sync_done >> #5: spa_sync+0x6a2 >> #6 txg_sync_thread+0x147 >> #7: fork_exit+0x118 >> #8: fork_trampoline+0xe >> >> uptime 2m25s.. >> > > Command used to import in FreeBSD was: > zpool import -fF -R / pool > which told me that zil was missing, and to use -m > > I booted openindiana (which is the only distribution I could ifnd with > a live CD supporting zpool v28) > > Doing a zpool import actually made it show that the pool had > successfully been repaired by the command above. > It did think that the pool was in use (and it was, as I didn't do a > zpool export). > > So I run zpool import -f pool in openindiana, and luckily, all my > files were there. Not sure if anything was lost... > > in openindiana, I then ran zpool export and rebooted into FreeBSD. > > I ran zpool import there, and got the same original behaviour of a > zpool import hanging, I can't sigbreak it nothing. Only left with the > option of rebooting. > > Back into openindiana, tried to remove the log drive, but no luck. > Always end up with the message: > cannot remove log: no such device in pool > > Googling that error seems to be a common issue when trying to remove a > ZIL but while that message is displayed, the log drive is actually > removed. > Not in my case.. > > So I tried something brave: > In Open Indiana > zpool export pool > > rebooted the PC, disconnected the SSD drive I had use and rebooted > into openindiana > ran zpool import -fF -R / pool (complained that log device was > missing) and again zpool import -fF -m -R / pool > > zfs status showed that logs device being unavailable this time. > > ran zpool remove pool log hex_number_showing_in_place > > It showed the error "cannot remove log: no such device in pool" > but zpool status showed that everything was allright > > zpool export pool , then reboot into FreeBSD > > zpool import this time didn't hang and successfully imported my pool. > All data seems to be there. > > > Summary: v28 is still buggy when it comes to removing the log > device... And once something is screwed, zpool utility becomes > hopeless as it hangs. > > So better have a OpenIndiana live CD to repair things :( > > But I won't be trying to remove the log device for a long time ! at > least the data can be recovered when it happens.. > > Could it be that this is related to the v28 patch I used > (http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101223-nopython.patch.xz > and should have stuck to the standard one). > Before anything else can you: (in FreeBSD) 1) Set vfs.zfs.recover=1 at the loader prompt (OK set vfs.zfs.recover=1) 2) Boot into single user mode without opensolaris.ko and zfs.ko loaded 3) ( mount -w / ) to make sure you can remove and also write new zpool.cache as needed. 3) Remove /boot/zfs/zpool.cache 4) kldload both zfs and opensolaris i.e. ( kldload zfs ) should do the trick 5) verify that vfs.zfs.recover=1 is set then ( zpool import pool ) 6) Give it a little bit monitor activity using Ctrl+T to see activity. You should have your pool back to a working condition after this. The reason why oi_127 can't work with your pool is because it cannot see FreeBSD generic labels. The only way to work around this for oi_127 would be to either point it directly at the replacing device or to use actual slices or partitions for your slogs and other such devices. Use adaNsN or gpt or gptid for working with your pool if you plan on using other OS's for recovery effects. Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJNGB5QAAoJEJBXh4mJ2FR+rUAH/1HhzfnDI1jTICrA2Oiwyk12 BLXac0HoTY+NVUrdieMUWPh781oiB0eOuzjnOprev1D2uTqrmKvivnWdzuT/5Kfi vWSSnIqWiNbtvA5ocgWs7IPtcaD5pZS06oToihvLlsEiRyYXTSh2XD7JOsLbQMNb uKTfAvGI/XnNX0OY3RNI+OOa031GfpdHEWon8oi5aFBYdsDsv3Wn8Z45qCp8yfI+ WZlI+P+uunrmfgZdSzDbpAxeByhTB+8ntnB6QC4d0GRXKwqTVrFmIw5yuuqRAIf8 oCJYDhH6AUi+cxAGDExhLz2e75mEZNHAqB2nkxTaWbwL/rGjBnVidNm1aj7WnWw= =FlmB -END PGP SIGNATURE- ___ 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: New ZFSv28 patchset for 8-STABLE
Hi Martin, List, Patched up to a ZFSv28 20101218 and it is working as expected, Great Job!. There seems to be some assertion errors that are left to be fixed yet with the following examples: Panic String: solaris assert: vd->vdev_stat.vs_alloc == 0 (0x18a000 == 0x0), file:/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c, line: 4623 #3 0x84caca35 in spa_vdev_remove (spa=0x84dba000, guid=2330662286000872312, unspare=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:4623 4623ASSERT3U(vd->vdev_stat.vs_alloc, ==, 0); (kgdb) list 4618 4619/* 4620 * The evacuation succeeded. Remove any remaining MOS metadata 4621 * associated with this vdev, and wait for these changes to sync. 4622 */ 4623ASSERT3U(vd->vdev_stat.vs_alloc, ==, 0); 4624txg = spa_vdev_config_enter(spa); 4625vd->vdev_removing = B_TRUE; 4626vdev_dirty(vd, 0, NULL, txg); 4627vdev_config_dirty(vd); This happens on i386 upon ( zfs remove pool ) Also if it is of any relevance this happens during ``offline'' too. If further information is needed I still have these cores and kernel just let me know what you need. Regards, -- jhell,v ___ 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: ZFS v28 on 8.2-PRERELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/22/2010 08:48, ciaby wrote: > P.S. Can i remove the SSD ZIL without upgrading the pool? Simply put `NO' Longer answer, ZFS will complain at the point where you try to replace the log device or remove it and tell you it was formatted using an older version. OpenSolaris and OpenIndiana both do this so the expectancy of FreeBSD would be to do the same. Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJNEsneAAoJEJBXh4mJ2FR+oY4IAJXHj2b29RxuP9M8Ru0ixFEj T4CVYQ9KFkPxozbb2OZW60lpEGOtJfPuHzzqX5ICAUgFnbeSwM0kMIBDvI2srE2l WvlSNwIB7wTdOac6s74o0IWBh4TBhKBMgFeQ+CLZlMkKoEs2HGwbYYqPg+R/+0gD x+sOQdfiMa1sUwMupl2QOFR5Iq1z+4IGNljVvg43EZ5IvJCc7dGF9vaE1V4gNkdq MNT/OphXOHirngdfphiRb7mdRss3k49NwrSaiPxlg4X+KNHI1BQmpZOLgLE+7Chg M6RfHSgoLkmtl2XK4H7eIivfnQrloU/4RMnou4LG2uPrNHHg/YbfqXjaehajXCc= =ZCc1 -END PGP SIGNATURE- ___ 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: aesni(?) corrupts data on 8.2-BETA1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 17 Dec 2010 09:01, Mike Tancsa wrote: In Message-Id: <4d0b6d26.7030...@sentex.net> On 12/16/2010 8:14 PM, jhell wrote: On 12/16/2010 20:10, jhell wrote: Regarding this patch(r216455) and r216162 I have had to back both of them out of my local tree to avoid panics on a ZFS & UFS2 i386 system. I have zfs & UFS on AMD64 and have not seen any issues. How do you trigger the issue in i386 ? Or does it just randomly happen ? Looks as if I have it narrowed down to that its only effecting prefetch on i386. Seeing as prefetch is not really suggested below 4G of RAM and as well on i386 it is not really much concern to me ATM. Whatever did change "Not in the ZFS code" & "Not in r216162 or r216455" has effected prefetch on i386 directly though or at least as far as I can see for the moment. As of right now Ill look into a few other commits starting with r216305 which was a MFC of r216194. I would like to see this resolved as I currently only have i386's to run from unless that is someone would like to donate some hardware ;) Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJNDD0AAAoJEJBXh4mJ2FR+SqIH/jkWf8Z69lKC3wlSYjwwNqTL gX/rEuAU/2xOQj2bKR4/BEfeNXtSy9n47IbbCZApGuBABf2lkytSUk2n1XgQ1sB1 GRJl8gCm5BtmhZh0oTc9CIwUcJy+h/w3dU34WXp5riegk0MwpPJlbx9JX4huC+6s j+wG0oJpxJZq1v/0uWM7ks1D6yYzgBXFyp9j+8ZGoeeXIeraqglj57eB0+Ck1Jq2 JjQ9uLTqnkLS2Zzf/Vgbju4O4bV6geAd+j6Td6Fwt+c3yHCWOHSFQcakyrdJzntl feWJPAl9ZZSGBhvdAH4pumLt01BVyESIe/rsbtD68pAIGWqxrL3NsI6bIDg3cvI= =apgr -END PGP SIGNATURE- ___ 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: aesni(?) corrupts data on 8.2-BETA1
On 12/17/2010 09:01, Mike Tancsa wrote: > On 12/16/2010 8:14 PM, jhell wrote: >> On 12/16/2010 20:10, jhell wrote: >>> Regarding this patch(r216455) and r216162 I have had to back both of >>> them out of my local tree to avoid panics on a ZFS & UFS2 i386 system. > > > I have zfs & UFS on AMD64 and have not seen any issues. How do you > trigger the issue in i386 ? Or does it just randomly happen ? > > ---Mike I can simply run a scrub on the pool and within a little while within 12% - 18% it goes ker-plunk!. Not that it really has to do with the percentage rage as it does the timing. I do have prefetch enabled when this happens and currently running with it turned off and will booting so said kernel.bad in a little while to see if that makes a difference. -- jhell,v ___ 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: aesni(?) corrupts data on 8.2-BETA1
On 12/16/2010 20:10, jhell wrote: > Regarding this patch(r216455) and r216162 I have had to back both of > them out of my local tree to avoid panics on a ZFS & UFS2 i386 system. > > With the following panic strings: > Dumptime: Thu Dec 9 08:37:40 2010 > Panic String: double fault > Dumptime: Thu Dec 9 08:41:57 2010 > Panic String: page fault > Dumptime: Fri Dec 10 00:23:35 2010 > Panic String: free: address 0x85ceb000(0x85ceb000) has not been allocated. > Dumptime: Fri Dec 10 14:37:33 2010 > Panic String: page fault > Dumptime: Sat Dec 11 04:10:01 2010 > Panic String: vm_fault: fault on nofault entry, addr: 8289c000 > Dumptime: Sun Dec 12 23:45:01 2010 > Panic String: page fault > Dumptime: Tue Dec 14 01:32:09 2010 > Panic String: page fault > Dumptime: Tue Dec 14 16:46:33 2010 > Panic String: general protection fault > Dumptime: Thu Dec 16 10:03:15 2010 > Panic String: vm_fault: fault on nofault entry, addr: b3811000 > > > Seems to be caused by r216162 or directly related to it. If further > information is needed let me know. Ill be around here for the next few > hours. > PS: Also when the system crashes with the above panic strings /boot/zfs/zpool.cache ends up corrupt leaving me with the need to boot from a good kernel and force import the pool. Also scrubs with the two revs end up with checksum errors all over the place. Without it everything returns to normal. -- jhell,v ___ 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: aesni(?) corrupts data on 8.2-BETA1
On 12/12/2010 03:43, Kostik Belousov wrote:
> On Sat, Dec 11, 2010 at 07:37:51PM -0500, Mike Tancsa wrote:
>> On 12/11/2010 6:22 PM, Kostik Belousov wrote:
>>> On Sat, Dec 11, 2010 at 06:08:08PM -0500, Mike Tancsa wrote:
>>>> On 12/11/2010 11:01 AM, Kostik Belousov wrote:
>>>>>
>>>>> I have no access to AESNI hardware. For start, you may use
>>>>> src/tools/tools/crypto/cryptotest
>>>>> to somewhat verify the sanity of the driver.
>>>>
>>>> I doesnt happen every time, but one out of 5 or so
>>>>
>>> First, which arch is it, amd64 or i386 ?
>>>
>>> Also, please revert r216162 and do the same tests.
>>
>> Hi,
>> Its AMD64, but i386 seems to be impacted too. I am not sure how to
>> revert to a specific commit, but for now I csup'd with a date tag of
>>
>> *date=2010.12.02.23.00.00
>>
>> which is a day before
>> http://lists.freebsd.org/pipermail/svn-src-stable-8/2010-December/004338.html
>>
>>
>> And that seems to fix it!
>>
>> I have been running
>> cryptotest -c -z -t 10
>> in a loop for the past 10min and not one error.
>
> Please try this patch on the latest HEAD or RELENG_8.
>
> diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c
> index 482b5da..1b493b4 100644
> --- a/sys/amd64/amd64/fpu.c
> +++ b/sys/amd64/amd64/fpu.c
> @@ -426,7 +426,9 @@ fpudna(void)
> fxrstor(&fpu_initialstate);
> if (pcb->pcb_initial_fpucw != __INITIAL_FPUCW__)
> fldcw(pcb->pcb_initial_fpucw);
> - fpuuserinited(curthread);
> + pcb->pcb_flags |= PCB_FPUINITDONE;
> + if (PCB_USER_FPU(pcb))
> + pcb->pcb_flags |= PCB_USERFPUINITDONE;
> } else
> fxrstor(pcb->pcb_save);
> critical_exit();
> diff --git a/sys/i386/isa/npx.c b/sys/i386/isa/npx.c
> index 9ec5d25..f314e44 100644
> --- a/sys/i386/isa/npx.c
> +++ b/sys/i386/isa/npx.c
> @@ -684,7 +684,9 @@ npxdna(void)
> fpurstor(&npx_initialstate);
> if (pcb->pcb_initial_npxcw != __INITIAL_NPXCW__)
> fldcw(pcb->pcb_initial_npxcw);
> - npxuserinited(curthread);
> + pcb->pcb_flags |= PCB_NPXINITDONE;
> + if (PCB_USER_FPU(pcb))
> + pcb->pcb_flags |= PCB_NPXUSERINITDONE;
> } else {
> /*
>* The following fpurstor() may cause an IRQ13 when the
Regarding this patch(r216455) and r216162 I have had to back both of
them out of my local tree to avoid panics on a ZFS & UFS2 i386 system.
With the following panic strings:
Dumptime: Thu Dec 9 08:37:40 2010
Panic String: double fault
Dumptime: Thu Dec 9 08:41:57 2010
Panic String: page fault
Dumptime: Fri Dec 10 00:23:35 2010
Panic String: free: address 0x85ceb000(0x85ceb000) has not been allocated.
Dumptime: Fri Dec 10 14:37:33 2010
Panic String: page fault
Dumptime: Sat Dec 11 04:10:01 2010
Panic String: vm_fault: fault on nofault entry, addr: 8289c000
Dumptime: Sun Dec 12 23:45:01 2010
Panic String: page fault
Dumptime: Tue Dec 14 01:32:09 2010
Panic String: page fault
Dumptime: Tue Dec 14 16:46:33 2010
Panic String: general protection fault
Dumptime: Thu Dec 16 10:03:15 2010
Panic String: vm_fault: fault on nofault entry, addr: b3811000
Seems to be caused by r216162 or directly related to it. If further
information is needed let me know. Ill be around here for the next few
hours.
--
jhell,v
___
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.1-stable kernel compile error
On 12/05/2010 04:56, Irakli wrote: > cvsup don't download /usr/src/sys/crypto/aesni/ files > when I put this files from > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/crypto/aesni/ > kernel compile successfully > csup(1) has replaced cvsup(1) for the most part. But if you are not getting the files you need try removing /var/db/sup or whatever "*default base=" points to in your supfile. You should be good to receive the files in question after this. If all else fails... remove that directory and remove your source tree and repeat. Good luck, -- jhell,v ___ 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: Some /etc files seem out of date in RELENG_8 compared to RELENG_8_1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2010 22:25, Geoff Roberts wrote: > > Hi, > > I was just doing and update to 8-PRERELEASE from 8.1 by using the > RELENG_8 tag in cvsup. > > When I used mergemaster to update /etc, there were a number of files > being merged into /etc that are older revisions than those I had in 8.1. > > You can check this for example by comparing the revision numbers at > the following URLS. > > Compare say syslog.conf (there are a whole list of other files that > are out of date). > > In 8.1 it has a revision of 1.30.2.1.4.1 - 5 months old > > In 8.X it has a revision of 1.30.2.1 - 16 months old > This is how CVS is intended to work. Though my explanation would be to straight to the point, this URL seems to explain it in more detail. These files are not out of date. http://cvsman.com/cvs-1.12.12/cvs_60.php#SEC60 > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/?only_with_tag=RELENG_8_1 > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/?only_with_tag=RELENG_8 > > Shouldn't RELENG_8 have all the changes that went into RELENG_8_1 as > FreeBSD moves to 8.2? > Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJM+HGTAAoJEJBXh4mJ2FR+hxIH/1N0y6/150lH50rTHowRYaHL yJqafch2EcO3HsA0nDtnJx+Vb6qsVTiZgzBXK/mnWI6nDmP8uPz8Y49LFjd0PCPH wrV4TuENeKXl2xxvb8+mGD++cf5VzZim2qgaAq+JWVrphA7UtaqMFBixUwljwFfT 31ivTu2eRpUO2lZyY6LrRYCp7y0sHIMiAuycYghqvvwvdvyizPCR0VrEH/vbLL6O zxxZq2mCUoPLGkVDXdcLp5TYoN2ujRsQCGNvKW93ebz+ipAcwz5bdPicVPmjTtnY vM+Q+jnza+141RkAxTvkIXwN+/THyJJzIx+aWZb5pXPdH7npGsjBmcXLVUbJLlg= =obeJ -END PGP SIGNATURE- ___ 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: FreeBSD Security Advisory FreeBSD-SA-10:10.openssl
On 12/01/2010 12:53, Gareth de Vaux wrote:
> On Mon 2010-11-29 (21:19), FreeBSD Security Advisories wrote:
>> # cd /usr/src
>> # patch < /path/to/patch
>> # cd /usr/src/secure/lib/libssl
>> # make obj && make depend && make && make install
>
> Hi all, I'm following the instructions with:
>
> # cvsup /etc/cvsup-src.conf
> # rm -rf /usr/obj
> # cd /usr/src/secure/lib/libssl
> # make obj && make depend && make
>
> [ snip ]
>
> cc -O -pipe -DTERMIOS -DANSI_SOURCE
> -I/usr/src/secure/lib/libssl/../../../crypto/openssl
> -I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto
> -I/usr/obj/usr/src/secure/lib/libssl -DOPENSSL_THREADS -DDSO_DLFCN
> -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu99
> -fstack-protector -c
> /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c
> /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c: In function
> 'dtls1_hm_fragment_new':
> /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c:210: error:
> 'hm_fragment' has no member named 'reassembly'
>
> [ more hm_fragment.reassembly errors .. ]
>
> *** Error code 1
>
> Stop in /usr/src/secure/lib/libssl.
>
>
> What's going on?
>
> hm_fragment is (only) defined in /usr/src/crypto/openssl/ssl/dtls1.h:
>
> typedef struct hm_fragment_st
> {
> struct hm_header_st msg_header;
> unsigned char *fragment;
> unsigned char *reassembly;
> } hm_fragment;
>
> which has that member and is sourced from the Makefiles.
>
> The first existence complaint in d1_both.c is:
>
> frag->reassembly = bitmask;
>
> yet
>
> frag->fragment = buf;
>
> a few lines earlier is fine?
> ___
> 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"
Try that with a ( make includes ) in that same directory and if it works
then the advisory will have to be revised.
so it should be
make obj
make depend
make includes
make && make install
If all else fails a buildworld would work for you...
Regards,
--
jhell,v
___
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: More IO identification problems
On 11/26/2010 08:41, Andriy Gapon wrote:
> on 26/11/2010 08:05 Adam Vande More said the following:
>> As a follow-up, after applying both patches presented in this thread(FreeBSD
>> 8.2-PRERELEASE #5: Thu Nov 25 19:14:00 CST 2010),
>>
>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060298.html
>>
>> "top -m io" now displays much more info and is generally consistent with
>> gstat in that IO spikes occer around the same time. However, gstat and "top
>> -m io" are still not displaying any stats for 90%+ of my hard drive
>> indicator light blinks. Since the issue effects gstat as well, it doesn't
>> seem like it could be related to ZFS. When the system is basically idling,
>> the only consistent IO related entries are these;
>>
>> 6 root 15 0 1 12 0 13 20.00%
>> {l2arc_feed_threa}
>> 6 root 15 0 1 12 0 13 20.00%
>> {arc_reclaim_thre}
>> 6 root 15 0 1 12 0 13 20.00% {zvol
>> zoot/usr/ho}
>> 6 root 15 0 1 12 0 13 20.00%
>> {txg_thread_enter}
>> 6 root 15 0 1 12 0 13 20.00%
>> {txg_thread_enter}
>>
>> Entries like these occur like clockwork on 30 sec intervals. My theory here
>> is that since the ZVOL has UFS + SU, this is causing a sync?
>>
>> What I'm trying to diagnose is a much more frequent hard drive access which
>> occurs on approximately 2 sec intervals. I timed this by pinging localhost
>> and comparing the response to the blinks. It's very consistent although not
>> completely so as once in awhile the blink occurs every second. If I listen
>> carefully I can hear increased drive activity during many of these intervals
>> so the indicator light seems to be working correctly.
>>
>> If anyone has ideas or tests they'd like me to run, it would be appreciated.
>>
>
> Perhaps it's some external component?
> E.g. hald is known to perform some disk/media checks every two seconds.
>
As well syslod will also cause sync to happen prematurely when something
goes to log.
syslog.conf(5):
***
To ensure that kernel messages are written to disk promptly,
syslog.conf calls fsync(2) after writing messages from the kernel.
Other messages are not synced explicitly. You may prefix a pathname
with the minus sign, ``-'', to forego syncing the specified file
after every kernel message. Note that you might lose information if
the system crashes immediately following a write attempt. Neverthe-
less, using the ``-'' option may improve performance, especially if
the kernel is logging many messages.
***
This is obviously the old way of ensuring logs are written to disk
before crash but now ZFS is handled differently. Check to see if adding
'-' to your syslog entries relieves that problem as ZFS will do the
right thing to ensure your data is written to disk.
--
jhell,v
___
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: top io mode
On 11/25/2010 06:28, Adam Vande More wrote: > top io doesn't seem to display stats when dealing direct with a block device > like so: > > dd if=/dev/ada0 of=/dev/null > > However if dd runs on a regular file eg > > dd if=test.file of=/dev/null > > then stats are reported in top. > > Is this the expected behavior? > Is this on ZFS ? If that is the case it is a known problem that needs the following patch to fix the issue. http://people.freebsd.org/~avg/zfs-ru.diff I believe it is planned to be MFC'd but am not quite sure so I have CC'd Andriy and he should be able to advise further. Regards, -- jhell,v ___ 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: Can not build either kernel nor 'world'
On 11/23/2010 20:33, Zhihao Yuan wrote: > I built and installed the latest 'world' this afternoon, and found that I > can not build the kernel now. And, the devd can not be started. I do not > know what's wrong. Maybe I need to downgrade my system to 8.1-RELEASE first. > What should I do now? > This does not provide much information, You are trying to build world and kernel for 8.1-STABLE ? or 8.1-RELEASE ?, CURRENT/HEAD ? Have a log that you can put a link up somewhere so it can be viewed ? Have you followed UPDATING entries that may be relavent to upgrading to whatever your building ? Also have a make.conf and src.conf with entries in it ? if so have you tried removing those entries ? Was your obj directory empty before you started your build ? If not, remove it and start from scratch. Also defining -DALWAYS_CHECK_MAKE may help in your situation as well but its really hard to tell from this point. -- jhell,v ___ 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 panics/hardlocks when savage module is inserted
On 11/16/2010 23:12, Adam Stylinski wrote: > I hate to be the guy who gripes on the mailing list about his dinosaur video > card's drivers crashing his system, but it's possible this could be an issue > of a wider scope. When I kldload savage the system hardlocks. Not exactly > sure if it's panicking or not, however I do have a serial port, so maybe I > can setup a serial console and compile the kernel with debugger support to > try and get a backtrace. > > Anybody have any pointers? This should give you enough of an overview of how to obtain and report the information you obtain for debugging kernel problems. http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html The generic kernel configuration for the most part should be enough information to start for most cases and this would at least give you a starting point. Using a GENERIC kernel from a release or a snapshot too would also help to determine if its a problem as part of the project or a configuration mistake you might have made in your custom kernel. -- jhell,v ___ 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: Degraded zpool cannot detach old/bad drive
On 11/16/2010 16:15, Rumen Telbizov wrote: > It seems like *kern.geom.label.gptid.enable: 0 *does not work anymore? I am > pretty sure I was able to hide all the /dev/gptid/* entries with this > sysctl variable before but now it doesn't quite work for me. I could be wrong but I believe that is more of a loader tuneable than a sysctl that should be modified at run-time. Rebooting with this set to 0 will disable showing the /dev/gptid directory. This makes me wonder if those sysctl's should be marked read-only at run-time. Though you could even rm -rf /dev/gptid ;) -- jhell,v ___ 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: Upgrading from 7.3 to 8.1: uname -a still shows 7.3p3
On 11/16/2010 11:21, Dimitry Andric wrote: > On 2010-11-16 01:42, Rainer Duffner wrote: >> I have the 8.1 sources, did a buildworld, buildkernel, installkernel, >> installworld. > > There seems to be a "reboot" missing before installworld...? :) kern.osreldate: 801000 You would not get that sysctl without rebooting on a 7.3 kernel. ;) -- jhell,v ___ 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: Upgrading from 7.3 to 8.1: uname -a still shows 7.3p3
On 11/15/2010 19:42, Rainer Duffner wrote: > Hi, > > I have the 8.1 sources, did a buildworld, buildkernel, installkernel, > installworld. > Now I have 8.1 binaries: > > server# file /bin/tcsh > /bin/tcsh: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked (uses shared libs), for FreeBSD 8.1, stripped > > but not the kernel: > > server# uname -a > FreeBSD server 7.3-RELEASE-p3 FreeBSD 7.3-RELEASE-p3 #3: Tue Nov 16 > 01:12:23 CET 2010 r...@server:/usr/obj/usr/src/sys/GENERIC i386 > > > How is that possible? > > Or is it just a mis-representation? > > kern.osreldate: 801000 > > I did a csup twice and rebuilt the kernel multiple times. > Also did a complete buildworld buildkernel cycle. > For whatever reason it seems that /sys/conf/newvers.sh was never updated when your sources were updated. You should be able to confirm this by looking through that file for '7.3'. If that was not the case then I would believe you have a stale /usr/obj that you should have removed before building kernel and world. If you still have the original obj directory available to you then you should be able to confirm this by looking through a file called vers.c that would also contain the 7.3 string. In any case you should verify that your sources are supposed to be what they are, and one good way to do this is by running (svn status) if you have checked your sources out via svn(1) 'devel/subversion-freebsd' Good luck, -- jhell,v ___ 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.1-STABLE - zpool import problem
On 11/12/2010 14:03, Maciej Friedel wrote: > I have a problem with importing the newly created pool > > # uname -a > FreeBSD backup.wwv.pl 8.1-STABLE FreeBSD 8.1-STABLE #1: Thu Nov 11 > 15:13:25 CET 2010 r...@backup.wwv.pl:/usr/obj/usr/src/sys/BACKUP > i386 > > # dmesg | grep WDC > ad4: 610480MB at ata2-master UDMA100 > SATA 1.5Gb/s > ad6: 610480MB at ata3-master UDMA100 > SATA 1.5Gb/s > ad12: 152627MB at ata6-master UDMA100 > SATA 1.5Gb/s > > # zpool create backupfs ad4 ad6 > # zpool status > pool: backupfs > state: ONLINE > scrub: none requested > config: > > NAMESTATE READ WRITE CKSUM > backupfsONLINE 0 0 0 > ad4 ONLINE 0 0 0 > ad6 ONLINE 0 0 0 > > errors: No known data errors > > pool: basefs > state: ONLINE > scrub: none requested > config: > > NAMESTATE READ WRITE CKSUM > basefs ONLINE 0 0 0 > ad12s2ONLINE 0 0 0 > > errors: No known data errors > > # zfs create backupfs/backup > # df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/label/rootfs496M354M102M78%/ > devfs1.0K1.0K 0B 100%/dev > basefs/home 141G117G 24G83%/home > basefs/usr27G2.8G 24G11%/usr > basefs/var24G255M 24G 1%/var > /dev/md0 496M 46K496M 0%/tmp > backupfs 1.1T 21K1.1T 0%/backupfs > backupfs/backup 1.1T 21K1.1T 0%/backupfs/backup > # mkdir /home/backup > # zfs umount /backupfs/backup > # zfs umount /backupfs > # zfs set mountpoint=/home/backup backupfs/backup > # zfs set mountpoint=none backupfs > # zpool export backupfs > # zpool import backupfs > cannot import 'backupfs': pool is formatted using a newer ZFS version > > # zpool import > pool: backupfs > id: 1262536404400505900 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: > > backupfsONLINE > ad4 ONLINE > ad6 ONLINE > # zfs upgrade > This system is currently running ZFS filesystem version 3. > > All filesystems are formatted with the current version. > # zpool upgrade > This system is currently running ZFS pool version 14. > > All pools are formatted using this version. > > Regards, > Maciej Friedel > One thing to note here is that your running 8.1-STABLE November code which is a zpl version 4 and spa 15 or otherwise known as ZFS v15. Did you build this from source ? or install via snapshot. If you installed via upgrading from source... Is your user-level zfs utilities & libs up-to-date or in sync with your kernel ? -- jhell,v ___ 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-STABLE buildworld failure
On 11/10/2010 00:07, Bryce Edwards wrote: > On Tue, Nov 9, 2010 at 11:04 PM, jhell wrote: >> On 11/09/2010 19:09, Bryce Edwards wrote: >>> After updating source today, I am receiving the following error when >>> running make NOCCACHE=YES -j16 buildkernel >>> >>> >>> ===> zlib (all) >>> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >>> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include >>> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq >>> -finline-limit=8000 --param inline-unit-growth=100 --param >>> large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer >>> -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone >>> -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow >>> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >>> -fstack-protector -std=iso9899:1999 -fstack-protector -Wall >>> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >>> -Wno-pointer-sign -fformat-extensions -c >>> /usr/src/sys/modules/zlib/../../net/zlib.c >>> ld -d -warn-common -r -d -o zlib.ko.debug zlib.o >>> :> export_syms >>> awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | >>> xargs -J% objcopy % zlib.ko.debug >>> objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols >>> objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug >>> zlib.ko >>> 1 error >>> *** Error code 2 >>> 1 error >>> *** Error code 2 >>> >>> Here's make.conf: >>> >>> SUP_UPDATE=yes >>> SUPFILE=/usr/share/examples/cvsup/stable-supfile >>> PORTSSUPFILE=/usr/share/examples/cvsup/ports-supfile >>> SUPHOST=cvsup5.us.freebsd.org >>> >>> #WITHOUT_X11=yes >>> >>> PORTS_MODULES=emulators/virtualbox-ose-kmod >>> >>> # ccache >>> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && >>> !defined(NOCCACHE) >>> #CC=/usr/local/libexec/ccache/world-cc >>> #CXX=/usr/local/libexec/ccache/world-c++ >>> .endif >>> >>> # added by use.perl 2010-11-09 09:32:27 >>> PERL_VERSION=5.10.1 >>> >>> And src.conf: >>> >>> WITHOUT_PROFILE=true# Avoid compiling profiled libraries >> >> This is a log from a buildkernel and not like the subject insists as a >> buildworld. Can you please rebuild world and then try a buildkernel >> >> cd /usr/src >> make -DNOCCACHE -DALWAYS_CHECK_MAKE buildworld >> make -DNOCCACHE -DALWAYS_CHECK_MAKE buildkernel >> make -DNOCCACHE -DALWAYS_CHECK_MAKE installkernel >> >> Reboot & then: >> cd /usr/src >> make -DNOCCACHE installworld >> make -DNOCCACHE delete-old >> make -DNOCCACHE delete-old-libs >> > > My apologies! The subject is wrong and it was during the buildkernel. > The buildworld was done just prior just like your example and > completed OK. The only difference is that I did not define > ALWAYS_CHECK_MAKE. > Also quoting UPDATING: 20101022: A workaround for a fixed ld bug has been removed in kernel code, so make sure that your system ld is built from sources after revision 211583 from 2010-08-21 (r210245 from 2010-07-19 if building stable/8 kernel on head, r211584 from 2010-08-21 for stable/7). A symptom of incorrect ld version is different addresses for set_pcpu section and __start_set_pcpu symbol in kernel and/or modules. >> >> You may also want to adjust that example ccache make.conf example >> sometime too as that will not always do what you expect it to do. >> >> -- >> >> jhell,v >> -- jhell,v ___ 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-STABLE buildworld failure
On 11/09/2010 19:09, Bryce Edwards wrote: > After updating source today, I am receiving the following error when > running make NOCCACHE=YES -j16 buildkernel > > > ===> zlib (all) > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/zlib/../../net/zlib.c > ld -d -warn-common -r -d -o zlib.ko.debug zlib.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | > xargs -J% objcopy % zlib.ko.debug > objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug > zlib.ko > 1 error > *** Error code 2 > 1 error > *** Error code 2 > > Here's make.conf: > > SUP_UPDATE=yes > SUPFILE=/usr/share/examples/cvsup/stable-supfile > PORTSSUPFILE=/usr/share/examples/cvsup/ports-supfile > SUPHOST=cvsup5.us.freebsd.org > > #WITHOUT_X11=yes > > PORTS_MODULES=emulators/virtualbox-ose-kmod > > # ccache > .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && > !defined(NOCCACHE) > #CC=/usr/local/libexec/ccache/world-cc > #CXX=/usr/local/libexec/ccache/world-c++ > .endif > > # added by use.perl 2010-11-09 09:32:27 > PERL_VERSION=5.10.1 > > And src.conf: > > WITHOUT_PROFILE=true# Avoid compiling profiled libraries This is a log from a buildkernel and not like the subject insists as a buildworld. Can you please rebuild world and then try a buildkernel cd /usr/src make -DNOCCACHE -DALWAYS_CHECK_MAKE buildworld make -DNOCCACHE -DALWAYS_CHECK_MAKE buildkernel make -DNOCCACHE -DALWAYS_CHECK_MAKE installkernel Reboot & then: cd /usr/src make -DNOCCACHE installworld make -DNOCCACHE delete-old make -DNOCCACHE delete-old-libs You may also want to adjust that example ccache make.conf example sometime too as that will not always do what you expect it to do. -- jhell,v ___ 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: Degraded zpool cannot detach old/bad drive
On 10/31/2010 15:53, Rumen Telbizov wrote: > Hi Artem, everyone, > > Here's the latest update on my case. > I did upgrade the system to the latest stable: 8.1-STABLE FreeBSD 8.1-STABLE > #0: Sun Oct 31 11:44:06 PDT 2010 > After that I did zpool upgrade and zfs upgrade -r all the filesystems. > Currently I am running zpool 15 and zfs 4. > Everything went fine with the upgrade but unfortunately my problem still > persists. There's no difference in this aspect. > I still have mfid devices. I also tried chmod-ing as you suggested /dev/mfid > devices but zfs/zpool didn't seem to care and imported > the array regardless. > > So at this point since no one else seems to have any ideas and we seem to be > stuck I am almost ready to declare defeat on this one. > Although the pool is usable I couldn't bring it back to exactly the same > state as it was before the disk replacements took place. > Disappointing indeed, although not a complete show stopper. > > I still think that if there's a way to edit the cache file and change the > devices that might do the trick. > > Thanks for all the help, > Rumen Telbizov > > > On Fri, Oct 29, 2010 at 5:01 PM, Artem Belevich wrote: > >> On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov >> wrote: >>> FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 >>> That's when I csuped and rebuilt world/kernel. >> >> There were a lot of ZFS-related MFCs since then. I'd suggest updating >> to the most recent -stable and try again. >> >> I've got another idea that may or may not work. Assuming that GPT >> labels disappear because zpool opens one of the /dev/mfid* devices, >> you can try to do "chmod a-rw /dev/mfid*" on them and then try >> importing the pool again. >> >> --Artem >> > > > The problem seems to be that its just finding the actual disk before it finds the GPT labels. You should be able to export the pool and then re-import the pool after hiding the disks that it is finding via /etc/devfs.rules file. Try adding something like (WARNING: This will hide all devices mfi) adjust accordingly: add path 'mfi*' hide To your devfs ruleset before re-importing the pool and that should make ZFS go wondering around /dev enough to find the appropriate GPT label for the disk it is trying to locate. It would seem to me that using '-d' in this case would not be effective as ZFS would be looking for 'gpt/LABEL' within /dev/gpt/ if memory serves correctly, and obviously path /dev/gpt/gpt/ would not exist. Also even if it did find the correct gpt label then it would be assuming its at a /dev path and not /dev/gpt/* and would fall back to finding the mfi devices after the next boot again. -- jhell,v ___ 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: POSIX file permission (understanding) problem?
On 10/29/2010 23:27, jhell wrote: > On 10/25/2010 18:28, Chuck Swiger wrote: >> chmod g+w testdir/ (as superuser, exit again) >>> >> >> ls -ld testdir >>> >> >> drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir >>> ls -l testdir >>> total 0 >>> -rw-r- 1 nobody intern 0 25 Okt 23:03 testfile >> >>> -> Now editing with vi (as user harry) changes the ownership of the >>> file and writing is successfull: >>> ls -l testdir/ >>> total 2 >>> -rw-r- 1 harry intern 5 25 Okt 23:10 testfile >> >> A file in a sticky directory may only be removed or renamed >> by a user if the user has write permission for the directory and the >> user >> is the owner of the file, the owner of the directory, or the super-user. > > > Obviously he is not the owner of the file, directory, nor the superuser > in this case so if I am missing something here please forgive me but I > still see a big problem with this > Never mind... forhot the chmod g+w. -- jhell,v ___ 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: POSIX file permission (understanding) problem?
On 10/25/2010 18:28, Chuck Swiger wrote: > chmod g+w testdir/ (as superuser, exit again) >> > > ls -ld testdir >> > > drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir >> ls -l testdir >> total 0 >> -rw-r- 1 nobody intern 0 25 Okt 23:03 testfile > >> -> Now editing with vi (as user harry) changes the ownership of the >> file and writing is successfull: >> ls -l testdir/ >> total 2 >> -rw-r- 1 harry intern 5 25 Okt 23:10 testfile > > A file in a sticky directory may only be removed or renamed > by a user if the user has write permission for the directory and the user > is the owner of the file, the owner of the directory, or the super-user. Obviously he is not the owner of the file, directory, nor the superuser in this case so if I am missing something here please forgive me but I still see a big problem with this -- jhell,v ___ 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: ZFS write speed
On 10/28/2010 03:30, S.N.Grigoriev wrote: > > > 28.10.10, 01:54, "Stefan Bethke" : > >> Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: >> >> > Hi list, >> > >> > I've got very low write speed using ZFS on a SATA disk. >> > My HDD configuration is: >> > ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s >> > ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s >> > ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s >> >> The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual >> outcome, but there was a long thread on stable or hackers on how to ensure >> proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't >> have to do a read-modify-write cycle, so try and search the archives. Though this might play a small part in your write performance with the EARS drives, this issue has more to do with the stat() calls and the ACL involvement with ZFS. This was sort of solved in 8.1-STABLE and from 3 cases that I know about and 1 being my own... write/read speeds have doubled from what can be seen to an effect of 8.1-RELEASE. You may want to either upgrade to stable/8 or use one of the snapshots from here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201010/ > > Stefan, > > thank you for your response. I'll try to find the topic you pointed. > >> > ad4 and ad6 are single-slice disks (UFS2 with soft updates) >> > >> > ZFS configuration is following: >> > zpool create Z ad8 >> > zfs create Z/music >> > zfs create Z/video >> > All ZFS parameters are default. >> > kern.maxvnodes = 100 >> > >> > To test my configuration I recursively copied from ad6 to ad8 two >> directories. >> > The first one contains MP3 files (average size = 10MB). >> > The second one contains AVI files (average size = 1GB). >> > >> > To compare performance I repeated above tests with ad8 using UFS2 with >> soft updates. >> > >> > 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to >> ZFS. >> > 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to >> ZFS. >> > >> > I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. >> > >> > Any tips? >> > >> > -- > -- jhell,v ___ 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: Web feeds for UPDATING files
On 09/25/2010 09:24, Alexander Kojevnikov wrote: > On 25 September 2010 17:04, Alexander Kojevnikov > wrote: >> On 25 September 2010 15:44, jhell wrote: >>> Really awesome! >>> >>> This will come in handy to serve up stable/*/UPDATING and head/UPDATING >>> to. And thinking along those lines it could probably be incorporated >>> directly into the DAV tree on svn. to serve directly from there. >> >> Great idea, I'll try to implement both feeds during the weekend and >> will post here and on freebsd-current@ and freebsd-stable@ when it's >> done. > > ...and done: > > http://updating.versia.com/ > > The site now features Atom feeds for the following files: > > * ports/UPDATING > * head/UPDATING > * stable/7/UPDATING > * stable/8/UPDATING > > Hope you find the feeds useful. > > Cheers, > Alex > > PS: I apologise to ports/UPDATING subscribers who got quite a few > duplicate entries. I barely missed the Ballmer Peak, just delete > those. Your amazing! Thanks Alexander! -- jhell,v ___ 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: FreeBSD 8.1 Stable Unreasanoble Rebooting
On 09/23/2010 14:38, jhell wrote:
> On 09/16/2010 15:33, Michael BlackHeart wrote:
>> 2010/9/16 Jeremy Chadwick :
>>> On Thu, Sep 16, 2010 at 08:37:29PM +0400, Michael BlackHeart wrote:
>>>> Today I've got a pretty strange event. It looks like a reboot but
>>>> unreasonable as far as I see. Before server's uptime was over month,
>>>> it's sometimes have to reboot for kernel updates or somethings like
>>>> that. I've digen all logs and didn't find a reason, so here they all.
>>>>
>>>> auth.log
>>>> Sep 16 13:59:58 diablo sshd[2284]: Received signal 15; terminating.
>>>> Sep 16 14:04:26 diablo sshd[2290]: Server listening on 0.0.0.0 port 22442.
>>>>
>>>> cron - nothing
>>>> debug.log - nothing
>>>> dmesg - nothing
>>>>
>>>> messages
>>>> Sep 16 13:44:55 diablo transmission-daemon[7965]: Couldn't create
>>>> socket: Protocol not supported (fdlimit.c:651)
>>>> Sep 16 13:45:31 diablo last message repeated 5 times
>>>> Sep 16 13:47:23 diablo last message repeated 13 times
>>>> Sep 16 13:57:40 diablo last message repeated 51 times
>>>> Sep 16 13:59:48 diablo last message repeated 12 times
>>>> Sep 16 14:00:18 diablo named[1575]: stopping command channel on
>>>> 127.0.0.1#953
>>>> Sep 16 14:00:18 diablo named[1575]: exiting
>>>> Sep 16 14:00:18 diablo syslogd: exiting on signal 15
>>>> Sep 16 14:02:31 diablo syslogd: kernel boot file is /boot/kernel/kernel
>>>> Sep 16 14:02:31 diablo kernel: Copyright (c) 1992-2010 The FreeBSD Project.
>>>> {...}
>>>
>>> This sure looks like a legitimate reboot to me (e.g. shutdown -r now);
>>> note how your system daemons (named, syslogd) are being shut down with
>>> SIGTERM. You can check with "last" (shutdown/reboot vs. crash).
>>>
>>>
>>> I would highly recommend taking this machine offline and reinstalling
>>> the OS, in addition to newfs'ing all existing filesystems (restore from
>>> last known good backup). buildworld/installworld and
>>> buildkernel/installkernel may not be enough depending on what the
>>> individual did. It's likely the machine could be compromised in some
>>> way, especially if there's any service on it which is public-facing,
>>> regardless of authentication mechanisms you've deployed in front of it.
>>>
>>>
>>> --
>>> | Jeremy Chadwick j...@parodius.com |
>>> | Parodius Networking http://www.parodius.com/ |
>>> | UNIX Systems Administrator Mountain View, CA, USA |
>>> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>>>
>>>
>
>> That looks reasonable
>> last says:
>> reboot ~ th 16 sen 14:04
>> reboot ~ th 16 sen 14:03
>> shutdown ~ th 16 sen 13:59
>
>> and it's pretty good syncs with logs but there's no anybody access to
>> physical console 'cos it's not even plugged in. That's for the first.
>> Next, I've got, I believe, pretty strong passwords, and also root
>> can't log in directly, but wheel user also is in operators so he also
>> can reboot or shutdown, but there's no any attempts or successful
>> logins. All potentialy dangerous services run under their own
>> unprerileged users, and so on. Crontabs also doesn't contain scripts,
>> I prefer periodic system, and there's no anyway anything that cause
>> reboot.
>> Thing that worries me it that there were multiple reboots and shutdown
>> that goes up by itself without anyone pressing a button. And in
>> messages log there's fsck segment that indicates to unnormal shutdown
>> or reboot. It looks like it started to shutting down but was in some
>> case interrupted and after powering up it few times reboots itself.
>> But commonly FreeBSD doesn't reboot by it's own will.
>> The same hardware worked over a half a year under 8.0 stables without
>> such a problem. I just would like to understand from where this
>> problem comes up.
>> This machine doesn't contain any critical info so I'll wait for a bit.
>> Also I'd like to notice that recently I've tuned hdd's spindown exept
>> system hdd by atacontrol port, powerd and CPU frequency lowering in
>> idle, may
Re: FreeBSD 8.1 Stable Unreasanoble Rebooting
lant a shutdown/reboot command in any one of the above matching files and have it run by at(1). This really sounds like the case here. 1). Check the above files. egrep -nr "(shutdown|reboot)" on those. 2). Inspect the files for at(1) reboot(8) shutdown(8) or paths to unintelligible binaries that have been setuid=0(u+s) owner=root. 3). Keep in mind a rogue staffer may have well cp(1) shutdown(8) to another command or created a script containing shutdown(8) to another command that matches another system command or has replaced one. Thats just a few things to go on for now. Others may have more to add to it. Regards & Good luck, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJMm56rAAoJEJBXh4mJ2FR+P8wH/RyMxZSsQGKODwtWNNipeUSZ iMA+n7ub3GStz1k7hfQQfsWqdWtfrO73Nrw6Af5vnGWdLGjatwD36qOmcLqfg1tE ZBc7QGFYyFkqHxL2Dor58Q6XV2GxS1zEGyT5Rf2mNGqMOyaTVdBpIlfX02mUdpX3 0KDRdNivEXK/A8sGSK0WN46E7+uSO7L7n4zfv3fEFmsZh9VhtRwf558MJxO39UgN FsLKQRy0DVPMAnb9zr6dWvRtAVpnCgQhlLdspETN7SFamO4CAs/8ZiasPaNzG/jl G3avQZhhT1Ws/DpDBdYwj5nOpkTU2Y90PUoLXktGjg90tNvOaWfboAhA80tzyWA= =hDLt -END PGP SIGNATURE- ___ 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: HEADS UP: instability on stable/8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2010 13:23, Rui Paulo wrote: > Hi, While I'm merging the userland DTrace bits to stable/8 you might > experience some instability if you use DTrace. If you use DTrace, I > suggest you don't try to upgrade during the next 5 days. > > Thanks for your patience, -- Rui Paulo > Thank you Rui this is much appreciated. If there is a specific version when you start those commits could that be noted as well on this thread ? Thanks again, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJMmrD7AAoJEJBXh4mJ2FR+cjgH/jbe3+JPdRJvsrD3oU31PMUb yZJgzzLGh2EDCdx7ADkOD/P/Bm4jWS0vxEFtzNH/rq7tSgcGYpLi0Btre/wE16BY WJQEssJUerwJ2qNMNnfLAZySJLxC2Bz3HXwvLsxOwhRRNDAWj+Mstzqakd5F+V0W kQvvHWmDfGYmWoloE6K++cj+Q8YjHVz6qHqf2vcmGCerAmvBE9/5xOfJqAGsZKoR aH//luRPH1GUroUMl6hi+59NtSDaONokAR2Ot0FT4G3jDRbetngkJAyrXIMSmNdl JBeAx2yY+P+v9pyl3Wir5FhH08wxJgJBeIy+n4W8z/fYyFcUmGC7sOiKyFABprE= =YFQU -END PGP SIGNATURE- ___ 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: Panic with chromium and 8.1-STABLE (Thu Sep 16 09:52:17 BRT 2010)
On 09/22/2010 16:37, Kostik Belousov wrote: > On Wed, Sep 22, 2010 at 03:58:12PM -0400, jhell wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 09/22/2010 09:28, Kostik Belousov wrote: >>> On Sun, Sep 19, 2010 at 07:28:13PM -0300, Mario Sergio Fujikawa Ferreira >>> wrote: >>>> Hi, >>>> >>>>I've just began trying chrome web browser from >>>> http://chromium.hybridsource.org/ but it triggered 2 panics on my >>>> 8.1-STABLE system. >>>> >>>> $ uname -a >>>> FreeBSD exxodus.fedaykin.here 8.1-STABLE FreeBSD 8.1-STABLE #26: Thu Sep >>>> 16 09:52:17 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 >>>> >>>>The panic information is: >>>> >>>> >>>> panic: vm_page_unwire: invalid wire count: 0 >>>> cpuid = 0 >>>> KDB: enter: panic >>>> >>>> 0xff006ecce000: tag ufs, type VREG >>>> usecount 1, writecount 1, refcount 4 mountedhere 0 >>>> flags () >>>> v_object 0xff0151489870 ref 0 pages 8 >>>> lock type ufs: EXCL by thread 0xff00200947c0 (pid 25025) >>>> ino 119526591, on dev ufs/fsusr >>>> >>>> 0xff011107f938: tag ufs, type VREG >>>> usecount 0, writecount 0, refcount 4 mountedhere 0 >>>> flags (VV_NOSYNC|VI_DOINGINACT) >>>> v_object 0xff0151f7f870 ref 0 pages 1284 >>>> lock type ufs: EXCL by thread 0xff01882cc7c0 (pid 26689) >>>> ino 263, on dev md0 >>>> >>>> >>>>I've made available 2 ddb textdumps at: >>>> >>>> http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.0 >>>> http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.1 >>>> >>>>I was able to use chrome prior to this latest kernel update. >>>> Now, I can reproduce a kernel panic even browsing www.google.com >>>> >>>>Please, let me know if I can provide any further information. >>> >>> Does it panic if you remove ZERO_COPY_SOCKETS option from the kernel >>> config ? >> >> This is triggered as well on a system without ZERO_COPY_SOCKETS just to >> clear that bit up. > I do not know what did prompted you to decide that the issue is the same. > There is nothing common except the word "panic" in the report by > lioux and your backtraces. > > You could have better luck showing your traces on the fs@ or asking zfs > porters directly. Well taking a stab at it I thought you were involved with that. Considering it is being triggered on the FS level there is somthing in common but that won't always mean the traces will be exact for two different file-systems. It may just as well be two different cases so Ill just forward them on to the correct people. Thanks anyway. Regards, -- jhell,v ___ 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: Panic with chromium and 8.1-STABLE (Thu Sep 16 09:52:17 BRT 2010)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2010 09:28, Kostik Belousov wrote: > On Sun, Sep 19, 2010 at 07:28:13PM -0300, Mario Sergio Fujikawa Ferreira > wrote: >> Hi, >> >> I've just began trying chrome web browser from >> http://chromium.hybridsource.org/ but it triggered 2 panics on my >> 8.1-STABLE system. >> >> $ uname -a >> FreeBSD exxodus.fedaykin.here 8.1-STABLE FreeBSD 8.1-STABLE #26: Thu Sep 16 >> 09:52:17 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 >> >> The panic information is: >> >> >> panic: vm_page_unwire: invalid wire count: 0 >> cpuid = 0 >> KDB: enter: panic >> >> 0xff006ecce000: tag ufs, type VREG >> usecount 1, writecount 1, refcount 4 mountedhere 0 >> flags () >> v_object 0xff0151489870 ref 0 pages 8 >> lock type ufs: EXCL by thread 0xff00200947c0 (pid 25025) >> ino 119526591, on dev ufs/fsusr >> >> 0xff011107f938: tag ufs, type VREG >> usecount 0, writecount 0, refcount 4 mountedhere 0 >> flags (VV_NOSYNC|VI_DOINGINACT) >> v_object 0xff0151f7f870 ref 0 pages 1284 >> lock type ufs: EXCL by thread 0xff01882cc7c0 (pid 26689) >> ino 263, on dev md0 >> >> >> I've made available 2 ddb textdumps at: >> >> http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.0 >> http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.1 >> >> I was able to use chrome prior to this latest kernel update. >> Now, I can reproduce a kernel panic even browsing www.google.com >> >> Please, let me know if I can provide any further information. > > Does it panic if you remove ZERO_COPY_SOCKETS option from the kernel > config ? This is triggered as well on a system without ZERO_COPY_SOCKETS just to clear that bit up. Kostik, I am going to forward you two core.txt.NN files I had generated on a ZFS system that I used chrome on as well. I can trigger this repeatedly from 20-30 minutes of using chrome. Not sure whats going on here but maybe you can shed some light over both issues that seem to be the same thing. I do not mind if you forward these core.txt.NN files to other devs that may be interested and able to help. I still have the kernels for both of these so if more information is needed just let me know. Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJMml/UAAoJEJBXh4mJ2FR+EkIH/j9lfSg1ZTMtn4vRgybvd+3F 0Sy88IgvltQmIicEaQ4MbQ9IpO/owsc362UexQvnbx38zVLRivfJYsDefAmG6Dex OVRuewzJzgr3YWv89t4OxZgWNcsyTFVZCLavCuGiUzbw52m83klc3Fubr0+wXI1G OtIEsaIFqaGHvgVSvGKlHLiv2/Q93bZ1kWCCHdHM3l4QIPG9ARuRR08bOVDQK0Xd GhMUVXfvV7fOF1cwzecQ5+AP4UDaExA3JRrkYf7IC8KkFgATbdA3RLbxypkkOf75 XVqBFmqjAQfIPc8vUvVd9WmC1tNfqJzJPQ3kl3B3HHs2K3g/BoZpeaUEGacXJ8o= =FyGm -END PGP SIGNATURE- ___ 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: MFC of ZFSv15
On 09/16/2010 09:55, Mike Tancsa wrote: > > Thanks again for all the ZFS fixes and enhancements! Are there any > caveats to upgrading ? > > Do I just do > > zpool upgrade -a > zfs upgrade -a > > or are there any extra steps ? > Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. Regards, UPDATING should have anything else. -- jhell,v ___ 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"
/stable/2.0.5/usr.bin/m4/serv.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Stable@, Repo Men & Women, I was recently creating a replicate of the central svn repo onto another server and came across the following. While svnsync(1) sync file:///path/to/repo svnsync: File not found: revision 8869, path '/stable/2.0.5/usr.bin/m4/serv.c' As per the ncvs repo. This file was moved into Attic ??1.1.1.2?? thus I believe this caused conflicts with cvs2svn. If further information is needed you can contact me directly off-list. Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJMkWXaAAoJEJBXh4mJ2FR+m4EH/jG78h3WEhfgCWA3imN6X5ii lMQL4c+c5Wvcjd3ocZVLv/fxiJTs/0tT41pM+LuCe+HEeEhkwx9Op3xeg5q37dbo tdCFNOx009gMOEUbMgir5n21zrQ7UwxgQ0mn0u7LEvHNs1VTnfIMDxbHqqbel7CX 509UReU/e+imJSdNQYQZqVSGQONh+q+EzzlTwCuT7/jqlhnE1te/SC3FKs3XVCEE uZZEwa6+fPHVvaS+eThsVzlK35EBpfYGxcdLbBetYUgs2FOG3plq5Ot86yg5LFKy zsQV0UkAEMMsPg2VQuA7FPz9IqKA3XJi60yQ9QXMqFcytW/jOh2Mx5tLi6z3yvI= =BFDQ -END PGP SIGNATURE- ___ 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: Policy for removing working code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2010 14:24, Doug Barton wrote: > On 9/10/2010 2:20 AM, Julian H. Stacey wrote: >> One option could be a new list > > Just send these notices to -announce. The removal of stuff like this > doesn't happen often, and as long as we're careful with the frequency > and content of the messages I can't imagine people would complain too much. > I agree with Doug on this. No need to add another layer of complexity to the already existing lists. Just use them properly. Besides wouldn't it make sense to publish the top three or five recent posts to announce@ to a reserved space on the CMS rather than relying on consumers to subscribe to the list at all. I know errata notices get announced I would think a heads up around the board about big changes like removing portions of code completely should be announced as well. FreeBSD-CA-??? "Change Announcement?" for that are constructed much of the same way the SA & EN are ?. Just some thoughts, Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMjEhMAAoJEJBXh4mJ2FR+7tEH/3IazQgUv/JubsuzKLVnCLER oYg1Ws/dvWPC0Tdizm7QIqp+WvFYGz/c9Udihl8jAMW5CVLkNSba/THcpcVbp4hY utHhC88EsPZjgKjGnCpbfOar2cZoBL1nPv16+pL2Ur+NjU9s+PAY31SmFJ6I3fq4 yTMjU+/fsjalBClZYzy90/f0E8jj45la66VrZhEAgMPEWYdIRY1akAOAiZxx9vhM 1M/l9uLuanGhS+4rkM9Tz7ZrCmfLmzV6K3OhEWagTJPbK8DH1WPKk41HhHiW+ef1 p7YDuQYi+CCFg9QB/erhXDXJT5BBOctXOTN4UdNkfC78g5vV+7FZa3CWsSzstss= =L7sZ -END PGP SIGNATURE- ___ 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: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)
On 09/08/2010 06:44, Vadim Goncharov wrote: > Hi Mark Linimon! > > On Wed, 8 Sep 2010 07:30:19 +; Mark Linimon wrote about 'Re: HEADS UP: > FreeBSD 6.4 and 8.0 EoLs coming soon': > >>>> The reason is performance for overall network stack, not ideology. > >>> For a practical reasons, "it works but slow" is better than >>> "doesn't work at all (due to absence of code in the src tree)". >>> "Make it work. Make it right. Make it fast. In that order", know this? >>> Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is >>> it?.. >> >> It wasn't "it works but slow". It was "it works, but networking throughput >> is limited on the modern hardware that the majority of our users employ". >> In particular, IIUC, 10GB network drivers were suffering under the old >> strategy. We simply were not competitive with other OSes, and we have >> many multiples more users interested in 10GBE than in ISDN. > > I understand that we need to support modern fast hardware but that doesn't > mean > we should drop working features for that. And... > >>> You do not understand the problem. It is not in notices & volunteers, but >>> rather in the Project's policy - delete something which could still work. >> >> You do not understand how this was handled. > > ...and how this is handled in other OSes to which we have compete, er? They > all > also do dropping features to frighten away old users? Are there no alternative > ways to handle? Put network Giant code into bunch of #ifdef's, after all. > >> The situation was: an announcement was made that "in X months, all network >> drivers need to be made to run Giant-free so that FreeBSD can drop Giant >> from the neworking stack to move forward." Within that period, most of >> the drivers were updated. Repeated postings were made to the mailing list >> that "the following drivers still have not been converted, and need to be >> updated or they will be dropped." They weren't; they were droppped. > > No. See my answer to vwe@ that there were no proper announcements. With them, > for example, someone could get sponsored to update these drivers which were > needed by those FreeBSD users who can't maintain code themselves. That's a > last > resort, more likely volunteers will come, but you get the idea. > >> So while it could "still" work, it was slowing down progress. > > If it is not ideology, then what is it?.. > >> The fact of the matter is, FreeBSD is a big project with a finite number >> of developers. We try to keep as much coverage of systems as we can, but >> a reality of any large software engineering project is that older features >> sometimes have to be dropped to make progress. > >>From time to time such critical cases could possibly be handled by another > ways, I've mentioned one possible above. > >> The code still exists in the repository for any interested party to pick >> up and modernize. > > I hope that for this particular case alternative from ports will be enough. > But policy is not tied to one particular case, alas. > Would you please stop provoking a situation for which you are no more involved in other than running FreeBSD. Thank you. PS: The website in your signature is broke. This should give you enough to do for a while. -- jhell,v ___ 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: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
On 09/03/2010 20:14, David Xu wrote: > jan.gr...@bristol.ac.uk wrote: >> On Thu, 2 Sep 2010, Andriy Gapon wrote: >> >> >>> on 02/09/2010 12:08 jan.gr...@bristol.ac.uk said the following: >>> >>>> On Wed, 1 Sep 2010, Ivan Voras wrote: >>>> >>>> >>>>> On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: >>>>> >>>>>> I'm running -STABLE with a kde-derived desktop. This setup >>>>>> (which is pretty standard) is providing abysmal interactive >>>>>> performance on an eight-core machine whenever I try to do >>>>>> anything CPU-intensive (such as building a port). >>>>>> >>>>>> Basically, trying to build anything from ports rapidly >>>>>> renders everything else so "non-interactive" in the eyes of >>>>>> the scheduler that, for instance, switching between virtual >>>>>> desktops (I have six of them in reasonably frequent use) >>>>>> takes about a minute of painful waiting on redraws to >>>>>> complete. >>>>>> >>>>> Are you sure this is about the scheduler or maybe bad X11 >>>>> drivers? >>>>> >>>> Not 100%, but mostly convinced; I've just started looking at >>>> this. It's my first stab at what might be going on. X11 >>>> performance is usually pretty snappy. There's no paging >>>> pressure at all. >>>> >>> From my experience: 1. system with Athlon II X2 250 CPU and >>> onboard AMD graphics - no issues with interaction between >>> buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. >>> system with comparable Core2 Duo CPU and onboard Intel graphics >>> (G33) - enabling OpenGL desktop effects in KDE4 leads to the >>> consequences like what you describe. With all GUI bells and >>> whistles disabled the system behaves quite like the AMD system. >>> >> >> All desktop effects are disabled. The graphics are from an nVidia >> GeForce 8500 GT (G86) with the X.org driver. (It's not _just_ >> desktop behaviour that's affected, though: the box runs a number of >> small headless [interactive] server processes which also appear to >> get rapidly starved of CPU time.) >> >> The behaviour isn't visible with the 4bsd scheduler; "stuff" >> generally remains snappy and responsive. >> >> I'll keep poking around and see if I can get to the bottom of it. >> >> >> >> > I think sysctl kern.sched.preempt_thresh is too low, default is only > 64. I always tune it up to 200 on my desktop machine which is > running gnome and other GUI applications, for a heavy GUI deskkop, I > would tune it up to 224 to get better result. > For reference how did you arrive at 224 for a result ? -- jhell,v ___ 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"
Labor day Tinderbox/csup(1) Vacation. bad route.
On 09/05/2010 06:17, FreeBSD Tinderbox wrote: > TB --- 2010-09-05 09:42:58 - tinderbox 2.6 running on > freebsd-current.sentex.ca > TB --- 2010-09-05 09:42:58 - starting RELENG_8_0 tinderbox run for i386/i386 > TB --- 2010-09-05 09:42:58 - cleaning the object tree > TB --- 2010-09-05 09:43:27 - cvsupping the source tree > TB --- 2010-09-05 09:43:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca > /tinderbox/RELENG_8_0/i386/i386/supfile > TB --- 2010-09-05 10:17:56 - WARNING: /usr/bin/csup returned exit code 1 > TB --- 2010-09-05 10:17:56 - ERROR: unable to cvsup the source tree > TB --- 2010-09-05 10:17:56 - 0.84 user 17.45 system 2097.45 real > > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full It's not Labor day in the U.S. yet!... ;) BACK TO WORK! -- jhell,v ___ 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: csup in repomirror mode dumps core @ stable/8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/02/2010 02:16, Jeremy Chadwick wrote:
> On Thu, Sep 02, 2010 at 07:56:31AM +0200, John Hay wrote:
>> On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote:
>>> Dear colleagues,
>>>
>>> some 2 days ago my repo mirror (stable/8...@amd64) starts dumping
>>> core on copying repo:
>>>
>>> ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v
>>> Segmentation fault (core dumped)
>>>
>>> deleting files from sup/cvsroot-all/ did not help
>>>
>>> unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in
>>> /usr/src/usr.bin/csup does not work, and I did not dig into this
>>> deeply yet, so trace are without parameters:
>
> This won't work. You need to do: make DEBUG_FLAGS="-g3 -ggdb -O0"
>
> The important part is not using -D. make.conf variables aren't
> exported into the compiler environment (I'm not phrasing this
> eloquently because I don't know how to describe it). The rest of the
> gcc arguments I provided are highly recommended (especially -O0,
> otherwise you probably won't get access to any variable data).
>
> I can confirm this works, by the way. Look closely at the cc line
> (past the initial -O2 -pipe -march=nocona).
>
> cc -O2 -pipe -march=nocona -I.
> -I/usr/src/usr.bin/csup/../../contrib/csup -DHAVE_FFLAGS -DNDEBUG
> -ggdb -g3 -O0 -std=gnu99 -fstack-protector -Wsystem-headers -Werror
> -Wno-pointer-sign -c
> /usr/src/usr.bin/csup/../../contrib/csup/updater.c
>
Not being picky but just wanted to let you know that the flags specified
to DEBUG_FLAGS that you have listed above are perfectly fine but for
those without the knowledge of how this is done, the last flag specified
is usually the flag that wins.
So for DEBUG_FLAGS="-g3 -ggdb -O0" the -ggdb flag would be the debugging
type of ELF binary produced making the '-g3' flag just redundant.
Now in case you wanted the effect of '-g3' and '-ggdb' you can specify
'-ggdb3' instead.
As for the compile that was listed above it seems as if the flags were
reorganized in some way leading to '-g3' ultimately taking the cake.
Irregardless you will still end up with a binary that can be debugged by
gdb(1)/kgdb(1) either way.
Attached is a script that I use after buildworld installworld to rebuild
libthr and libc that is helpful for debugging that you may or may not
find useful.
Regards,
- --
jhell,v
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMg2/VAAoJEJBXh4mJ2FR+0k4H/RhffEPOsykY777HLm+PgSxF
EGmXHGDO/E3q3SRwcq062wLqa3r6sEcFh3claXamNRyCCsMvzvOEo/id77GA9lGe
SMlJGjsI8WyA0ZZl9SonsFN9bU4KFS2OfCzXBpUHbdDBZ0huaLlJNOq41HBxv55B
MSqTxfOXWUANZ2zzDiuKwdtY+MwiXwEwj8nJV0SAryGjcwEZoC/34nZfHCF2Y/uU
sKVhrZmzg/jbXxVtDuFfJ5uhk9UoLRWeAf0huUpfZJ6k7FtzjL4pP/EEMPyJhGtK
fVNYiOuQr9ZAErRg27LDgfT/fKwffbONeYQ9Q0osV44GYcateO5RhBdA7UEEAxE=
=fmjo
-END PGP SIGNATURE-
#! /bin/sh
LIBDIR="/usr/src/lib"
DBGLIBS="libc libthr"
DBGFLAGS="-g3 -O0"
TARGETS="obj depend includes"
NUMCPUS=$((($(sysctl -n kern.smp.cpus)*2)+(10)))
for dbglib in $DBGLIBS; do
for target in $TARGETS; do
make -C $LIBDIR/$dbglib $target DEBUG_FLAGS="${DBGFLAGS}"
done
nice make -C $LIBDIR/$dbglib DEBUG_FLAGS="${DBGFLAGS}" &&
make -C $LIBDIR/$dbglib install DEBUG_FLAGS="${DBGFLAGS}"
done
builddbglibs.sh.sig
Description: Binary data
___
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: Extending your zfs pool with multiple devices
On 09/03/2010 04:25, Michal wrote: > What is really odd is I see your replies but not my original post, how > very strange?? > > Thank you for all of your assistance. I would like to move to being able > to build a cheap san-like storage area for a DB, I don't know how well > it would work but I'd like to try it anyway since things like HP MSA's > are hugely expensive. > > I like these suggestions of filling a second box and connecting this to > the 1st box using these expanders and port replicators. I don't really > need as fast as I can get as this is not a high-use DB backend or many > user file server. A few users here and there but nothing that worries me > about the bottleneck caused by these replicators. This way is ALOT > better then my system of trying to export iscsi disks or something like > that. This way I can add create a second box then have a cable into an > expander or replicator on the 1st box, a 3rd box could then be added to > the expander/replicator at a later date. There is a limit on how far > this could go realistically, but I like this way. I could go further by > adding SSD's for the L2ARC and ZIL if I wanted to. I found zfsbuild.com > to be a quite nice site/blog > Thanks for the link: zfsbuild.com I'm going to check that out. Anyway... not that this is a great solution but if it is windows clients that are connecting to this that your worried about and would like to split off storage to separate machines etc... you can use DFS with Samba. Imagine building two more machines and having them be completely transparent to the clients that connect to the main server. Using a Samba DFS server would allow you to distribute out the file-systems to different shares on different machines without the client ever having to know that the actual location that the directory lays on is another machine and allows you to easily migrate new servers into the network without client ever seeing the change. Implement ISCSI, ZFS & HAST into this mix and you have yourself one hell of a network. Just an idea, Regards, -- jhell,v ___ 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: About zfs + nfs stability
On 08/31/2010 09:21, Giulio Ferro wrote:
> 1) Is it a good idea to upgrade this production system to the latest 8
> stable (8.1 stable I believe)? Is it really stable?
For this question alone, I can verify that it is stable to upgrade to
the stable branch. Though on one hand it might be reasonable for you to
locally merge changes from the two points of CDDL into your source tree.
Example: (Tested here)
cd /usr/src
svn merge svn://svn.freebsd.org/base/stable/8/cddl cddl
svn merge svn://svn.freebsd.org/base/stable/8/sys/cddl sys/cddl
If you do not have any local changes to your source tree for those parts
of the branch then you should not have any problems or conflicts upon
merge & this will bring your system up-to-date with ZFSv14 in stable/8.
Another route if you use CVS would be to checkout the source tree using
Subversion and diff it locally but you should still end up with the same
result.
There are a few patches that I can recommend but they are for stable/8
that has been patched with ZFSv15 that is due to be committed some time
in September - November. Patches and descriptions below. And attached is
a UMA patch for the VFS subsystem that helps a little with performance
but not near as much as the patches below.
http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch
http://people.freebsd.org/~mm/patches/zfs/zfs_metaslab.patch
http://people.freebsd.org/~mm/patches/zfs/zfs_abe_stat_rrwlock.patch
And for the better performance question by upgrading... that is a real
hard question to answer not knowing your hardware implementation. There
really has not been that much of a performance increase that I can
account for regarding stable/8 vs. releng/8.1, or at least not yet.
PS: I have done minimal testing for V4: /nfs either my understanding of
it or the way it is setup to work is somewhat confusing but this is only
with very little knowledge of NFSv4 so please only take this as opinion
but I would not upgrade a production system to use V4: /nfs quite yet
unless the need demands it.
Regards & Good Luck,
--
jhell,v
diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c
index 2dcd14f..ed07ecb 100644
--- a/sys/vm/uma_core.c
+++ b/sys/vm/uma_core.c
@@ -2727,14 +2727,26 @@ zone_free_item(uma_zone_t zone, void *item, void *udata,
}
MPASS(keg == slab->us_keg);
- /* Do we need to remove from any lists? */
+ /* Move to the appropriate list or re-queue further from the head. */
if (slab->us_freecount+1 == keg->uk_ipers) {
+ /* Partial -> free. */
LIST_REMOVE(slab, us_link);
LIST_INSERT_HEAD(&keg->uk_free_slab, slab, us_link);
} else if (slab->us_freecount == 0) {
+ /* Full -> partial. */
LIST_REMOVE(slab, us_link);
LIST_INSERT_HEAD(&keg->uk_part_slab, slab, us_link);
}
+ else {
+ /* Partial -> partial. */
+ uma_slab_t tmp;
+
+ tmp = LIST_NEXT(slab, us_link);
+ if (tmp != NULL && slab->us_freecount > tmp->us_freecount) {
+ LIST_REMOVE(slab, us_link);
+ LIST_INSERT_AFTER(tmp, slab, us_link);
+ }
+ }
/* Slab management stuff */
freei = ((unsigned long)item - (unsigned long)slab->us_data)
___
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"
hwpmc(4) driver / compiler warnings
I have received the following warnings about enumerated values for enum pmc_event on stable/8 i386. I am not sure how long this has been going on because I do not really use the PMC, therefore its not built into the kernel. This is just a heads up because though this warning has no effect on my machines it may in other area's. WARNING: hwpmc_amd.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_core.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_intel.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_logging.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_mod.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_pentium.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_piv.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_ppro.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_tsc.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_uncore.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_x86.c: enum pmc_event has too many values: 1121 > 1023 Regards, -- jhell,v ___ 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: zfs sharenfs with multiple hosts/networks and options
On 08/25/2010 03:47, Heinrich Rebehn wrote: > Hi list, > > with traditional /etc/exports i can do > > /export/linux/root-ro xxx.xxx.xxx.0/24 > /export/linux/root-maproot=0 xxx.xxx.xxx.1 > > How can i do this using zfs's sharenfs option? > > When i try > > zfs set sharenfs="-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1" > data/linux/root > > /var/log/messages shows "network/host conflict" and "bad exports list line. > > The general problem seems to be that with each "zfs set sharenfs" command, > the corresponding in /etc/zfs/exports gets overwritten. > > Is there a workaround for this besides ignoring sharenfs and using hand > edited /etc/exports? > > Thanks for any help, > Hi Heinrich, All the sharenfs property is actually doing and maybe not exactly in this order is modifying /etc/zfs/exports with the interpreted contents of the sharenfs property and using a syntax that the native mountd(8) understands or at least tries to in a very simple way. After this is all done, mountd(8) recieves a HUP signal to inform if to reread /etc/exports & /etc/zfs/exports. So traditionally everything is happening the way it always has been except for the fact your now using the zfs(1M) Sun command with our own patch on top of that to make it look like its doing what you see in *Solaris or at least the interpreted version. Currently we do not have a/the share(1M) command implemented. My suggestion would be to write a script either in Python or Perl or maybe even in C to parse your own command line arguments and adjust /etc/exports or /etc/zfs/exports accordingly depending on the type of filesystem your arguments point to and then send signal HUP to mountd(8). This will at least be a little more under your control without having to modify sources and deal with conflicts later. I would recommend that you disable using the sharenfs property at all if you choose to go this route as you may start to find inconsistencies among your shares. The reference code where this is all happening is: cddl/compat/opensolaris/misc/fsshare.c Disable handling of the sharenfs property (ZFS_PROP_SHARENFS): cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c Personally I would love to see our version of the sharenfs version translated into something that is local to FreeBSD only like the org.freebsd:swap local property that we use to enable swap on zvol's. My theorized version of this would look a little like the following. zfs set \ org.freebsd:nfs='r...@192.168.1.0/24,root=0; r...@192.168.2.1,root=514' org.freebsd:nfs4='V4: ..' Where options are separated by commas and shares to different hosts or networks are separated by semicolons. But if you don't want to go through all this then you could always designate /etc/zfs/exports as a permanent share for users that are allowed to write and administered by the sharenfs property. And use /etc/exports as your extraneous read-only shares. Just a thought. Anyway! enough said. Good luck on your mission. Regards, -- jhell,v ___ 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 option survey for stable/8 r210741 (for nanobsd)
On 08/22/2010 17:23, Poul-Henning Kamp wrote: > I have run the build option survey scripts[1] on stable/8 r210741 > and have put the results here: > > http://phk/misc/build_options_stable_8_210741/ Where is this at again ? ;) -- jhell,v ___ 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: daily run output 800.scrub-zfs fixups
On 08/22/2010 08:55, Alexander Leidinger wrote: > On Sat, 21 Aug 2010 16:29:43 -0400 jhell wrote: > >> Also I just noticed another confusing message 'at least for me' that >> said "starting first scrubbing (after reboot) of pool 'exports'". I >> read that like it is going to scrub the pool after the next reboot. I >> actually had to open up the script to double check that was not the >> case. The new attached patch changes the message to "starting scrub of >> pool 'pool'" so there is no confusion of when the scrub is actually >> going to happen. > > Background info for this part: > On every reboot the info from the last scrub is lost (except in the > history output). What this part of the message was > meant to do is, to tell that there was no scrub since the last boot > (this is the first scrub since boot). > > Would it be less confusing for you if I change >starting first scrubbing (after reboot) of pool X > to >starting first scrub (since last boot) of pool X > ? That would be wonderful!. -- jhell,v ___ 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: daily run output 800.scrub-zfs fixups
On 08/21/2010 15:50, Alexander Leidinger wrote:
> On Sat, 21 Aug 2010 00:17:08 -0400 jhell wrote:
>
>>
>> Hi Alexander,
>>
>> Attached is a fix for one problem and one slight overlook for
>> 800.scrub-zfs.
>>
>> The first & second change was probably just an oversight but none the
>> less they both give a false impression of actions taken.
>>
>> Change1:
>> ${daily_scrub_zfs_default_threshold=30} is missng the ':'
>> which would ultimately reset the users supplied value in
>> periodic.conf to 30.
>
> I will have a look at this.
>
>> Change2:
>> ${_scrub_diff} -le ${_pool_threshold} would cause the scrub
>> to be run on the day after the threshold was met. So I changed '-le'
>> -> '-lt' which causes it to be run on the 30th day instead of the
>> 31st day.
>
> This depends how you define threshold... I had number of days between
> scrubs in my mind. Now it depends what I wrote in the man page, if it
> tells what I had in mind (I don't remember, I have to look at it
> myself, but I'm not a native english speaker, so I may have not wrote
> it good enough).
>
I believe that people in this case would think that if they set the
threshold to 12 days that its going to run on the same day that the
threshold was expired and not the 13th. Usually when thresholds are met
the commands are fired that same instance and not a day later.
> This is not set in stone, if the majority of people want something
> else, I'm surely not in the way.
>
Also I just noticed another confusing message 'at least for me' that
said "starting first scrubbing (after reboot) of pool 'exports'". I read
that like it is going to scrub the pool after the next reboot. I
actually had to open up the script to double check that was not the
case. The new attached patch changes the message to "starting scrub of
pool 'pool'" so there is no confusion of when the scrub is actually
going to happen.
Regards,
--
jhell,v
Index: etc/periodic/daily/800.scrub-zfs
===
--- etc/periodic/daily/800.scrub-zfs (revision 211527)
+++ etc/periodic/daily/800.scrub-zfs (working copy)
@@ -11,7 +11,7 @@
source_periodic_confs
fi
-: ${daily_scrub_zfs_default_threshold=30}
+: ${daily_scrub_zfs_default_threshold:=30}
case "$daily_scrub_zfs_enable" in
[Yy][Ee][Ss])
@@ -53,7 +53,7 @@
# Now minus last scrub (both in seconds) converted to days.
_scrub_diff=$(expr -e \( $(date +%s) - \
$(date -j -f %F.%T ${_last_scrub} +%s) \) / 60 / 60 / 24)
- if [ ${_scrub_diff} -le ${_pool_threshold} ]; then
+ if [ ${_scrub_diff} -lt ${_pool_threshold} ]; then
echo " skipping scrubbing of pool '${pool}':"
echo " last scrubbing is ${_scrub_diff} days ago, threshold is set to ${_pool_threshold} days"
continue
@@ -65,11 +65,11 @@
echo " scrubbing of pool '${pool}' already in progress, skipping:"
;;
*"none requested"*)
-echo " starting first scrubbing (after reboot) of pool '${pool}':"
+echo " starting scrub of pool '${pool}':"
zpool scrub ${pool}
;;
*)
-echo " starting scrubbing of pool '${pool}':"
+echo " starting scrub of pool '${pool}':"
zpool scrub ${pool}
;;
esac
___
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"
Fwd: daily run output 800.scrub-zfs fixups
Hi Alexander,
Attached is a fix for one problem and one slight overlook for 800.scrub-zfs.
The first & second change was probably just an oversight but none the
less they both give a false impression of actions taken.
Change1:
${daily_scrub_zfs_default_threshold=30} is missng the ':' which would
ultimately reset the users supplied value in periodic.conf to 30.
Change2:
${_scrub_diff} -le ${_pool_threshold} would cause the scrub to be run
on the day after the threshold was met. So I changed '-le' -> '-lt'
which causes it to be run on the 30th day instead of the 31st day.
Regards & Thank you again for merging this to stable/8.
PS: If you would like a PR filed for this I can do that just let me know.
Original Message
Subject: xx.dataix.local daily run output
Date: Fri, 20 Aug 2010 03:18:09 -0400 (EDT)
From: Superuser Root
To: r...@xx.dataix.local
...snip...
Scrubbing of zfs pools:
skipping scrubbing of pool 'exports':
last scrubbing is 30 days ago, threshold is set to 30 days
-- End of daily output --
Index: etc/periodic/daily/800.scrub-zfs
===
--- etc/periodic/daily/800.scrub-zfs (revision 211527)
+++ etc/periodic/daily/800.scrub-zfs (working copy)
@@ -11,7 +11,7 @@
source_periodic_confs
fi
-: ${daily_scrub_zfs_default_threshold=30}
+: ${daily_scrub_zfs_default_threshold:=30}
case "$daily_scrub_zfs_enable" in
[Yy][Ee][Ss])
@@ -53,7 +53,7 @@
# Now minus last scrub (both in seconds) converted to days.
_scrub_diff=$(expr -e \( $(date +%s) - \
$(date -j -f %F.%T ${_last_scrub} +%s) \) / 60 / 60 / 24)
- if [ ${_scrub_diff} -le ${_pool_threshold} ]; then
+ if [ ${_scrub_diff} -lt ${_pool_threshold} ]; then
echo " skipping scrubbing of pool '${pool}':"
echo " last scrubbing is ${_scrub_diff} days ago, threshold is set to ${_pool_threshold} days"
continue
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAABAgAGBQJMb07lAAoJEJBXh4mJ2FR+OF8H/RVSV15D0q2JSYjPrjr0dFSR
+dD+GOOU4ZZr5cP1oNsodIbc2CiYia6Y/TUVT39WiHF9+Pu/r9EiYG9fxvTVfeIY
pHgW5nrrDDnZU8oRNb/2k7vhwaPMXm5UUw9TlqtOL+Cx3ZpprBE2/I8sRrJutOoo
Hf5BaVDosmumJtEykI9Xg4Hkwdq18v+FIBVwxPWb0f0aUwnV9OS9XfCM3Quf50OF
ba+94EZH/2gQvGrFHb2jH9c2tYZXvtzEpSuFRFEHrbNPVpO6jjPBIQHN9xvmJwD/
2Pih6QXBIN7cfwvXpEzzbLSlIMHv7bc8Ushi1/0voIi932JJQr5/VY6DwmQvkRU=
=M7Vr
-END PGP SIGNATURE-
___
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: freebsd-stable Digest, Vol 370, Issue 2
What ? You must have missed the following suggestion/request: Might also help if it was not top-posted. ;) When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-stable digest..." On 08/17/2010 11:09, FOSS Deluxe wrote: > Well in normal use user applications are the ones that put the load on > the CPU. The kernel is pretty much lightweight in size and work when non > kernel intensive tasks are at hand (like gigabit links in the networks, > etc). The good news is that the kernel will have its own core to play with. > > On 08/17/2010 08:00 AM, freebsd-stable-requ...@freebsd.org wrote: >> Send freebsd-stable mailing list submissions to >> freebsd-stable@freebsd.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> or, via email, send a message with subject or body 'help' to >> freebsd-stable-requ...@freebsd.org >> >> You can reach the person managing the list at >> freebsd-stable-ow...@freebsd.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of freebsd-stable digest..." >> >> >> Today's Topics: >> >> 1. Re: Inconsistent IO performance (Ivan Voras) >> 2. Re: Inconsistent IO performance (Kevin Oberman) >> 3. STABLE kernel panic: privileged instruction fault (Alexey Tarasov) >> 4. Re: Inconsistent IO performance (Jeremy Chadwick) >> 5. Re: Inconsistent IO performance (Jeremy Chadwick) >> 6. Re: STABLE kernel panic: privileged instruction fault >>(Kostik Belousov) >> 7. Re: STABLE kernel panic: privileged instruction fault >>(Alexey Tarasov) >> 8. Re: STABLE kernel panic: privileged instruction fault >>(Kostik Belousov) >> 9. Re: STABLE kernel panic: privileged instruction fault >>(Alexey Tarasov) >>10. Re: STABLE kernel panic: privileged instruction fault >>(Kostik Belousov) >>11. Re: STABLE kernel panic: privileged instruction fault >> (Alexey Tarasov) >>12. Re: RELENG_7 em problems (and RELENG_8) (Mike Tancsa) >>13. Performance AMD Phenom II X6 1090T (Vladislav V. Prodan) >>14. Crash in dummynet. (Pawel Tyll) >>15. Re: Crash in dummynet. (Luigi Rizzo) -- jhell,v ___ 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: www.freebsd.org
Ugh, Top-posting. Let me dissect this. On 08/12/2010 11:07, Michael Schuh wrote: > the FreeBSD's webserver was off ( not reacheable for a time ) 's/off/on/' 's/for a time/by me/' > after my clicks and that was the problem, 's/my/my spamming/' > not that these commands nor man pages wasn't been there. -- jhell,v ___ 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: www.freebsd.org
On 08/11/2010 09:30, Michael Schuh wrote: > Hi again, > > up and running again. > many thanks. > > greetings > michael > > 2010/8/11 Michael Schuh : >> Hi@ list >> >> either i shoot the www.freebsd.org webserver in the head or he is still down >> for other reasons. >> What i have done before: >> >> look through the man pages online. >> open the manpage for ZFS >> then at the end of that manpage clicked on sharemgr(4) >> http://www.freebsd.org/cgi/man.cgi?query=sharemgr&sektion=1M&apropos=0&manpath=FreeBSD+8.1-RELEASE >> >> and after that no answer on requests. >> so i guess there will be a problem with man.cgi >> >> i have no idea who is responsible for that, if somebody >> know it and reads this please forward it to the responsible person. >> asap because www.freebsd.org isnt reacheable from here. >> >> many thanks >> >> greetings >> >> michael >> >> -- >> = = = http://michael-schuh.net/ = = = >> Projektmanagement - IT-Consulting - Professional Services IT >> Michael Schuh >> Postfach 10 21 52 >> 66021 Saarbrücken >> phone: 0681/8319664 >> mobil: 0175/5616453 >> @: m i c h a e l . s c h u h @ g m a i l . c o m >> >> = = = Ust-ID: DE251072318 = = = >> > When browsing through the manual pages for ZFS keep in mind that not all of the options utils or even manual pages are available on FreeBSD. Specifically sharemgr(1M) share(1M) unshare(1M) zonecfg(1M) dfstab(4) attributes(5) are not part of FreeBSD as of this moment. These can be better referred to as Sun/*Solaris specific commands and utilities. Regards, -- jhell,v ___ 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: [CFT] [sys/conf/newvers.sh] Cleanup and additions.
On 08/11/2010 03:47, Oliver Fromme wrote: > jhell wrote: > > Based on the parts of the script with the additions for tracking source > > using git(1) I set out to add support for mercurial hg(1) and ended up > > cleaning some of the script while making some of those additions. > > [...] > > I have opened a PR: misc/149510 here: http://bit.ly/buBqXc > > Just out of curiosity, why are you obfuscating this if statement? > > -if [ ! -r version ] > -then > -echo 0 > version > -fi > +[ ! -r version ] && echo 0 >version > > It should rather be fixed like this (FreeBSD standard is to put > if...then on one line): > > -if [ ! -r version ] > -then > +if [ ! -r version ]; then > I originally did it that way but on a sheer whim since it was a simple test and did not end up in being some big fancy line I changed it to what it is now. I have no problem changing this back since its only just a visual change & functionality would still be the same. It was just easier on my eyes while reading it for some reason and did not see a need for a multi-line statement. > On a tangential note ... I've been using a wrapper script > for "make kernel" for ages, long before svn existed. It > adds the date of the checked-out sources to the release name, > e.g. uname -rsm gives "FreeBSD 8.1-PRERELEASE-20100720 i386" > on this machine. > > http://people.freebsd.org/~olli/scripts/makekernel > Thanks, Ill check this out. Writing before reading that script I have been using a script to build the kernel too. It just set BRANCH_OVERRIDE and whatever other CFLAGS and make flags I want with the addition of looking at kern.smp.cpus and calculating the recommended value to use when using '-j' plus an additional amount if needed. > Best regards >Oliver > Thank you Oliver. -- jhell,v ___ 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: [CFT] [sys/conf/newvers.sh] Cleanup and additions.
On 08/10/2010 21:50, Anonymous wrote: > Anonymous writes: > >> jhell writes: >>> >>> And that would be to identify non-conforming ports using non-standard >>> locations. Though the option is available to look in a non-standard >> >> You're confusing default and standard value. LOCALBASE has a default for >> /usr/local. If it were a standard one wouldn't care about it and just >> hardcode /usr/local everywhere. > > ...or at least used `=' and not `?=' in bsd.port.mk. The only mention I see of LOCALBASE in all of source on stable/8 is: /usr/src/contrib/bind9/config.threads.in /usr/src/secure/usr.bin/ssh/Makefile /usr/src/secure/usr.sbin/sshd/Makefile /usr/src/tools/kerneldoc/subsys/Makefile /usr/src/tools/regression/atm/Funcs.sh /usr/src/tools/regression/atm/proto_cc/RunTest.sh /usr/src/tools/regression/atm/proto_sscfu/RunTest.sh /usr/src/tools/regression/atm/proto_sscop/RunTest.sh /usr/src/tools/regression/atm/proto_uni/RunTest.sh /usr/src/tools/tools/tinybsd/CHANGES /usr/src/usr.bin/make/Makefile So what your telling me is we would have to pull in something else to do this just for newvers.sh or is this sinking into the source from somewhere I am not aware of? -- jhell,v ___ 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: [CFT] if_ath updates - ar5416 (macbook pro, etc)
On 08/11/2010 00:11, Adrian Chadd wrote: > On 11 August 2010 11:48, jhell wrote: > > >> I have attached a dump_all_config_desc for this device in case anyone >> can identify it. Linksys WUSB54G > > Check out this: > > http://www.qbik.ch/usb/devices/search_res.php?pattern=802.11 > > ugen3.3: at usbus3, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > That vendor:product combination is in the above list. > > It looks like it's this: > > http://linuxwireless.org/en/users/Drivers/zd1211rw > > Would you mind trying linux + that driver, see if it works? > Ill have to setup or bring up a linux VM or temporary install within the next day or two and see what I come up with. > > Adrian Thanks for looking into this. I have that kernel with the merged from head revisions installing right now. Should be setup to play with in about 15 minutes then I am out of office for the night. Ill check this in the morning and review some of the logs. -- jhell,v ___ 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: [CFT] if_ath updates - ar5416 (macbook pro, etc)
On 08/10/2010 22:38, Adrian Chadd wrote: > On 11 August 2010 07:48, jhell wrote: > >> I have applied the following (r211136) to my local stable/8 branch and >> has proven to be an improvement with no drawbacks. > > Ah, the calibration scheduling change. Cool! > >> As for the rest I can not vouch for unless you give me a specific patch >> to test but I am willing to merge from head to my local tree at any >> given point in time if you can give some revisions you would like >> tested. You "I believe" made it possible for me to use this card within >> a week that I had reported it ~2007-2008 so I and my card are at your >> disposal. > > Merge in: > > r211134 and r211135; these are the AR5416 initval changes. Ill pull these in within the next hour and float some tests across the bow overnight to see what happens. > > I wasn't even thinking about working on atheros stuff in 2007/2008. :) > Ah must of been someone else then. Nonetheless it was adapted and committed to the sources within a weeks time and worked perfectly. And the email I had wrote to was answered within an hour that I had wrote it, so due to that I owe anyone working on this card a debt of gratitude and any tests that need to be run. > Thanks for the offer. I've bought a pair of AR5416's for here so I can > test regressions to the ar5416 module whilst I work on the AR9160. > Just keep an eye on the commit logs for changes I make to sys/dev/ath/ > and consider pulling some of those in. I'd appreciate any testing. :) > > > > Adrian Regards, -- On a side note I have another little nifty device that has been inactive for over a year now that does not have a associated driver that I have not gotten around to fixing up yet. I have the win drivers for this but its a USB device and does not work with NDIS. I am thinking this is just one of those quirks but like I said, I haven't had the time to really get into it since I already have multiple other means to use for wireless. I'd love to be able to use this as a permanent scanning device though. Ive tried a few different things with this device that failed to work so anybodies guess is better than mine right now. I have attached a dump_all_config_desc for this device in case anyone can identify it. Linksys WUSB54G jhell,v ugen3.3: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0051 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0009 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x008d bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x000d bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 6 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x008e bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 7 bLength = 0x0007 bDescriptorType = 0x0005
Re: [CFT] [sys/conf/newvers.sh] Cleanup and additions.
On 08/10/2010 20:39, Doug Barton wrote: > On 08/10/2010 17:34, jhell wrote: >> I also meant to CC dougb@ on this as I believe he had something to do >> with the original commits of the git(1) portions and possibly other parts. > > I have specifically sworn off any further contact with that file. I have > no idea why screwing around with what should have been a simple thing > continues to hold such endless fascination for people, but I refuse to > dive back into that swamp. > I can respect that. I just find it to be of real use to be able to identify what is currently running on the system to what revisions were available at the time it was compiled whether it be local revisions or remote or mixed like what I have done with this patch. Personally I have drove off ideas of my own for a long time due to the long standing nature and background of newvers.sh because it is just a simple straight forward use that is needed from it. To complicate something as simple as this just seems fundamentally wrong in a lot of ways so I had to weigh the negatives and positives before I decided to submit this one. Regards & thanks for the good luck, -- jhell,v ___ 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: [CFT] [sys/conf/newvers.sh] Cleanup and additions.
On 08/10/2010 19:32, Anonymous wrote: > jhell writes: > >> * Adjust the paths that are checked for binaries to be of only >> /usr/local/bin and /usr/bin. "/bin" is highly unlikely to hold svn(1), >> git(1) or hg(1). > > Please, look at conf/146828. That script shouldn't blindly assume where > user installs his packages[1]. > > [1] using non-default LOCALBASE is a convenient way to identify > non-conforming ports > And that would be to identify non-conforming ports using non-standard locations. Though the option is available to look in a non-standard location for binaries, IMHO it does not belong here and I don't find that right for building world. I also find this method a little hard to adjust for targeting specific locations, for example if the base system finally had a svnversion(1) installed and we prefered that over use of a local installed port. Currently I can just subtract that path from any one of the given SCM's configured to work with this patch without effecting the others. I have had another idea along the likes of this but just throwing an entry point hook in that checks for the existence of a user built or supplied file if you will so newvers.sh can keep doing what it has been doing for all these years without the interruption for small changes like the ones were talking about now. If people are interested in something like this I would be more than happy to oblige and provide a patch to do just that. >> +gitsvnid="`$git log |fgrep 'git-svn-id:' >> |head -1 |\ >> +sed -n 's/^...@\([0-9][0-9]*\).*$/\1/p'`" > > The above line can be sed-only. A few parts can be simplified, too. > I agree with this. I had just copied it over from what was already existing and excepted by the original committee and whoever reviewed it. I will adjust the patch for the sed(1) portion of this but I would prefer to wait for further comments from the lists before adjusting the search paths to use a function and look in a non-standard place. I also meant to CC dougb@ on this as I believe he had something to do with the original commits of the git(1) portions and possibly other parts. Thank you for following up with me on this. Regards, -- jhell,v ___ 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: [CFT] if_ath updates - ar5416 (macbook pro, etc)
On 08/10/2010 19:48, jhell wrote:
> On 08/10/2010 03:58, Adrian Chadd wrote:
>> On 10 August 2010 15:51, Adrian Chadd wrote:
>>> Hi everyone,
>>>
>>> I'm committing some updates to the if_ath and ath_hal code.
>>>
>>> I've just committed updates to the AR5416 register setup values. I'd
>>> appreciate some testing by AR5416 users - eg macbook pro users - to
>>> ensure this hasn't broken functionality.
>>
>> I've also started merging in general if_ath changes; so please test
>> the ath code in -head and let me know if I've introduced any
>> regressions.
>>
>
> I have applied the following (r211136) to my local stable/8 branch and
> has proven to be an improvement with no drawbacks.
>
> diff -r 7d9664d4ac99 sys/dev/ath/if_ath.c
> --- a/sys/dev/ath/if_ath.c Tue Aug 10 16:41:55 2010 -0400
> +++ b/sys/dev/ath/if_ath.c Tue Aug 10 19:39:25 2010 -0400
> @@ -5418,6 +5418,7 @@
> longCal = (ticks - sc->sc_lastlongcal >= ath_longcalinterval*hz);
> if (longCal) {
> sc->sc_stats.ast_per_cal++;
> + sc->sc_lastlongcal = ticks;
> if (ath_hal_getrfgain(ah) == HAL_RFGAIN_NEED_CHANGE) {
> /*
> * Rfgain is out of bounds, reset the chip
> @@ -5466,7 +5467,6 @@
> nextcal *= 10;
> } else {
> nextcal = ath_longcalinterval*hz;
> - sc->sc_lastlongcal = ticks;
> if (sc->sc_lastcalreset == 0)
> sc->sc_lastcalreset = sc->sc_lastlongcal;
> else if (ticks - sc->sc_lastcalreset >=
> ath_resetcalinterval*hz)
>
> As for the rest I can not vouch for unless you give me a specific patch
> to test but I am willing to merge from head to my local tree at any
> given point in time if you can give some revisions you would like
> tested. You "I believe" made it possible for me to use this card within
> a week that I had reported it ~2007-2008 so I and my card are at your
> disposal.
>
>
> Thank you.
>
PS I should probably also say that I am on i386 stable/8 with the AR5416
--
jhell,v
___
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: [CFT] if_ath updates - ar5416 (macbook pro, etc)
On 08/10/2010 03:58, Adrian Chadd wrote:
> On 10 August 2010 15:51, Adrian Chadd wrote:
>> Hi everyone,
>>
>> I'm committing some updates to the if_ath and ath_hal code.
>>
>> I've just committed updates to the AR5416 register setup values. I'd
>> appreciate some testing by AR5416 users - eg macbook pro users - to
>> ensure this hasn't broken functionality.
>
> I've also started merging in general if_ath changes; so please test
> the ath code in -head and let me know if I've introduced any
> regressions.
>
I have applied the following (r211136) to my local stable/8 branch and
has proven to be an improvement with no drawbacks.
diff -r 7d9664d4ac99 sys/dev/ath/if_ath.c
--- a/sys/dev/ath/if_ath.c Tue Aug 10 16:41:55 2010 -0400
+++ b/sys/dev/ath/if_ath.c Tue Aug 10 19:39:25 2010 -0400
@@ -5418,6 +5418,7 @@
longCal = (ticks - sc->sc_lastlongcal >= ath_longcalinterval*hz);
if (longCal) {
sc->sc_stats.ast_per_cal++;
+ sc->sc_lastlongcal = ticks;
if (ath_hal_getrfgain(ah) == HAL_RFGAIN_NEED_CHANGE) {
/*
* Rfgain is out of bounds, reset the chip
@@ -5466,7 +5467,6 @@
nextcal *= 10;
} else {
nextcal = ath_longcalinterval*hz;
- sc->sc_lastlongcal = ticks;
if (sc->sc_lastcalreset == 0)
sc->sc_lastcalreset = sc->sc_lastlongcal;
else if (ticks - sc->sc_lastcalreset >=
ath_resetcalinterval*hz)
As for the rest I can not vouch for unless you give me a specific patch
to test but I am willing to merge from head to my local tree at any
given point in time if you can give some revisions you would like
tested. You "I believe" made it possible for me to use this card within
a week that I had reported it ~2007-2008 so I and my card are at your
disposal.
Thank you.
--
jhell,v
___
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"
[CFT] [sys/conf/newvers.sh] Cleanup and additions.
Hello Stablers & Heads, Based on the parts of the script with the additions for tracking source using git(1) I set out to add support for mercurial hg(1) and ended up cleaning some of the script while making some of those additions. This works exactly as before but a little more correct and with the additions to be able to track kernel sources or whole source tree with a local revision system. Example output follows (uname -v) from my system being tracked locally with mercurial. FreeBSD 8.1-STABLE #0 r211092M 55:65408c40b051 Mon Aug 9 07:03:32 EDT 2010 jh...@ujump.dataix.net:/usr/obj/usr/src/sys/MITHOP Inspiration for making these changes came from mercurial, OpenSolaris and finally http://wiki.freebsd.org/LocalMercurial Following is a list of changes that I have made that I believe people that are involved with the source may find useful. 1 file changed, 55 insertions(+), 35 deletions(-) This allows a user: * That is using csup(1) or cvsup(1) to locally keep track of the whole source tree or just the kernel part of the tree using svn(1), hg(1) or git(1). * That is using svn(1) to checkout their source tree to use hg(1) or git(1) to keep track of the whole tree or the kernel part of the tree. http://svn.freebsd.org/base/ * That is using git(1) to checkout their source tree to use hg(1) to keep track of the whole tree or the kernel part of the tree. http://spoerlein.net/gitweb/ This checks for: * SCM roots in src/ or src/sys for .svn, .hg, & .git and acts accordingly if they exist while prioritizing using an SCM root in src/ before it uses src/sys/ * Then looks for acceptable binaries for svn(1), hg(1) git(1) within the select paths /usr/local/bin & then /usr/bin. The paths may change for svn(1) or git(1) & maybe mercurial if it ever becomes part of world. Currently I have set these to only look in /usr/local/bin. Cleanups: * Instead of using variables that shared the same name as their counterpart binaries to hold a revision number use more descriptive names like svnrev gitrev & hgrev for revisions. Use git svnversion & hg variables for their respective binaries. * Adjust the paths that are checked for binaries to be of only /usr/local/bin and /usr/bin. "/bin" is highly unlikely to hold svn(1), git(1) or hg(1). * Test for a SCM root in the source tree locations before we look for binaries. If these don't exist there is no need to know where svn or git are. * For git(1) always set work-tree and git-dir so there is no possibility to end up with a "-dirty" git(1) revision. * Remove extraneous "touch version" since the previous if statement already creates the file if its not found. * Inline the test for version file. I have opened a PR: misc/149510 here: http://bit.ly/buBqXc And have uploaded the patch here: http://bit.ly/9hvVfx Throw me some feedback, concerns or other information. It will be really appreciated. Regards, -- jhell,v ___ 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: Kernel symbol file alternate location
On 08/06/2010 06:19, Oliver Fromme wrote: > Kostik Belousov wrote: > > If you keep /usr/obj around, you do not need symbol files at all, > > and INSTALL_NODEBUG?=true in make.conf is enough. You can always > > use kernel.debug and modules with debugging symbols from build > > directory for kgdb. > > OK ... But that won't work for /boot/kernel.old. > > Best regards >Oliver > kernel /boot/kernel symbols /boot/sym When kernel is upgraded old kernel and sym becomes /boot/kernel.old /boot/sym.old If I remember correctly in a recent backtrace that I have tried when I used /boot/kernel.old/kernel the symbols ended up loading from /boot/kernel anyway and not the kernel.old directory. So whether these are moved to a different location or not I do not believe it will make that much of a difference on where they are loaded from. I may be wrong about this. IMO creating symlink's is going to be a bad way to handle this and adjusting the respective utilities that use the symbols is a much more permanent and failure safe way to go about this. Besides moving the location of the symbols and having a debugging utility or crash dump utility fail is not really a mission critical failure and would be able to be found and corrected fairly quick among the amount of people that are using these. $0.02 US Regards, -- jhell,v ___ 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 console bug still exists
On 08/04/2010 03:22, David Xu wrote: Sigh, pressing ScrollLock key several times can lock up the kernel when it is still booting before /sbin/init runs. David Xu Sorry David, No matter what I have tried I have not been able to reproduce this across 5 separate machines. Is there any way that you could obtain a backtrace and or any other further information ? Is there a PR already opened ? has it been looked at ? is there another thread already started on this ? Is this a USB keyboard ? PS/2 ? is this a USB keyboard plugged into a PS/2 via a USB->PS/2 plug ? is this a laptop ? PC ? PPC ? ARM ? There is not enough information on this subject from you yet. Please provide some URLs to your hardware & some other information like uname -a output & kernel config etc... Some hints I might possibly be able to provide you with are disabling device vkbd, or kbdmux or both if you have that choice and you are not making sufficient use of them. Obviously this depends a lot on your usage and what the hardware is but these are things that you have to answer. Regards & Good Luck, -- jhell,v ___ 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: Problems replacing failing drive in ZFS pool
On 07/21/2010 02:14, Joshua Boyd wrote: > [r...@foghornleghorn ~]# zpool replace tank da0 label/disk01 > cannot open 'label/disk01': no such GEOM provider > must be a full path or shorthand device name Of course you cant. You have labeled a disk that is already in use so in turn the label should never appear in dev/label/*. If you tried to re-silver the same disk that was already in use I would think if it could be done that the result would be of inconsistent data and write errors all over the place. Regards, -- jhell,v ___ 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.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?)
On Sat, 17 Jul 2010 14:35, Markus Gebert wrote: In Message-Id: On 13.07.2010, at 16:02, Markus Gebert wrote: Unfortunately, I have not been able to get anything useful out the svn commit logs, which could explain this. Maybe someone else has an idea what could have changed between 7 and 8 to break it, and again between 8 and CURRENT to magically fix it again. I tracked this down further. I couldn't easily downgrade my 8.1 installation to see when the problem was introduced because the zpool version used is 14. So I tried to figure out, when the problem was solved in CURRENT. I started with the first possible revision that can boot off my v14 pool (r201143, Dec 28, zfs v14 commit). With this revision, I was able to trigger the MCE. Then I took some later revision (rev206010, Apr 1, chosen randomly), and I couldn't reproduce the problem. I started narrowing the revisions down until I found out, that while on r202386 I'm still able to trigger the MCE, r202387 seems to solve the problem on CURRENT: http://svn.freebsd.org/viewvc/base?view=revision&revision=202387 Since John Baldwin mentioned this problem could be timing related, it seems reasonable, that a clock-related change could be fix it. But this commit seems to have been MFC'd to 8-STABLE and 8.1 (at least as far as I can tell) along with some other changes to amd64 specific code. I thought that maybe these other changes that have been MFC'd could have reintroduced the problem later on, but so far I could not reproduce the problem with newer CURRENT revisions. So, I actually nailed this one done to a single commit on CURRENT, but still cannot tell what the actual difference is compared to 8-STABLE/8.1. Any ideas how to proceed? Adding to this I remembered some specific commits that caught my attention when they happened. Specifically they were to mca.c (locate mca) on my machine provided the file paths and svn log provided the commit log. When you said April and I seen the log it rang a bell. These may be of interest to you: r210079 | jhb | 2010-07-14 17:10:14 -0400 (Wed, 14 Jul 2010) | 13 lines MFC 208507,208556,208621: Add support for corrected machine check interrupts. CMCI is a new local APIC interrupt that fires when a threshold of corrected machine check events is reached. CMCI also includes a count of events when reporting corrected errors in the bank's status register. Note that individual banks may or may not support CMCI. If they do, each bank includes its own threshold register that determines when the interrupt fires. Currently the code uses a very simple strategy where it doubles the threshold on each interrupt until it succeeds in throttling the interrupt to occur only once a minute (this interval can be tuned via sysctl). The threshold is also adjusted on each hourly poll which will lower the threshold once events stop occurring. r206183 | alc | 2010-04-05 12:11:42 -0400 (Mon, 05 Apr 2010) | 6 lines MFC r204907, r204913, r205402, r205573, r205573 Implement AMD's recommended workaround for Erratum 383 on Family 10h processors. Enable machine check exceptions by default. And a list of mca.c's within the stable/8 src tree: /usr/src/sbin/mca/mca.c /usr/src/sys/amd64/amd64/mca.c /usr/src/sys/dev/aha/aha_mca.c /usr/src/sys/dev/buslogic/bt_mca.c /usr/src/sys/dev/ep/if_ep_mca.c /usr/src/sys/i386/i386/mca.c /usr/src/sys/ia64/ia64/mca.c Regards & Good luck, -- jhell ___ 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: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
On 07/11/2010 23:08, Freddie Cash wrote: > Search the archives for the -stable, -current, and -fs mailing lists > from the past 3 months. There are patches floating around to fix > this. The ZFS code that monitors memory pressure currently only > monitors the "free" amount, and completely ignores the "inact" and > other "not actually in use" amounts. > AFAIR, any of the patches that were around were either incomplete or inconsistent & were good attempts to solve the problem but turned out in the end to not effect the problem in a positive or negative way. I may be wrong as it seems the problem has a few variables that determine its effect in different cases, usage, hardware mixture & implementation. If there is one thing that I have been seeing more of was the perl hack that gets every process on your system to swap-out to free RAM for use by ZFS or whatever its intention. perl -e '$x = "x" x 100;' It might be a good thing to mention this on the ZFS tuning section of the wiki for reference. Regards & Good Luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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.x grudges
On 07/08/2010 10:08, Marian Hettwer wrote: > Hi jhell, > > ehm... > > Am 08.07.10 14:46, wrote jhell: > On 07/08/2010 06:54, for whatever Marian Hettwer wrote: > >> I certainly not wrote the text below. That's what, I guess, you wrote. >> Your MUA is defect. >> And honestly, I don't know why that's a reply to my email (which you >> completely deleted, apart from the "On 07/08/2010 06:54, for whatever >> Marian Hettwer wrote") thingy.. > >> confused, >> Marian > >> PS.: I guess your Mail should have been a reply to someone else's mail?! > Yeah... that was not intended to go to you. ugh! ;( -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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.x grudges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2010 06:54, for whatever Marian Hettwer wrote: With any major upgrade or release process comes a commitment from the developers and end-users alike that involves a review, testing & release. The release part on the end-users behalf is simply a commitment to follow through & make needed changes to what has been reviewed and tested & continue with the current use accepting the changes. Taking a guess here, but you are probably a manager in a company that is asking you to cut back your test environment because it is hard for you to maintain with a under staffed under knowledged IT department resulting in a non-efficient budget that could end up in more staff being cut. Personally even if the above is not true I would fire you and keep a few more testbeds, just for wasting a free projects developers time by posting non nonsensical radical & somewhat fascist views on this list. Everyone has a bad day once in a while but using a troll type manor while ranting and raving obnoxiously instead of getting involved appropriately is unacceptable and will not solve your problem. - -- "I say things as they are. Slackers are called slackers, people who can't read manual pages are called losers, and in general, calling things what they are results in developers wasting less time." -- Theo +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBAgAGBQJMNcivAAoJEJBXh4mJ2FR+h68H/1mw7n4/KpDvzDxa8MACUMYI 9lQGKvKIjm2IrOfWlTpnoOAJOYKmsEE2b9fKht0376z1tze/tssNLkFD0CLZt+NK +Vyt7kraqyv6vn85ZQjLU1OD1z8XAOwVI1EMHusGaJi8VfscLerT1rIDplc1hfFt uH5GYnvepyqxKxtB9a2+eXwyjuz/dlfx4Dj8TvhdbfF9Ge5HuzWZcb4xzCIYPeIA KSrqxbOn5bpgiOW4i83hUT88Ntl7ZTw83UfnsiFOPQmtlzfQorc8QOF+gdjGAsG+ k4AuNoo4fBKbu50kSLO4hf+dccIga3Y3a5P2iwS+ANXbsHs9PcSNZ8p35Tk0MM8= =0IA0 -END PGP SIGNATURE- ___ 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: Odd behavior of labels on different filesystem types
On 07/04/2010 12:15, Kevin Oberman wrote: >> Sender: "J. Hellenthal" >> Date: Sun, 04 Jul 2010 01:55:20 -0400 >> From: jhell >> >> On 07/03/2010 16:51, Kevin Oberman wrote: >>> I have run into an odd behavior in 8-stable that I can't see a reason >>> for. >>> >>> If I have a FAT32 formatted removable drive, I get /dev entries for it >>> as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the >>> filesystem, the /dev/ufsid label is removed, but the other two remain. >>> >>> If I have a UFS filesystem on the disk, I have similar devices except >>> that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, >>> the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. >>> >>> I'm not sure which is "right", but I can't see the reason for the >>> different behavior and it has caused a fair bit of trouble when working >>> with gnome-mount as I can't unmount a ufs device. When the >>> /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a >>> new device and immediately re-mounts it. >>> >>> Can this inconsistency be corrected? >> >> Can you try to zero out that disk first i.e. >> dd if=/dev/zero of=/dev/DISK bs=4m >> >> Then format your msdos fat part and relabel it. You should not see a >> dev/ufsid/ label for this anymore. I believe that for some reason the >> ufsid metadata or whatever you want to call it some how has been left >> behind and is still being read for whatever reason and can be confirmed >> by this. >> >> As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the >> others should disapear so this is correct behavior. > > Thanks for the suggestion. I will try a device which has never had a UFS > file system and see if the ufsid device is created. Looks like the > former is an issue with geom tasting and it would be nice to get it > fixed, but it is not what is causing my problem. It is the latter issue > that causes the problems with gnome-mount. > > The real issue for me is that /dev/ufs/LABEL is removed on a mount while > /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring > it, but the /dev/FS/LABEL has to be acted upon differently depending on > which filesystem is involved. Do you use those labels for anything ? if not, I worked around this while I used gnome for a period with devfs.rules(5) example follows. rc.conf(5) add devfs_system_ruleset="your_system" [your_system=10] add path 'ufsid'hide add path 'msdosfs' hide add path 'ufs' hide add path 'iso9660' hide add path 'reiserfs' hide add path 'ntfs' hide add path 'ext2fs' hide add path 'gpt' hide And you can do the same for the actual devices that you use a label for, so mounting devices like daN can just be done from /dev/label/LABEL. add path 'da0' hide # Do this only after it is labeled. add path 'label/DA0LABEL' mode 0600 user jhell group jhell With a little toying of the above you should get the desired effect you want in gnome. I do find it frustrating having to resort to using only generic labels for situations like this and believe firmly that the generic label should take precedence over all labels except gpt & ufsid and result in the other name-brand labels disappearing not causing this frustration to happen. Having the multiple layers of labels available IMO is cause for confusion. Final note before I stretch this out like the Armstrong figurine ;), there was a case where I was using the module instead of having GEOM_LABEL option built into the kernel, this being loaded after the machine was already booted caused some strange results with the labels that I know of on 7.2-STABLE. I don't know if this still exists but the result from that was multiple labels still being available under /dev while its counterpart label was mounted. That caused Gnome/hald to get pretty confused. Regards & Good luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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: Odd behavior of labels on different filesystem types
On 07/03/2010 16:51, Kevin Oberman wrote: > I have run into an odd behavior in 8-stable that I can't see a reason > for. > > If I have a FAT32 formatted removable drive, I get /dev entries for it > as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the > filesystem, the /dev/ufsid label is removed, but the other two remain. > > If I have a UFS filesystem on the disk, I have similar devices except > that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, > the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. > > I'm not sure which is "right", but I can't see the reason for the > different behavior and it has caused a fair bit of trouble when working > with gnome-mount as I can't unmount a ufs device. When the > /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a > new device and immediately re-mounts it. > > Can this inconsistency be corrected? Can you try to zero out that disk first i.e. dd if=/dev/zero of=/dev/DISK bs=4m Then format your msdos fat part and relabel it. You should not see a dev/ufsid/ label for this anymore. I believe that for some reason the ufsid metadata or whatever you want to call it some how has been left behind and is still being read for whatever reason and can be confirmed by this. As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the others should disapear so this is correct behavior. -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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: My kernel panics suck
On 07/02/2010 16:29, C. P. Ghost wrote: > On Fri, Jul 2, 2010 at 9:18 PM, William D. Colburn (Schlake) > wrote: >> I got my new 8-stable system up, and now I just have recurrent disk >> controller failures. The machine can't stay more than about ten >> minutes before it panics into a hung kernel, or simple reboots. >> Unfortunately, I know the root cause of the panics. If my computer is >> sitting on the table, then the kernel doesn't panic. If the computer >> is sitting on the desk, then it panics like mad. The table is wooden, >> the desk is metal. Of course, I'm also changing power too. On the >> table, I use a wall outlet, while on the desk I use my Smart UPS. >> Unfortunately, you can't really help me with this. I'm just writing >> in out of the hope that I'll get some sympathy for this problem. > > Yuck...! If you have an electrical insulation problem, and your desk > is metal, I'd _really_ urge you to replace your hardware completely, > or have it properly insulated by a professional electrician. An electric > shock could cause real pain() and panic(). ;-) > > But seriously, if that's the only reason for the panics, it's a pretty > strong hint that you have an electrical problem: when ICs are > underpowered, they tend to behave erratically. > >> -- Schlake > > -cpghost. > Adding to this, though I find it unlikely but worth mentioning but you could be grounding out to a already charged surface through a screw in the case (laptop/desktop), check the bottom and cover up anything you find with black electrical tape and try again. Another route would be to grab a multimeter and test the metal table for a positive ? source. If that metal table also happens to be screwed down to the floor then take all the screws out as one maybe more could be running across some weird current. Regards, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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: panic during boot on 8.0-RELEASE
On 06/22/2010 19:42, Nicholas Mills wrote: > Oops, sent this to the wrong list. > > --Nick > > -- Forwarded message -- > From: Nicholas Mills > Date: Tue, Jun 22, 2010 at 7:41 PM > Subject: panic during boot on 8.0-RELEASE > To: freebsd-curr...@freebsd.org > > > Hey all, > > Screenshot of panic message is attached. Machine is a VM running under > Parallels Server Bare Metal 4. The cdrom device was enabled but not > connected during boot. System was attempting to boot into single user mode. > This occurred after a fresh install of 8.0-RELEASE. > > Let me know how I can provide more useful info. > Upload the image somewhere else and provide a link to that. 8.1-RELEASE is coming at some point. You might want to try RC1 snapshots here: http://bit.ly/b7K6fI Good Luck, -- jhell ___ 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: FreeBSD eats 169.254.x.x addressed packets
On 06/09/2010 08:28, Reko Turja wrote: >> One final comment - I still don't understand why FreeBSD "won't" >> respond to pings >> when it has an address like 169.254.1.1. I can ssh to the unit but it >> won't >> respond to pings. I tried setting up a linux box with an address like >> 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... > I do not believe that is what he was implying by comparing this to Linux. I think he might be using Linux as a example of "They have not limited their users to only changing source code" to get the objective completed. They should have. In this case and reviewing the previous messages + remembering these: http://bit.ly/9sigji http://bit.ly/9pfE9A http://bit.ly/9CNT3K FreeBSD takes the correct action for this scenario which could proudly be used as an exemplary piece of code that other forms of OS's should use as a reference for integrity. http://bit.ly/byHBzN Regards, -- jhell ___ 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: Make ZFS auto-destroy snapshots when the out of space?
On 05/30/2010 18:06, Kirk Strauser wrote: > On May 29, 2010, at 9:42 PM, Dan Nelson wrote: > >> If the kernel does the snapshot deleting itself, why not add a pool-level >> property that sets the amount of free space at which the deletion starts? >> That way you don't need the cleanup script. Alternatively, make the >> org.freebsd:allowautodestroy property hold the trigger freespace amount. >> That way you can have monthly/daily/hourly snapshots but set it so the >> hourly ones disappear first, then the dailies (by setting the destroy >> trigger slightly higher for the ones you want to expire first). > > > That'd definitely work. The idea was to keep as much as possible out of > the kernel so that it wouldn't add additional complexity for people who > don't use it (but it certainly wouldn't offend me any to find it in > there :-) ). I think this would probably be best handled by the script that is creating the snapshots. Though this is a nice feature how well would it be received upstream and in what period of time would we have to wait while maintaining are down-level patches. I would propose looking at the creation time of the snapshots while in creation mode and parsing for a time that is older than a use configurable variable so the script can take proper action when destroying snapshots before it tries to create a new one and look at a value comprised of either the quota property or a attribute like the previous one stated. I strongly urge against creating a attribute that the script would look for due to the reason it would take more involvement with the script to be specific to FreeBSD where as now it should be OS independent. # This works good enough to compare with date(1) "+%s" zfs get -o name,value creation | grep @ # This works for seeing exactly how much a snapshot is using zfs get -o name,value used |grep @ Between the above two examples a threshold can be achieved at which older data can expire faster or slower depending on your settings and provide an upper tolerance for space usage. Of course this can be refined and there is a whole lot that is left to be scripted around the above commands. Regards, .02 -- jhell ___ 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: Zpool scrub and not-root users
On Tue, 25 May 2010 16:13, Jeremy Chadwick wrote:
In Message-Id: <20100525201315.ga20...@icarus.home.lan>
On Tue, May 25, 2010 at 03:21:56PM -0400, jhell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2010 15:04, Jeremy Chadwick wrote:
On Mon, May 24, 2010 at 05:00:03PM +0200, Mikkel Skaerris wrote:
Im wondering if there is a way of allowing non-root users to perform a disk
scrub using zpool scrub . I've been messing around with permissions,
but no luck so far. Anyone got a clue?
One question: why? Followed by one answer: sudo. :-)
Don't get me wrong I'm not shooting down sudo below.
: He does not need to add another layer of insecurity to his system such
: as sudo. Not saying that this is bad but it feels like a little overkill
: for something as simple as this.
This can be done old-school.
pw groupadd _zfsadm
pw groupmod _zfsadm -m {username}
chmod u+s,o-rx /sbin/zpool
chown :_zfsadm /sbin/zpool
: Repeat command line 2 for every user you want to have root type access
: to /sbin/zpool.
I thought I said "root type access to /sbin/zpool".
Of course you do not need the zfsadm group to do this. You could just
use the wheel group which in turn gives any member of that group su(1)
access to the root user, so you commands would turn into...
pw groupmod wheel -m {username}
chmod u+s,o-rx /sbin/zpool
Because this binary is already installed group wheel there is no need to
chown it. And this is a little more implicit that you trust anyone with
access to the zpool command will also be having access to su(1)
Pick one, and Ill leave the "how to keep these permissions through
upgrades/updates of world" up to you.
If I'm misunderstanding what the OP wants, then I welcome correction. I
read the Op to want users to be able to run "zpool scrub", so I took
that literally -- "/sbin/zpool scrub " and nothing more.
No you are not misunderstanding but I am also taking into account that the
admin said "I've been messing around with permissions" & most notably I
thought that he has tried the access control methods that are administered
through the use of zfs allow which also might be a possibility if the
admin has world/base on a zfsroot. Second thought that came to mind while
leaving the possibility open to him was your standard Unix file perms.
While thinking about the scenario in a quick sense, If this is disk
activity that the admin wants to grant to a user in the form of scrub on a
pool then the admin already must trust whoever he is planning to give
these rights and has taken into account the possibility of misuse which
has lead him here asking for advice.
sudo offers the ability for the OP to provide root-level access to
defined users and ONLY the ability to run "/sbin/zpool scrub {pool}" and
nothing more (e.g. not "/sbin/zpool remove" or similar). It could also
be used to define certain users to scrub only certain pools.
I hope so at least that's what it was designed for. Yes very well noted
just leaving the possibility open to the admin to use something other than
a third party package in case it is his policy to not have something like
that installed. It happens.
Your first and second solutions allow any user added to _zfsadm and
group wheel, respectively, the ability to use /sbin/zpool. I hear
"zpool destroy -f" is a fun command to run while the system
administrator isn't looking. :-)
Good thing in most cases you can recover a destroyed pool or at least
that's the way it was designed the last time I accidentally did that (-D).
Backups are also a good thing in the case of a angry over driven highly
motivated administrator or staff.
;)
--
jhell
___
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: Zpool scrub and not-root users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2010 15:04, Jeremy Chadwick wrote:
> On Mon, May 24, 2010 at 05:00:03PM +0200, Mikkel Skaerris wrote:
>> Im wondering if there is a way of allowing non-root users to perform a disk
>> scrub using zpool scrub . I've been messing around with permissions,
>> but no luck so far. Anyone got a clue?
>
> One question: why? Followed by one answer: sudo. :-)
>
He does not need to add another layer of insecurity to his system such
as sudo. Not saying that this is bad but it feels like a little overkill
for something as simple as this.
This can be done old-school.
pw groupadd _zfsadm
pw groupmod _zfsadm -m {username}
chmod u+s,o-rx /sbin/zpool
chown :_zfsadm /sbin/zpool
Repeat command line 2 for every user you want to have root type access
to /sbin/zpool.
Of course you do not need the zfsadm group to do this. You could just
use the wheel group which in turn gives any member of that group su(1)
access to the root user, so you commands would turn into...
pw groupmod wheel -m {username}
chmod u+s,o-rx /sbin/zpool
Because this binary is already installed group wheel there is no need to
chown it. And this is a little more implicit that you trust anyone with
access to the zpool command will also be having access to su(1)
Pick one, and Ill leave the "how to keep these permissions through
upgrades/updates of world" up to you.
Good luck & regards,
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJL/CNUAAoJEJBXh4mJ2FR+HwcH/0vuGlIP8mU1p6FI0XiEl9K/
tpDLxED+4cd8htBTQyh0mDWrRz8dOagjggaENC2JvNpUO8Vhxx0mJNZY6pvzmAys
5VHevdYKvY6doEjoQD9muktECXruCOXgQtxeI34r+ZLJz9fUhVJIlcNDBBrhOAG5
/P6XYy5LIKEuxBBRNqosW+JVTcU4sOJhGU1YZUlUpn0z41ObM87vjD77XP6sWfhZ
Sw5dDPhNBHmmOuCEeuTnpItu1ykHUrr5jDkrtFWyIFP7ijPl7Fbd3VIRaP5nlWDU
yNd06479yKS1uqOwFeEXt3DOr8nws+uY/6WtXzlsmLdhsqwy2FQN35r7PlXaY0k=
=c/NP
-END PGP SIGNATURE-
___
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: r207811 rc.subr
On 05/09/2010 14:53, Doug Barton wrote: > On 05/09/10 07:47, jhell wrote: >> Hi again Doug, >> >> Just another report about rc.subr r207811. >> >> Cannot 'resync' ipfilter. Set ipfilter_enable to YES in /etc/rc.conf or >> use 'one resync' instead of 'resync'. > > You need to update ALL of your /etc, including /etc/rc.d/netif. > Woh sorry, at some point I lost track of the modifications and missed a couple. Thanks for clearing that up for me Doug. -- jhell ___ 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"
r207811 rc.subr
Hi again Doug, Just another report about rc.subr r207811. Cannot 'resync' ipfilter. Set ipfilter_enable to YES in /etc/rc.conf or use 'one resync' instead of 'resync'. Cannot 'resync' ipfilter. Set ipfilter_enable to YES in /etc/rc.conf or use 'one resync' instead of 'resync'. This happens during boot... This is also on a system that does not have ipfilter, built WITHOUT_IPFILTER=yes. -- jhell ___ 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 of r206686 r179870
The following two commits to stable/7 may be responsible for dirtying
the console with messages pertaining to setting values in rc.conf.
Though these messages are harmless and daemons will continue to run as
normal; they should be looked into & fixed.
reverting to revision 201272 of rc.subr relieves this problem.
r207801 | dougb | 2010-05-08 18:15:05 -0400 (Sat, 08 May 2010) | 4 lines
Changed paths:
M /stable/7/etc
M /stable/7/etc/rc.subr
MFC r206686:
Make 'stop' work even if ${name}_enable is not set.
r207800 | dougb | 2010-05-08 18:13:48 -0400 (Sat, 08 May 2010) | 8 lines
Changed paths:
M /stable/7/etc
M /stable/7/etc/rc.subr
MFC r179870:
Move the check for enabled knobs further down in run_rc_command() so
that bogus commands cause usage information to be printed instead of
diagnostics about enabling the knob.
This is a prerequisite for merging r206686.
Regards,
--
jhell
___
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: ZFS Tuning - arc_summary.pl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 29 Mar 2010 10:43, Barry Pederson wrote:
In Message-Id: <4bb0bc7c.3000...@barryp.org>
I've been using the arc_summary.pl script from here:
http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summary.pl
and noticed some odd numbers, with the ARC Current Size being larger than the
Max Size, and the breakdown adding up to less than the current size as shown
below
ARC Size:
Current Size: 992.71M (arcsize)
Target Size: (Adaptive) 512.00M (c)
Min Size (Hard Limit): 81.82M (arc_min)
Max Size (Hard Limit): 512.00M (arc_max)
ARC Size Breakdown:
Recently Used Cache Size: 99.84% 511.18M (p)
Frequently Used Cache Size: 0.16% 0.82M (c-p)
From another thread I saw, it sounds like arc_max isn't really
a "Hard Limit" but rather some kind of high water mark. If that's
the case then I wonder if this might make more sense
-
--- arc_summary.pl.original 2010-02-25 19:23:13.0 -0600
+++ arc_summary.pl 2010-03-29 09:32:28.0 -0500
@@ -121,20 +121,20 @@
my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size};
my $arc_size_MiB = ($arc_size / 1048576);
-my $mfu_size = $target_size - $mru_size;
+my $mfu_size = $arc_size - $mru_size;
my $mfu_size_MiB = ($mfu_size / 1048576);
-my $mru_perc = 100*($mru_size / $target_size);
-my $mfu_perc = 100*($mfu_size / $target_size);
+my $mru_perc = 100*($mru_size / $arc_size);
+my $mfu_perc = 100*($mfu_size / $arc_size);
print "ARC Size:\n";
printf("\tCurrent Size:\t\t\t\t%0.2fM (arcsize)\n", $arc_size_MiB);
printf("\tTarget Size: (Adaptive)\t\t\t%0.2fM (c)\n", $target_size_MiB);
printf("\tMin Size (Hard Limit):\t\t\t%0.2fM (arc_min)\n",
$arc_min_size_MiB);
-printf("\tMax Size (Hard Limit):\t\t\t%0.2fM (arc_max)\n",
$arc_max_size_MiB);
+printf("\tMax Size :\t\t\t%0.2fM (arc_max)\n",
$arc_max_size_MiB);
print "\nARC Size Breakdown:\n";
printf("\tRecently Used Cache Size:\t%0.2f%%\t%0.2fM (p)\n", $mru_perc,
$mru_size_MiB);
-printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (c-p)\n", $mfu_perc,
$mfu_size_MiB);
+printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (arcsize-p)\n",
$mfu_perc, $mfu_size_MiB);
print "\n";
### ARC Efficency ###
---
Giving something like this...
ARC Size:
Current Size: 992.88M (arcsize)
Target Size: (Adaptive) 512.00M (c)
Min Size (Hard Limit): 81.82M (arc_min)
Max Size : 512.00M (arc_max)
ARC Size Breakdown:
Recently Used Cache Size: 51.48% 511.18M (p)
Frequently Used Cache Size: 48.52% 481.70M (arcsize-p)
Barry
Barry,
What branch and revision was this run on ?
I need the above information because the output above just does not match
up quite as it should and I want to investigate when, where & why as I
believe something else is going on here that is not on the behalf of
arc_summary.pl.
Or if you could provide me personally with the full output of the script
from the downloads section "just to be sure" in an attachment that would
work as well.
Thanks.
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLzUAhAAoJEJBXh4mJ2FR+kP4H/3FSkazC+Jxv0q5XJhP/YfeP
gJ0vWP+84J6HM68GyS4eCOu3QPGUPBAuqZOS8Bb9jXg9xNfxCvw2DQn5mP6v6i6H
w8mWyYyCla7iBfItod4L2GjQeP52SIt7sW9icDeWvrS+LphwjTQmBiA4QwGBQT5D
YiarUMpzY1Jkq8I6YgGYRIwZqeuNn7X68ZEKIz8/LhTM6WKdktm5dcBb6UM/mC/a
I82sv+7mG/9Bn0Orp7DMqvym0rllYmb+Sj7Pj2NEcPt9LYDNf6Vy1Wmly6hNQTYb
b8WkfgLeMogDN9JS6Bw+UxNGwHgQgqDIWvkKDt9qrmuTpKLEozD6GnBzo27uZkg=
=RoRd
-END PGP SIGNATURE-
___
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: ZFS Tuning - arc_summary.pl
On 03/29/2010 12:11, Jeremy Chadwick wrote: > On Mon, Mar 29, 2010 at 09:43:08AM -0500, Barry Pederson wrote: >> From another thread I saw, it sounds like arc_max isn't really >> a "Hard Limit" but rather some kind of high water mark. If that's >> the case then I wonder if this might make more sense > > It became a hard limit in a semi-recent commit somewhere. I've lost > count of the modifications at this point. So, the perl script would > have to read __FreeBSD_version in /usr/include/osreldate.h and adjust > its output accordingly. > Update: The current version in head r52 has these modifications now. As a side note while doing the the original modification I noticed some strange values (negative) and decided to just branch what I already had in head to stable/7 and continue with the modifications in head. arc_summary.pl has not been updated in the downloads section until I investigate more what happened with those negative values and why. I will probably be adding some more (2) lines to the ARC Size Breakdown area that compares its current usage to the the target_size so a comparison can be done side-by-side of the difference to current size and what it would look like at the target_size. Regards, -- jhell ___ 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: Results of BIND RFC
On 04/01/2010 23:48, Randy Bush wrote: >> May I only hope this is legit and not a April Fool's joke :) > > actually, as an unbound user, i would be quite happy to have bind > removed. bloated, ever-buggy, config religion, ... > > randy At least I hope that this will be removed and added to the distribution as a package upon release time. -- jhell ___ 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: ZFS Tuning - arc_summary.pl
On 03/29/2010 10:43, Barry Pederson wrote:
> I've been using the arc_summary.pl script from here:
>
> http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summary.pl
>
>
> and noticed some odd numbers, with the ARC Current Size being larger
> than the Max Size, and the breakdown adding up to less than the current
> size as shown below
>
>
> ARC Size:
> Current Size: 992.71M (arcsize)
> Target Size: (Adaptive) 512.00M (c)
> Min Size (Hard Limit): 81.82M (arc_min)
> Max Size (Hard Limit): 512.00M (arc_max)
>
> ARC Size Breakdown:
> Recently Used Cache Size: 99.84% 511.18M (p)
> Frequently Used Cache Size: 0.16% 0.82M (c-p)
>
>
>
> From another thread I saw, it sounds like arc_max isn't really
> a "Hard Limit" but rather some kind of high water mark. If that's
> the case then I wonder if this might make more sense
>
>
>
> -
> --- arc_summary.pl.original 2010-02-25 19:23:13.0 -0600
> +++ arc_summary.pl 2010-03-29 09:32:28.0 -0500
> @@ -121,20 +121,20 @@
>
> my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size};
> my $arc_size_MiB = ($arc_size / 1048576);
> -my $mfu_size = $target_size - $mru_size;
> +my $mfu_size = $arc_size - $mru_size;
> my $mfu_size_MiB = ($mfu_size / 1048576);
> -my $mru_perc = 100*($mru_size / $target_size);
> -my $mfu_perc = 100*($mfu_size / $target_size);
> +my $mru_perc = 100*($mru_size / $arc_size);
> +my $mfu_perc = 100*($mfu_size / $arc_size);
>
> print "ARC Size:\n";
> printf("\tCurrent Size:\t\t\t\t%0.2fM (arcsize)\n", $arc_size_MiB);
> printf("\tTarget Size: (Adaptive)\t\t\t%0.2fM (c)\n", $target_size_MiB);
> printf("\tMin Size (Hard Limit):\t\t\t%0.2fM (arc_min)\n",
> $arc_min_size_MiB);
> -printf("\tMax Size (Hard Limit):\t\t\t%0.2fM (arc_max)\n",
> $arc_max_size_MiB);
> +printf("\tMax Size :\t\t\t%0.2fM (arc_max)\n",
> $arc_max_size_MiB);
>
> print "\nARC Size Breakdown:\n";
> printf("\tRecently Used Cache Size:\t%0.2f%%\t%0.2fM (p)\n", $mru_perc,
> $mru_size_MiB);
> -printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (c-p)\n",
> $mfu_perc, $mfu_size_MiB);
> +printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (arcsize-p)\n",
> $mfu_perc, $mfu_size_MiB);
> print "\n";
>
> ### ARC Efficency ###
>
> ---
>
>
> Giving something like this...
>
>
> ARC Size:
> Current Size: 992.88M (arcsize)
> Target Size: (Adaptive) 512.00M (c)
> Min Size (Hard Limit): 81.82M (arc_min)
> Max Size : 512.00M (arc_max)
>
> ARC Size Breakdown:
> Recently Used Cache Size: 51.48% 511.18M (p)
> Frequently Used Cache Size: 48.52% 481.70M (arcsize-p)
>
>
> Barry
> ___
> 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"
Ill mark this up on my todo. Thanks for the feedback & I should have
something committed back within the next couple days, possibly even tonight.
I never recalculated for this difference as that area of the code was
just a formatting fix.
But as Jeremy has pointed out, it would have to verify against
__FreeBSD_version but since I already pull in the sysctl MIB
kern.osreldate I should be able to compare to that and say 70 or
higher make the above correction.
As this is mainly ZFS v13 dependent now I don't feel to bad doing what I
have stated above.
Thanks again,
Regards,
--
jhell
___
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: Can't boot after make installworld
On Mon, 22 Mar 2010 07:13, Dan Naumov wrote:
In Message-Id:
The ZFS bootloader has been changed in 8-STABLE compared to
8.0-RELEASE. Reinstall your boot blocks.
P.S: "LOADER_ZFS_SUPPORT=YES" is also deprecated in 8-STABLE, not to
mention that you have it in the wrong place, for 8.0, it goes into
make.conf, not src.conf.
P.S.S: src.conf is the correct place this should be placed but will also
work if placed in make.conf.
As stated in src.conf(5)
---
The src.conf file contains settings that will apply to every build
involving the FreeBSD source tree; see build(7).
The src.conf file uses the standard makefile syntax. However, src.conf
should not specify any dependencies to make(1). Instead, src.conf is to
set make(1) variables that control the aspects of how the system builds.
---
It would be almost to the same effect of doing this at the end of your
make.conf except it has already been done for you elsewhere.
.if ${.CURDIR:M/usr/src*}
.include "/etc/src.conf"
.endif
Is there any particular reason you are upgrading from a production
release to a development branch of the OS?
- Sincerely,
Dan Naumov
Regards,
--
jhell
___
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: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
On Thu, 18 Mar 2010 17:02, O. Hartmann wrote: In Message-Id: <4ba294f7.4030...@mail.zedat.fu-berlin.de> On 03/16/10 00:04, O. Hartmann wrote: On 03/15/10 18:30, Matthew Fleming wrote: Since the last update and make world on Friday, 12th March I get a crash on one of my FreeBSD SMP boxes (it is always the same core message), saying something about Fatal trap 12: page fault while in kernel mode [...] current process: 12 (swi2: cambio) Can you show the stack traceback from the kernel core? We had a problem a while ago at Isilon that I can't tell if it's related. In our case, the camisr() routine was called after panic(9) started and before the halt of other processors. This did Bad Things(TM) since the mtx_lock is a no-op after panicstr is set. We solved it locally by wrapping camisr() in a local cambio_swi() routine that only called camisr(NULL) when panicstr == NULL. Thanks, matthew Hello. I will do as soon as possible. The box is in production at the moment and I've less time to put everything into debugging to provide more details. Just in case: does the kernel automatically save the screen with the dump information? If not, I have no other terminal facility to get a dump via the classical way. Regards, Oliver Since yesterday, this problem went away! This is mystical. After deactivating radeon.ko and the virtual box stuff I tried again with a new build of world and - voila! - everything worked again. This is strange ... Oliver If possible set a dump device and use the following in your rc.conf: crashinfo_enable="YES" dumpdev="ADD-DEVICE-HERE" After the crash happens look for core.txt.N files in /var/crash. You will probably want to look over the crash info and scrub it of vital information to comply with your companies policies. It is very verbose. DDB as I have heard can be configured AFAIR to textdump but I have no knowledge of that. Good Luck, -- jhell ___ 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: Does zfs have it's own nfs server?
On Fri, 19 Mar 2010 20:18, Jeremy Chadwick wrote: In Message-Id: <20100320001820.ga92...@icarus.home.lan> On Fri, Mar 19, 2010 at 07:50:24PM -0400, Charles Sprickman wrote: On Fri, 19 Mar 2010, Willem Jan Withagen wrote: On 17-3-2010 9:27, Matthias Gamsjager wrote: sharenfs does work in freebsd but iscsi does not. I'm not sure about smb. about nfs: you should take a look at /etc/zfs/exports On Wed, Mar 17, 2010 at 9:15 AM, Harald Schmalzbauer wrote: Hello, I observed some very strange filesystem security problems. Now I found that if I set sharenfs=yes data/pub I can mount_nfs but it does't respect any settings in /etc/exports. Also I get very strange uid numbers when writing. If I turn sharenfs off, limitations in /etc/exports work as expected. I thought sharenfs and sharesmb are only working on OpenSolaris. What about shareiscsi? I do not use /etc/exports for zfs shares But instead of yes as value, you can use the NFS-options as string and that gets it into /etc/zfs/exports. Just wondering, is this using the base nfsd/mountd, or is there some in-kernel nfs code strictly for zfs? I haven't found much info on the share* options in the manpage or wiki. ZFS on FreeBSD's "sharenfs" option does nothing more than manage data in a flat file (/etc/zfs/exports) and automatically send a SIGHUP to mountd's pid (based on reading the contents of the file _PATH_MOUNTDPID). If you grep through /usr/src/cddl you can see what I'm referring to. "So how does mountd know about /etc/zfs/exports?" $ ps -auxw | grep mount root 861 0.0 0.0 6836 1716 ?? Is 10Mar10 0:00.00 /usr/sbin/mountd -r -l /etc/exports /etc/zfs/exports This is defined/referenced in /etc/rc.d/mountd. All that said: I avoid use of the "sharenfs" option in ZFS on RELENG_7 and RELENG_8, as I found certain quirks/behavioural oddities (such as mountd not picking up changes, or claims of not exporting something which visually confirmed should have been exported -- and in one case, mounting of a ZFS-exported NFS filesystem worked but then any I/O would block on the client indefinitely. Don't ask me how/why that happened). Possibly these were bugs that existed during ZFS's transitional phase between 7.x and 8.x, but the unreliable nature of the situation left a bad taste in my mouth. The workaround: Using /etc/exports to reference the local ZFS filesystems I want exported, HUP mountd, done. Above oddities/quirks no longer happened. And there's an added bonus: all your exports are therefore kept in one single place: a text file that's existed since what, 1989 or so? Of course, the advantage is that with ZFS properties you can inherit options -- that might be useful to some, but not to me. There's also known quirks/issues with the parsing logic with "sharenfs". This was discussed in December 2009. Could you give an example of passing options that would say, limit to a subnet and map root to root using the zfs sharenfs command? zfs create pool/fs zfs set sharenfs="-maproot=blah -network x.x.x.x -mask y.y.y.y" pool/fs Right now I'm more or less "avoiding" NFS as much as possible, as the number of severe/major bug reports on RELENG_8 keep coming in, and that scares me greatly. There is also this: http://www.freebsd.org/cgi/query-pr.cgi?pr=17 Which I filed a while back that shows a bug in at least stable/7 that does not unshare/remove shared filesystems from /etc/zfs/exports. PJD has taken this PR and asked for a followup if this can be confirmed on a 8.X system as he believes it is fixed there. If someone of this thread is running a 8.X system would you please followup to this PR with YES/NO it exists or not, and it would be greatly appreciated. I believe this also has a part of sending HUP to mountd but I could not test that either on stable/7 or stable/8. -- jhell ___ 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: route -cloning flag
On 3/5/2010 1:44 AM, Matthias Gamsjager wrote: > One thing is sure. the route won't survive a reboot. Guess you can add > it to rc.conf but I have never tried it. > check /etc/defaults/rc.conf for static_routes and its usage. Maybe you already know about this but I wanted to double check with you just in case. rc.conf(5) also has a example usage. > On Thu, Mar 4, 2010 at 5:04 PM, Iasen Kostov wrote: >> On Thu, 2010-03-04 at 17:28 +0200, Iasen Kostov wrote: >>> Hi, >>> >>> How can I simulate 'route add -net 1.1.1.1/32 -cloning -iface fxp0' on >>> FreeBSD 8.x because it appears that somebody has axed cloning ? >>> And no it does NOT work without -cloning. And I don't really want to >>> argue if it is correct or not - It worked not it doesn't ;) >>> >>> Regards, Iasen. >>> >> >> Hum when I actually got to the machine and added the route it worked >> without -cloning. I can Only guess that the on site support did >> something wrong but I really don't know what mistake can they make in >> that simple command (route add -net 1.1.1.1/32 -iface fxp0) ;) . I hope >> it will still works after reboot ... And the man page is wrong, It >> still lists -cloning as valid option, with that in mind and remote >> server one can easily lock himself out :( >> >> Regards, Iasen. >> -- jhell ___ 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: usr/sbin/service False positives
On Sat, 6 Mar 2010 00:36, dougb@ wrote: On 3/5/2010 9:26 PM, jhell wrote: Hi Doug, FreeBSD 7.3-STABLE i386 r204701 Ive been getting the following (below sig) false positives from logcheck recently (moreso log/messages) from service(8). Is there any way that this could be worked around? This messages happen after a reboot and I am presuming that it might be because of the user of -i to env but I am unsure at this point and wanted to give a heads-up before 7.3-RELEASE. These services had never given warnings to messages before the use of service(8). I don't understand, how are you using the service command? It's not used by anything in the system, it's just a command line tool for administrators. Doug Ugh! Please ignore any message coming from me in the next 10 minutes ;) I was writing some service checks utilizing periodic about 1 month ago and doing so I was dragging in rc.subr and doing a load_rc_config and that's where the WARNING was coming from. Before I suspended that project for a month I forgot to disable that piece. Sorry for the noise. Thanks anyway, -- jhell ___ 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"
usr/sbin/service False positives
Hi Doug, FreeBSD 7.3-STABLE i386 r204701 Ive been getting the following (below sig) false positives from logcheck recently (moreso log/messages) from service(8). Is there any way that this could be worked around? This messages happen after a reboot and I am presuming that it might be because of the user of -i to env but I am unsure at this point and wanted to give a heads-up before 7.3-RELEASE. These services had never given warnings to messages before the use of service(8). # grep WARNING: /var/log/messages Regards, -- jhell -- Forwarded message -- Date: Mon, 1 Mar 2010 10:02:11 Subject: centel 2010-03-01 10:02 Security Events System Events =-=-=-=-=-=-= Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $idled_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $mpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $mysql_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $racoon_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $samba_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $snmpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $snmptrapd_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $snort_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $socks5_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $apache22_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $asterisk_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $avahi_daemon_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $avahi_dnsconfd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $ddclient_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $dictd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $dovecot_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $ffserver_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $flow_capture_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $flow_fanout_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $git_daemon_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $hald_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $miniupnpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $openbgpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $openospfd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $spamd_enable is not set properly - see rc.conf(5). ___ 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: Plans for BIND and DNSSEC readiness
On Mon, 22 Feb 2010 00:12, dougb@ wrote: PGP Command Output gpg: Signature made Mon Feb 22 00:12:14 2010 EST using DSA key ID D5B2F0FB gpg: Good signature from "Doug Barton " gpg: aka "Doug Barton " gpg: aka "Doug Barton " --- Begin PGP Signed Message Verified 2010-02-25 21:12:11 -- I've made a post to -arch regarding my plans for BIND in the base, along with some information about getting ready for DNSSEC, including the upcoming signing of the root zone. You can find the message at http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html. If you have any feedback regarding any of these topics, please follow up to that thread. Regards, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ End PGP Signed Message Verified 2010-02-25 21:12:11 --- Little late for a reply, But thanks for keeping this updated as this is obviously very important information that not everyone usually comes across. At least I didn't hear anything about it till now. Thanks Doug, -- jhell ___ 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: ZFS tuning [was: hardware for home use large storage]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to the nature of this thread and its current list involvement I am going to be starting a new thread in freebsd-filesystems@ just for arc_summary.pl tomorrow night with the subject below. [arc_summary.pl] Adjustments, PR & Requests I would appreciate if you would join me there for any response or problems that may arise for the use of this script. I don't feel that this list is any longer the correct place to hold this discussion as it is more ZFS centric than stable@ was meant for. If someone would like to start the subject off before I get to it please feel free. Thanks in advance. - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe9OTAAoJEJBXh4mJ2FR+LdwH/0cCwnsWogtHfGyU4PJcu1fG PV/PxpgMKQsTIfckGI8ef/UPCG7lki6FD9+bPrsOrFy2ZuvGhK+jfxXsa+99Rt4h ovi6qopLjfHde9Ztd87E3Ds88kR0KEszdnDvbg7mr/xAz9V7hFrLWvmIqxaedg06 I+j932tUfFmA2xiExBWVjtHfdYD2YaO671SET0nPSGz0b6yRlfedOvTZvheI+l05 fB1pXQNwve1en6oDtBBb0pgoODI9HgrZyrQbJzTFH/hXremdO5Dv5AUULI/XKwNA KSSWRMRKYODdX7cDIDbS2+7GjLj1V85gdBc10usR4AqpSFl8aGmTIUfK187y+qs= =7QZB -END PGP SIGNATURE- ___ 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: ZFS tuning [was: hardware for home use large storage]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 17 Feb 2010 04:53, jhell@ wrote:
PGP Command Output
gpg: Signature made Wed Feb 17 04:53:27 2010 EST using RSA key ID 89D8547E
gpg: Good signature from "jhell "
--- Begin PGP Signed Message Verified 2010-02-17 06:13:53 --
On Wed, 17 Feb 2010 03:56, bartosz.stec@ wrote:
On 2010-02-17 09:32, Torfinn Ingolfsen wrote:
On Wed, 17 Feb 2010 09:19:49 +0100
Bartosz Stec wrote:
So here's my reply (last line seems most interesting ;) :
[...snipped...]
Illegal division by zero at ./arc_summary.pl line 242.
FWIW, I also got this line when I ran this script on my idle zfs server.
I'm not a PERL programmer (or programmer at all ;), but what I see is
script
doesn't check if L2ARC is used at all, so it will always try compute these
lines:
printf("\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_hits / ( $l2_hits
+
$l2_misses )), $l2_hits );
printf("\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_misses / (
$l2_hits
+ $l2_misses )), $l2_misses );
printf("\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_feeds / (
$l2_hits
+ $l2_misses )), $l2_feeds );
Without active L2ARC it will always generate divide at zeo error, so it
seems
that additional check for usable L2ARC values is needed at first place.
Thanks for reporting this. As I am usually on a system that is using a
L2ARC I wouldn't have noticed it.
I should have this fixed in about 10 hours. But as I am writing this email
I am heading off to bed, work calls in the morning.
Check back tomorrow night for a updated version and adjust the current to
your liking for the moment.
;) Thanks again.
--
jhell
End PGP Signed Message Verified 2010-02-17 06:13:53 ---
I take that back.
I just uploaded a modified version that I wrapped with a if statement to
check and see if l2_hits >= 0.
If you don't have a L2ARC you will now get a message explaining why its not
included in your summary.
I couldn't sleep until I fixed this knowing that more people are probably
going to come across this problem and email back.
New rev: 184
MD5 (arc_summary.pl) = f47bac165e7bf707d5f81cfdd007c30a
SHA256 (arc_summary.pl) =
794dce069ff649598d99204b362d141a19da47dcf60ec165b260d55a5c9d493f
SIZE (arc_summary.pl) = 12695
http://jhell.googlecode.com/files/arc_summary.pl
http://jhell.googlecode.com/files/arc_summary.pl.asc
Now I can finally sleep ;)
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLe9BrAAoJEJBXh4mJ2FR+0K8IAKA43hk95Kll9mLfMWj5bUPp
ZLlDzZPPy30Ign6wfbSO0wImLW0UVa9wAL0EwWb78F9T/3AJ2fQZFgWrOp/t+eV4
iKG8rsEy6t6YDYYZ7G6XnSibiCO+M+L+b6eSWMbcl/Ak8n+1PZUQisFevq/K0cCu
31ktjNxC6eqK1s0rKn/CgyXKO/rga60U12OHG9SLInM8J1dtHSGAp6kBO0B6C9+m
uzEKOkUxXlYZpo+vlR9alByPWfiG9JqkgiYcOeXcgo0kb405cVT5jwBrOY9UnTb8
phxY6RXUViGP/quX2P+tGIYO47gDvBiGY/XRyTO1bmM+O0nPTnnKHpJg9NBvZ/g=
=OFDn
-END PGP SIGNATURE-
___
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: ZFS tuning [was: hardware for home use large storage]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 17 Feb 2010 03:56, bartosz.stec@ wrote:
On 2010-02-17 09:32, Torfinn Ingolfsen wrote:
On Wed, 17 Feb 2010 09:19:49 +0100
Bartosz Stec wrote:
So here's my reply (last line seems most interesting ;) :
[...snipped...]
Illegal division by zero at ./arc_summary.pl line 242.
FWIW, I also got this line when I ran this script on my idle zfs server.
I'm not a PERL programmer (or programmer at all ;), but what I see is script
doesn't check if L2ARC is used at all, so it will always try compute these
lines:
printf("\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_hits / ( $l2_hits +
$l2_misses )), $l2_hits );
printf("\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_misses / ( $l2_hits
+ $l2_misses )), $l2_misses );
printf("\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_feeds / ( $l2_hits
+ $l2_misses )), $l2_feeds );
Without active L2ARC it will always generate divide at zeo error, so it seems
that additional check for usable L2ARC values is needed at first place.
Thanks for reporting this. As I am usually on a system that is using a
L2ARC I wouldn't have noticed it.
I should have this fixed in about 10 hours. But as I am writing this email
I am heading off to bed, work calls in the morning.
Check back tomorrow night for a updated version and adjust the current to
your liking for the moment.
;) Thanks again.
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLe7yXAAoJEJBXh4mJ2FR+NyAH/jBS6W0b9tZZVOm5nQ+kmjG2
CZxWqkkNe6ldQ3ggdmSNlz324Vr+6ZpHvLHjlpRDloyCEX2//9exzpDAMY/3yYL/
4hrY7WeaAVDhwaCmvVxyiuP3QFnF1ENl+mMBxpbc6sYoYpDJ1900qh/0FFFjIRxm
V9vaBWl1vYzLxiAp55b+UBLI5NNPEKTJgxQMBAflh24A3KuDtNijS23EEeA/g2vq
eZorXS/55n5ZJxVWXMOn0i9IKdpn0sYPu5xoMWCihKxN6KRnighBfr9BIjpXZEEC
rktEX4wY4bOMpULQJff/9MAjlisq5jvsY7JulYHX22D+HjC4/Z3TLQ/RVCI2d5Q=
=GRta
-END PGP SIGNATURE-
___
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: ZFS tuning [was: hardware for home use large storage]
On Tue, 16 Feb 2010 12:59, freebsd@ wrote:
On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote:
On 2/15/10 7:49 PM, jhell wrote:
As I make final modifications to the script I will keep the below URLs
updated and welcome any bug reports or modification requests to me
personally.
Here is the URLs:
http://jhell.googlecode.com/files/arc_summary.pl
http://jhell.googlecode.com/files/arc_summary.pl.asc
Nice. How about including relevant lines from /boot/loader.conf,
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";
}
}
Yes, it should more or less duplicate the sysctl values, but it may
make it more obvious where the settings are coming from, or if the
user has bad or ignored settings
Major problems with the above code:
1) Opens /boot/loader.conf for rw access; should be read-only
2) Makes the assumption /boot/loader.conf exists
3) Does not close the fd
4) Excessively quotes variables for no justified reason
5) Makes some bad assumptions about the contents of the file (ex.
comments with the word "zfs" in them would match)
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()...
Very nice!,
Ill keep this for reference later on. This might just come in handy at
some point.
But for the sake of arc_summary.pl I feel this is beyond the scope of what
its intended use is. See previous email in response to Barry.
Thanks Jeremy
--
jhell
___
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: ZFS tuning [was: hardware for home use large storage]
On Tue, 16 Feb 2010 12:06, bp@ wrote:
On 2/15/10 7:49 PM, jhell wrote:
As I make final modifications to the script I will keep the below URLs
updated and welcome any bug reports or modification requests to me
personally.
Here is the URLs:
http://jhell.googlecode.com/files/arc_summary.pl
http://jhell.googlecode.com/files/arc_summary.pl.asc
Nice. How about including relevant lines from /boot/loader.conf, 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";
}
}
Yes, it should more or less duplicate the sysctl values, but it may make it
more obvious where the settings are coming from, or if the user has bad or
ignored settings
Barry
Hi Barry,
This is a very nice idea so please do not get me wrong when I say
that I would rather stay away from having to open config files and start
comparing results. I don't feel that this is in the place of the script to
do this type of action and can lead to confusion upon the users behalf.
sysctl(8) is by far better off getting the values from a running system
rather than parsing values obtained from a file that does not change the
system except for after a reboot upon which the values outlined in
loader.conf can be obtained from sysctl mibs.
The latest version of the script that I have uploaded has the sysctl mibs
spilled out at the bottom. These are mibs that I felt were relevent to the
tuning of ZFS and FreeBSD obtained from various sources and memory recall
so I might have missed a few so if you or anyone else has a mib to be
added please forward them to me in a email and I will be sure to add it.
Regards, and thanks for the feedback.
--
jhell
___
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: ZFS tuning [was: hardware for home use large storage]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 16 Feb 2010 16:56, freebsd@ wrote: On Wed, Feb 17, 2010 at 07:05:11AM +1100, Peter Jeremy wrote: Overall, Barry's script makes an excellent proof-of-concept - which is what he was offering. You know, I had a verbose in-line response typed up, agreeing with some points of yours and disagreeing with others (with perlfaq and other reference material), but decided... fuck it! :-) Lol, (anyway)... To all those involved in this. More up-to-date: arc_summary.pl r182 I have done some more minor formatting with the heading section. I have added some L2 ARC stats. Adjusted called binaries to have full paths for the moment until I get around to fixing it a little more. Not having the full path caused some frustrations with emailing the output while running from cron. If this will be a problem with anyone running it and you come across errors where something can not be executed please be patient as I will have this adjusted soon. arcstat.pl: Please update the WiKi with the missing URL, I uploaded the original FreeBSD modified copy of arcstat.pl script to the same location as arc_summary.pl in case anyone wants to grab that file for FreeBSD while they are their. I have also signed this file with my public key. I won't be making any mods to this script as I see it works as intended. I may be persuaded in the future to make adjustments to keep it working and small bug fixes. http://jhell.googlecode.com/files/arc_summary.pl http://jhell.googlecode.com/files/arcstat.pl MD5 (arc_summary.pl) = 6587be39266bd131ed5f4611f321c9e2 SHA256 (arc_summary.pl) = fea99963562e1caee01d6ccd9af1b592cb18fcfaf81308bd1ee21c546c8290ad SIZE (arc_summary.pl) = 12875 MD5 (arcstat.pl) = 9b7d7b4d52ba997c7c59bc0afaca8aa9 SHA256 (arcstat.pl) = b97fc59460468bb2bab6d53009e67f2de87fd5817e7b5656266ea4fd75079b2a SIZE (arcstat.pl) = 8172 Best regards. And watching for replies, - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe6G9AAoJEJBXh4mJ2FR++mYIAJXgJ468WX65PErzYiNySmB/ Sliz5Qur7kpqeP/LHuJHXk/FG+JaaQJQbh/9vIsX2zoqnBK7gqyqTOdv2pw+sKff PNcwdhYbJXEYTnGorj4FXmEI4IkXfuYM281nEpytSVU1CLTnL8oeWU9YRFTw0Fhh Gtvcy2jSnOmjjARt/0Ot1PKfOE9/PTghBTjvmGJIUz11evKsacZmXEIpv1P3KnS9 XMmeDjARkMpXCqDsBPPWeD/YYWUW6SA3Iq+BP0CeVqk7ytQ/q2WI7wH5pC+EscTx dLczky3GR5TeeHrRVQCKWVzQGoxQFH85X2MGipgOae6viHHC+Nk2J1cKVWhLx5s= =zRvh -END PGP SIGNATURE- ___ 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: ZFS tuning [was: hardware for home use large storage]
On Tue, 16 Feb 2010 13:30, mattjreimer@ wrote: On Mon, Feb 15, 2010 at 5:49 PM, jhell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It is funny that you guys are all of a sudden talking about this, as I was just working on some modifications to the arc_summary.pl script for some better formatting and inclusion of kmem statistics. My intent on the modifications is to make the output more usable to the whole community by revealing the relevant system information that can be included in an email to the lists for diagnosis by others. ... Example output: - - System Summary OS Revision:199506 OS Release Date:703100 Hardware Platform: i386 Processor Architecture: i386 Storage pool Version: 13 Filesystem Version: 3 Kernel Memory Usage TEXT: 8950208 KiB,8 MiB DATA: 206347264 KiB, 196 MiB TOTAL: 215297472 KiB, 205 MiB Above did you really mean "8950208 B" not KiB, etc.? Matt Yes, Thank you for pointing this out. I have fixed this and it will be added to the the same url as before in about 3 or so hours from the time of this email. This update will also add some stats for L2 ARC as well. Thanks again. -- jhell ___ 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: ZFS tuning [was: hardware for home use large storage]
On Mon, 15 Feb 2010 21:20, fullermd@ wrote: On Mon, Feb 15, 2010 at 08:49:38PM -0500 I heard the voice of jhell, and lo! it spake thus: As I make final modifications to the script I will keep the below URLs updated and welcome any bug reports or modification requests to me personally. Well, here's one: OS Revision:199506 There's no reason to show this; it's just confusing because it'll be misinterpreted. kern.osrevision isn't what you probably think it is. It's just the BSD #define in param.h, which (aside from a blip which was instantly reverted) last changed in 1996 when the -Lite2 import was done. Removed in revision 171, and added output for sysctl tunables to the bottom. Current branches or exact matches of sysctl's that are included are... kern.maxusers vfs.zfs vm.kmem_size vm.kmem_size_max If there is more sysctl's that you think should be added please let me know and I will add and update the script. The new revision(171) is in the same url as before. MD5 (arc_summary.pl) = 29b276a6e2f13eedf5d36370994b7f0e SHA256 (arc_summary.pl) = 15a27b9eb71eddd64ee07a515c136f8467783dfb1075d9707028a082387c5127 SIZE (arc_summary.pl) = 9449 Regards, -- jhell ___ 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: ZFS tuning [was: hardware for home use large storage]
On Mon, 15 Feb 2010 21:20, fullermd@ wrote: On Mon, Feb 15, 2010 at 08:49:38PM -0500 I heard the voice of jhell, and lo! it spake thus: As I make final modifications to the script I will keep the below URLs updated and welcome any bug reports or modification requests to me personally. Well, here's one: OS Revision:199506 There's no reason to show this; it's just confusing because it'll be misinterpreted. kern.osrevision isn't what you probably think it is. It's just the BSD #define in param.h, which (aside from a blip which was instantly reverted) last changed in 1996 when the -Lite2 import was done. Thanks!, No I did not have any understanding of that till this moment but had included it just for completeness. In that case I will mark that for deletion. Regards, -- jhell ___ 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"
