Re: Buzzing snd_emu10kx enabled card with r206173
On Wed, May 26, 2010 at 12:05 PM, Mark Stapper wrote: > On 25/05/2010 20:05, Garrett Cooper wrote: >> On Tue, May 25, 2010 at 3:06 AM, Mark Stapper wrote: >> >>> On 18/05/2010 08:14, Mark Stapper wrote: >>> On 18/05/2010 00:22, Garrett Cooper wrote: > On Mon, May 17, 2010 at 11:21 AM, Mark Stapper wrote: > > > >> I have the same problem. >> I'll try compiling the driver in the kernel. >> > FWIW I've compiled the driver into the kernel for several > iterations now and it works like a champ, so there's something with > the sound subsystem that isn't jiving properly when loading from > modules... > HTH, > -Garrett > > > Thanks for the info. I've noticed that when I load the kernel module at startup (by adding it to loader.conf) chances of it working improve. If I load it afterwards, the nice huff puff sounds come out of my speaker again. Compiling the new and improved kernel today. Thanks for your help. >>> >>> I compiled the emu10kx driver into the kernel. >>> That seemed to work, but now the hissing and buzzing is back. >>> I really don't know what is going on anymore.. >>> Any thoughts? >>> >> What modules have you compiled and loaded? > > Kernel config and kldstat output pasted below > [...] > Everything I saw there appeared sane (it would have been nice to grab the -v output from kldstat, but that's ok...). Let's try doing the following: 1. Add `options EMU_MTX_DEBUG' to your kernconf. 2. Add set the sysctl: dev.emu10kx.0.debug=1 . Let's see if anything changes... Also, if you could provide some more hardware stats (say dmesg.boot and/or devinfo -v) and version stats (I already know that you're running amd64 from your kernel config) for the OS that would be helpful as well. I'm going to try upgrading my kernel and I'll try these steps as well. The locking between this driver and some other sound drivers isn't exactly the same (interestingly enough this driver uses Giant locking for some bits, while the ich one doesn't), and there were some past bugs with other branches of *BSD's drivers related to pci bus commands, etc; the other BSDs have dramatically different soundsystems -- I assume the old school soundsystem, s.t. the issues are probably not the same. Thanks, -Garrett ___ 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?
Hi, Kirk, On Sat, May 29, 2010 at 1:07 PM, Kirk Strauser wrote: > I found some nice scripts to regularly snapshot all the filesystems in my > ZFS pool at > http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs > . One thing bothers me, though: I have to intentionally set how many months' > worth of snapshots I want to keep. Too many and I run out of room. Too few > and I lose some of the benefits of easy recovery of deleted data. My > computer is better at bookkeeping than I am, so why not let it? > > I'd propose standardizing on an attribute like org.freebsd:allowautodestroy. > Modify ZFS's disk full behavior to scan for snapshots with that attribute > set and destroy the oldest one, and continue until there's enough free space > to complete a write requests or until out of "expendable" snapshots to > destroy (at which time the normal disk full handler would run). Also run a > daily periodic script to ensure that the free space stays below a > configurable threshold each day so that ZFS isn't constantly butting up > against completely full drives. > > This would take all configuration guesswork out of the equation and would > let me keep as many snapshots as I have space to maintain. If I want to > extend my reach back in time, I can add another drive to the pool and the > rest is handled automatically. At the same time, should I suddenly *want* to > store massive amounts of new data, the snapshots can be easily and > automatically cleared out to make room for the stuff I want to hold. > > What do you think? It seems like this should be pretty easy to implement > without requiring any upstream changes or new FreeBSD-only data structures. > The whole thing could possibly be implemented in userspace, but I don't know > that ZFS has any exception handling callbacks that would make it easy. > > An unused resource is a wasted resource, right? I think this sounds like a good idea but I think we may probably want to explore a more general mechanism, e.g. a daemon that "listen"s system events like file system full, etc. and execute some user defined actions. One thing that we want to avoid is that by making the "automatic recycle" we would open a new race between system and user backup programs, i.e. if you remove an intermediate snapshot, 'zfs send' may fail at receiving side, if incremental send is being used. We would need a way to "notify" that a 'zfs send' is underway. Cheers, -- Xin LI http://www.delphij.net ___ 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 Sat, May 29, 2010 at 1:07 PM, Kirk Strauser wrote: > I found some nice scripts to regularly snapshot all the filesystems in my > ZFS pool at > http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs > . One thing bothers me, though: I have to intentionally set how many months' > worth of snapshots I want to keep. Too many and I run out of room. Too few > and I lose some of the benefits of easy recovery of deleted data. My > computer is better at bookkeeping than I am, so why not let it? > > I'd propose standardizing on an attribute like org.freebsd:allowautodestroy. > Modify ZFS's disk full behavior to scan for snapshots with that attribute > set and destroy the oldest one, and continue until there's enough free space > to complete a write requests or until out of "expendable" snapshots to > destroy (at which time the normal disk full handler would run). Also run a > daily periodic script to ensure that the free space stays below a > configurable threshold each day so that ZFS isn't constantly butting up > against completely full drives. > > This would take all configuration guesswork out of the equation and would > let me keep as many snapshots as I have space to maintain. If I want to > extend my reach back in time, I can add another drive to the pool and the > rest is handled automatically. At the same time, should I suddenly *want* to > store massive amounts of new data, the snapshots can be easily and > automatically cleared out to make room for the stuff I want to hold. > > What do you think? It seems like this should be pretty easy to implement > without requiring any upstream changes or new FreeBSD-only data structures. > The whole thing could possibly be implemented in userspace, but I don't know > that ZFS has any exception handling callbacks that would make it easy. > > An unused resource is a wasted resource, right? So basically you're saying deal with an LRU snapshot deletion when you reach a certain threshold of free space, type scheme? This might get tricky, but it does lend itself to other systems I suppose (I hate to mention it, but the best one I can think of is Windows' system restore... there might be something else available with OSX's Time Machine). What would be more tricky is when the automated system is filling in a bunch of useless snapshots unnecessarily, but as you'd be providing the snapshot criteria, I suppose that you would know what snapshots you want to save and what ones you want to toss... It's an interesting thought though -- just increases the overall complexity of the system and may only meet one need. Cheers, -Garrett ___ 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?
In the last episode (May 29), Kirk Strauser said: > I found some nice scripts to regularly snapshot all the filesystems in my > ZFS pool at > http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs > . One thing bothers me, though: I have to intentionally set how many > months' worth of snapshots I want to keep. Too many and I run out of > room. Too few and I lose some of the benefits of easy recovery of > deleted data. My computer is better at bookkeeping than I am, so why not > let it? > > I'd propose standardizing on an attribute like > org.freebsd:allowautodestroy. Modify ZFS's disk full behavior to scan for > snapshots with that attribute set and destroy the oldest one, and continue > until there's enough free space to complete a write requests or until out > of "expendable" snapshots to destroy (at which time the normal disk full > handler would run). Also run a daily periodic script to ensure that the > free space stays below a configurable threshold each day so that ZFS isn't > constantly butting up against completely full drives. 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). -- Dan Nelson dnel...@allantgroup.com ___ 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: Floppy drive not detected after 8.0-RELEASE->8.1-PRERELEASE
Jung-uk Kim wrote: On Friday 28 May 2010 03:35 pm, Scott Allendorf wrote: Andriy Gapon wrote: on 28/05/2010 19:32 Scott Allendorf said the following: I recently upgraded to 8.1-PRERELEASE (amd64) on a Dell Optiplex 960 running 8.0-RELEASE. After the upgrade, my floppy drive was no longer detected. After a binary search, the following commit appears to be responsible: http://svn.freebsd.org/viewvc/base?view=revision&revision=203544 Can you check if reverting of MFC of the following helps (it's a part of that big ACPI MFC)? r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3 lines Remove _FDE quirk handling as these quirks are automatically repaired by ACPICA layer since ACPICA 20091214. Thank you for your quick reply to my message. Reverting this change (src/sys/dev/fdc/fdc_acpi.c from 1.13.2.2 to 1.13.2.1) appears to have fixed the issue. The floppy drive is now detected and it is functional. There do not appear to be any side effects. Please try the attached patch. Sorry, it was stupid. :-( Jung-uk Kim Applying the patch to r200554 of fdc_acpi.c (1.13.2.2) appears to fix the issue. Once again, the floppy drive is detected and it is functional. There do not appear to be any side effects. Thank you, Scott -- Scott C. Allendorf Email: scott-allend...@uiowa.edu UNIX Systems Administrator Office: 216A Van Allen Hall Department of Physics and AstronomyVoice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479ICBM: 41 39 43.6 N 91 31 55.1 W smime.p7s Description: S/MIME Cryptographic Signature
Re: Floppy drive not detected after 8.0-RELEASE->8.1-PRERELEASE
On Fri, May 28, 2010 at 07:07:04PM -0400, Jung-uk Kim wrote:
> On Friday 28 May 2010 03:35 pm, Scott Allendorf wrote:
> > Andriy Gapon wrote:
> > > on 28/05/2010 19:32 Scott Allendorf said the following:
> > >> I recently upgraded to 8.1-PRERELEASE (amd64) on a Dell Optiplex
> > >> 960 running 8.0-RELEASE. After the upgrade, my floppy drive was
> > >> no longer detected. After a binary search, the following commit
> > >> appears to be responsible:
> > >>
> > >>
> > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=203544
> > >
> > > Can you check if reverting of MFC of the following helps (it's a
> > > part of that big ACPI MFC)?
> > >
> > > r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3
> > > lines Remove _FDE quirk handling as these quirks are
> > > automatically repaired by ACPICA layer since ACPICA 20091214.
> >
> > Thank you for your quick reply to my message.
> >
> > Reverting this change (src/sys/dev/fdc/fdc_acpi.c from 1.13.2.2 to
> > 1.13.2.1) appears to have fixed the issue. The floppy drive is now
> > detected and it is functional. There do not appear to be any side
> > effects.
>
> Please try the attached patch. Sorry, it was stupid. :-(
>
> Jung-uk Kim
> --- sys/dev/fdc/fdc_acpi.c(revision 208626)
> +++ sys/dev/fdc/fdc_acpi.c(working copy)
> @@ -96,6 +96,7 @@ fdc_acpi_attach(device_t dev)
> {
> struct fdc_data *sc;
> ACPI_BUFFER buf;
> + ACPI_OBJECT *obj;
> device_t bus;
> int error;
>
> @@ -131,7 +132,8 @@ fdc_acpi_attach(device_t dev)
> }
>
> /* Add fd child devices as specified. */
> - error = fdc_acpi_probe_children(bus, dev, buf.Pointer);
> + obj = buf.Pointer;
> + error = fdc_acpi_probe_children(bus, dev, obj->Buffer.Pointer);
>
> out:
> if (buf.Pointer)
Works for me as well.
pgppFzTOleOxX.pgp
Description: PGP signature
Make ZFS auto-destroy snapshots when the out of space?
I found some nice scripts to regularly snapshot all the filesystems in my ZFS pool at http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs . One thing bothers me, though: I have to intentionally set how many months' worth of snapshots I want to keep. Too many and I run out of room. Too few and I lose some of the benefits of easy recovery of deleted data. My computer is better at bookkeeping than I am, so why not let it? I'd propose standardizing on an attribute like org.freebsd:allowautodestroy. Modify ZFS's disk full behavior to scan for snapshots with that attribute set and destroy the oldest one, and continue until there's enough free space to complete a write requests or until out of "expendable" snapshots to destroy (at which time the normal disk full handler would run). Also run a daily periodic script to ensure that the free space stays below a configurable threshold each day so that ZFS isn't constantly butting up against completely full drives. This would take all configuration guesswork out of the equation and would let me keep as many snapshots as I have space to maintain. If I want to extend my reach back in time, I can add another drive to the pool and the rest is handled automatically. At the same time, should I suddenly *want* to store massive amounts of new data, the snapshots can be easily and automatically cleared out to make room for the stuff I want to hold. What do you think? It seems like this should be pretty easy to implement without requiring any upstream changes or new FreeBSD-only data structures. The whole thing could possibly be implemented in userspace, but I don't know that ZFS has any exception handling callbacks that would make it easy. An unused resource is a wasted resource, right? ___ 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"
Wireless Card Driver
I just completed the update to 8.1 Beta 1 in hopes that there would be a driver for the wireless card. No luck. The update went just fine. No problems observed so far. pciconf shows: no...@pci0:3:0:0: class=0x028000 card=0x27901814 chip=0x07811814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp.' device = 'Wireless (RT2860/RT2890)' class = network Is there a driver not installed by default that works for this unit?___ 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: AHCI timeouts on S3 resume
(For the archives...) Before posting this to acpi@, I updated my system to r208630, and tried to reproduce the issue with verbose logging. No such luck: the AHCI timeouts are now gone! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 8.1-BETA1 Available...
The first of the test builds for the FreeBSD 8.1 release cycle is now available for amd64, i386, ia64, powerpc, pc98, and sparc64 architectures. Files suitable for creating installation media or doing FTP based installs through the network should be on most of the FreeBSD mirror sites by now. MD5/SHA256 checksums of the images are at the bottom of this message. The ISOs for this build do not include packages other than the docs. For amd64 and i386 "memstick" images are also available that can be copied to a USB "memory stick" (also called "thumb drive") and used for installs on machines that support booting from that type of media. The target schedule for the release is available here: http://www.freebsd.org/releases/8.1R/schedule.html and the wiki page tracking the current status is here: http://wiki.freebsd.org/Releng/8.1TODO If you find problems you can report them through the normal Gnats based PR system or here on this mailing list. If you are updating an already running machine the CVS branch tag is RELENG_8, or if you prefer SVN use "stable/8". Updates done that way will result in a machine that says it is running "8.1-PRERELEASE". The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 8.0-RELEASE can upgrade as follows: # freebsd-update upgrade -r 8.1-BETA1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 7.x) can also use freebsd-update to upgrade to FreeBSD 8.1-BETA1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 7.x and FreeBSD 8.x. Checksums: MD5 (FreeBSD-8.1-BETA1-amd64-bootonly.iso) = f491aad2302485ee2bb3ff0f1a7517e0 MD5 (FreeBSD-8.1-BETA1-amd64-disc1.iso) = f3e8967854720e2258a395fa6699cd2c MD5 (FreeBSD-8.1-BETA1-amd64-dvd1.iso) = 43f6f0e60b1552a6fd0bb35017dd53f7 MD5 (FreeBSD-8.1-BETA1-amd64-livefs.iso) = 6ada39bf3b58c90adc42e8df226626ab MD5 (FreeBSD-8.1-BETA1-amd64-memstick.img) = 6849e0a969acb3c004d234bde271fff2 MD5 (FreeBSD-8.1-BETA1-i386-bootonly.iso) = f92123989706d2109ebc2ffd386c9696 MD5 (FreeBSD-8.1-BETA1-i386-disc1.iso) = e66848a74dd176bfbb29fd3e40cba5ab MD5 (FreeBSD-8.1-BETA1-i386-disc2.iso) = d6ff7be05dec3909c2e6a0bc5cb41a54 MD5 (FreeBSD-8.1-BETA1-i386-disc3.iso) = d2205b41f3da267d643705d698f814b8 MD5 (FreeBSD-8.1-BETA1-i386-dvd1.iso) = 9d925a0b8c21417843f5d1a5f5c16063 MD5 (FreeBSD-8.1-BETA1-i386-livefs.iso) = 510a08125f22e100a18984198c640f3c MD5 (FreeBSD-8.1-BETA1-i386-memstick.img) = c08e0f9b0f5df9c406b069d8e6087a47 MD5 (FreeBSD-8.1-BETA1-ia64-bootonly.iso) = 18e41d3d24e7b3a51b507a7518401e05 MD5 (FreeBSD-8.1-BETA1-ia64-disc1.iso) = 706c77f3859dc4eb852e709e2aaabc7f MD5 (FreeBSD-8.1-BETA1-ia64-disc2.iso) = 63c64715211f3a1ae4ea6c142e71ad09 MD5 (FreeBSD-8.1-BETA1-ia64-disc3.iso) = ece2835a2c68136d01f706b167aa0d40 MD5 (FreeBSD-8.1-BETA1-ia64-dvd1.iso) = b1913f121343d990a369146863c0fc3f MD5 (FreeBSD-8.1-BETA1-ia64-livefs.iso) = 66bcbb4e946beb12d57f4da78c44acf6 MD5 (FreeBSD-8.1-BETA1-pc98-bootonly.iso) = 27f4c2ddf9a3d945cf218cabef68edc4 MD5 (FreeBSD-8.1-BETA1-pc98-disc1.iso) = d8ab88d88b458f140fce39cec027b892 MD5 (FreeBSD-8.1-BETA1-pc98-livefs.iso) = 37102e8e1f28942a1666b561eede5859 MD5 (FreeBSD-8.1-BETA1-powerpc-bootonly.iso) = 55d85e7e6e5930f0ab68b7be023e8acd MD5 (FreeBSD-8.1-BETA1-powerpc-disc1.iso) = 05c4fa05d7c5478d88a64da7af1f67af MD5 (FreeBSD-8.1-BETA1-powerpc-disc2.iso) = c4a0d44421fd11646839a4eb6e16d32a MD5 (FreeBSD-8.1-BETA1-powerpc-disc3.iso) = 92d07d4ff0f62f88cf1f46bd3ffc0982 MD5 (FreeBSD-8.1-BETA1-sparc64-bootonly.iso) = 2930fb42cd0c626b157abd5f6a60c297 MD5 (FreeBSD-8.1-BETA1-sparc64-disc1.iso) = e115e85a5e83b63142d5f02f44e61e66 MD5 (FreeBSD-8.1-BETA1-sparc64-dvd1.iso) = cf24647bd0e00462bf33423864f942cf MD5 (FreeBSD-8.1-BETA1-sparc64-livefs.iso) = 777c3604d88eae2f3011e80a579416e9 SHA256 (FreeBSD-8.1-BETA1-amd64-bootonly.iso) = 249e9e6c3202a29e000c6df2aea2ed6937aa975a6c7959593fea7b1b1b20c408 SHA256 (FreeBSD-8.1-BETA1-amd64-disc1.iso) = db2f63becc38fadbb2fd1ec29142d4309ad03eb22cafcd6818ac284487bbb580 SHA256 (FreeBSD-8.1-BETA1-amd64-dvd1.iso) = 7ae07967f495bc298f1a7852783b4631fd0fc4a6517fbb60042a4377e977c3e1 SHA256 (FreeBSD-8.1-BETA1-amd64-livefs.iso) = 8502721b505f218b3be2feb1cb1d6d8438b1bf4b3b765ba5154c4ad9a23e6ef1 SHA256 (FreeBSD-8.1-BETA1-amd64-memstick.img) = 92e36b2788f58569ae475d4ad3ec67a9a0c4167abe00b83
