Re: SB Live 7.1 soundcard trouble
On Tue, Dec 06, 2005 at 09:59:02AM +, Vyacheslav Sotnikov wrote: > Hi list. > I've got trouble with drivers for my soundcard - they dont detect it. > pciconf brings that: > > [EMAIL PROTECTED]:9:0: class=0x040100 card=0x10061102 chip=0x00071102 rev=0x00 > hdr=0x00 > vendor = 'Creative Labs' > device = 'CA0106-DAT Audigy LS' > class= multimedia > subclass = audio > > I has tried standard snd_emu10k1, that shipped with FreeBSD and that is > in ports - /usr/ports/audio/emu10kx/ - they both failed. > > I also try to install OSS from opensound.com and it failed with "kernel > trap 18" while installation. Before trying to install OSS drivers you should first uninstall FreeBSD ones. And make also sure you downloaded drivers for your version of FreeBSD. If nothing helps you can bug OSS people, they are very responsible. -ip -- Self starters --- won't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SB Live 7.1 soundcard trouble
Igor Pokrovsky wrote: >>I also try to install OSS from opensound.com and it failed with "kernel >>trap 18" while installation. > > > Before trying to install OSS drivers you should first uninstall FreeBSD ones. If by uninstalling you mean to kldunload current drivers, that i had do it already, and version of drivers is correct - oss3993c-freebsd-x86-v6.0-RELEASE.tar.gz > And make also sure you downloaded drivers for your version of FreeBSD. > If nothing helps you can bug OSS people, they are very responsible. thank you. i'll try. > > -ip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] nsswitch extensions + caching
Hello! I've made the "nsswitch + caching daemon" project during the Google's Summer of Code. I'm still working on it - there is always a room for improvements :) Since previous release, I've made a lot of changes to the initial version, fixed some bugs, and this version seems to be worth using it :) Here is the the new release of the patch: http://www.rsu.ru/~bushman/nsswitch_cached/nss_cached_rev2.patch The description of the project itself and of its several new features can be found here: http://rsu.ru/~bushman/nsswitch_cached/ Your feedback would be great! Michael Bushkov Rostov State University ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SB Live 7.1 soundcard trouble
Hi, First of all, I'm actually a Linux/Ubuntu user *avoids thrown squidgy fruit* but I have a CA0106 SB Audigy LS and have had no end of trouble with it - working presently, though. I could not get it to work with standard emu10k1 drivers, but to some extent using ALSA. It tended to have buffer issues - to get smooth sound out of xmms I had to use the custom options within xmms to set very high buffers on the output. I invite you to look at http://ubuntuforums.org/showthread.php?t=19307 I'm aware that the L in ALSA stands for linux, and that this method uses apt-get then dpkg to compile then install as a .deb package, but I can testify that this is the only way I have ever seen that has given me seamless sound (currently using eSound daemon) completely OS-wide. Good luck & regards, Thomas K ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rm: Directory not empty ..(had tried chflag ...)
Dear All: I running fsck -y to a device, and I delete some files in the same time . I found there were some files could'nt be delete.. message: rm: old_files: Directory not empty I had tried chflags -R noschg old_files rm -rf old_files thanks in advance ..^^ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rm: Directory not empty ..(had tried chflag ...)
On Tue, Dec 06, 2005 at 07:14:26PM +0800, K.C.Huang-MLC wrote: > Dear All: > I running fsck -y to a device, and I delete some files in the same time . > I found there were some files could'nt be delete.. > > message: > rm: old_files: Directory not empty > > I had tried > chflags -R noschg old_files > rm -rf old_files Did you run fsck until the filesystem is clean? If not try running fsck from single user mode a few more times. Another possibility is that this can sometimes happen with softupdates with fsck running in the background. If you wait for fsck to finish running in the background, then the problem should go away (this has been fixed in more recent FreeBSD releases). David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
scsi-target and the buffer cache
I'm curious about whether a target mode device would use the buffer cache or not. Here's a scenario: Host A: has fibre channel host adapter, in target mode, large memory pool, and another fiber channel host adapter connecting to fibre channel block device. Host B: Fibre channel host adapter, connecting to Host A. 'sees' the target mode block device created by Host A. Will Host A use the buffer cache to cache blocks between the real block device, and the shared target mode device? What about if Host A put a filesystem on the block device, created a single file the size of the filesystem, and shared that filesystem via a target mode device to Host B? What I'm wanting is a box (FreeBSD?) that can be placed between a fibre channel block device (like a RAID array), and a fibre channel host using that block device, and act as a block cache for that device, using the FreeBSD's memory. If it had a significant amount of memory, this could be very useful. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] nsswitch extensions + caching
Michael Bushkov wrote: [...] so, I've been wonderring.. what's all the fuss about nsswitch? what does it get us? (Not saying it doesn't, just hoping someone will explain) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] nsswitch extensions + caching
On Tue, Dec 06, 2005 at 10:46:26AM -0800, Julian Elischer wrote: > Michael Bushkov wrote: > [...] > > so, I've been wonderring.. what's all the fuss about nsswitch? > what does it get us? It gives us the ability use modules to provide arbitrary backends for a variety of interfaces to system databases. For instance getpw*(), gethost*(), etc. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpvpofIPB3WE.pgp Description: PGP signature
Re: [PATCH] nsswitch extensions + caching
In the last episode (Dec 06), Brooks Davis said: > On Tue, Dec 06, 2005 at 10:46:26AM -0800, Julian Elischer wrote: > > Michael Bushkov wrote: > > [...] > > > > so, I've been wonderring.. what's all the fuss about nsswitch? > > what does it get us? > > It gives us the ability use modules to provide arbitrary backends for a > variety of interfaces to system databases. For instance getpw*(), > gethost*(), etc. Michael's patch itself adds caching to our nsswitch implementation, which dramatically improves performance on slow sources (ldaps, for example). -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] nsswitch extensions + caching
I haven't seen much fuss, actually :) Here are some points: 1. Nsswitch makes caching easy. As nsswitch-related calls are done quite often, caching can be very useful. With nsswitch we can organize caching of different types of data (passwd, groups, services, etc) in the quite simple uniform manner. In other OSes caching is usually organized via nscd. The caching daemon (it's implementation is in the patch) is the analogue of the nscd in some way. It has different approach for caching, but can work in the way, the nscd usually works. 2. Nsswitch implementation is not yet completed. There's a number of databases, which can be supported, but their support is not yet implemented. Their support in nsswitch will give us: a) uniform way to configure the data sources to use (via nsswitch.conf) 2) the ability to cache their data 3. More concrete example is /etc/services file. The services database didn't utilize nsswitch/nsdispatch. If it uses nsdispatch, it will be able to cache data from the file - and we'll be able to make it as big as we want. Of course, first "uncached" requests will take some time, but all subsequent requests for the information, that is already in the cache will be extremely fast - they won't event open the /etc/services file. 4. Another concrete example is OpenSSH authroization keys. If we use nsswitch to retrieve them, we can easily use NIS or LDAP as their storage, which is a good thing. I hope, this will satisfy you :) With best regards, Michael - Original Message - From: "Julian Elischer" <[EMAIL PROTECTED]> To: "Michael Bushkov" <[EMAIL PROTECTED]> Cc: ; Sent: Tuesday, December 06, 2005 9:46 PM Subject: Re: [PATCH] nsswitch extensions + caching Michael Bushkov wrote: [...] so, I've been wonderring.. what's all the fuss about nsswitch? what does it get us? (Not saying it doesn't, just hoping someone will explain) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rm: Directory not empty ..(had tried chflag ...)
K.C.Huang-MLC wrote this message on Tue, Dec 06, 2005 at 19:14 +0800: > I running fsck -y to a device, and I delete some files in the same time . > I found there were some files could'nt be delete.. Don't run fsck -y while you have the file system mounted.. if you do, you will end up with troubles like you have... you should make sure to pass -B to fsck if you want to run fsck while the file system is mounted... Though I've never done that manually (I let the rc scripts handle that for me)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
On Monday 05 December 2005 10:52 pm, Craig Boston wrote: > On Mon, Dec 05, 2005 at 07:51:29PM -0600, Craig Boston wrote: > > With the ACPI timer disabled (debug.acpi.disabled=timer), the ACPI+APIC > > case now behaves the same as the plain APIC case. Each IRQ gets > > anywhere from 10,000-500,000 interrupts before it simply stops working. > > And to follow up to myself yet again, the i8254 timecounter is also bad > news for APIC. Switching to it, with or without ACPI, causes things to > stop working really fast. > > Just a stab in the dark, but it sounds like there may be something > screwy going on in the interconnect between the I/O APIC and the 8259s. > I'm pretty familiar with old-style (ISA) design, but somewhat fuzzy on > exactly how those two normally coexist, especially when everything is > integrated together on a bridge chip somewhere. > > IIRC there used to be some mixed-mode hacks that have been cleaned up in > 6.0. Might Windows still be doing something similar and that's why it > works? No, Windows doesn't use mixed mode. That stuff only had to do with routing IRQ0 anyways. We use the lapic timer instead of IRQ0 now (as does Windows). -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-target and the buffer cache
Eric Anderson wrote: I'm curious about whether a target mode device would use the buffer cache or not. Here's a scenario: Host A: has fibre channel host adapter, in target mode, large memory pool, and another fiber channel host adapter connecting to fibre channel block device. Host B: Fibre channel host adapter, connecting to Host A. 'sees' the target mode block device created by Host A. Will Host A use the buffer cache to cache blocks between the real block device, and the shared target mode device? What about if Host A put a filesystem on the block device, created a single file the size of the filesystem, and shared that filesystem via a target mode device to Host B? What I'm wanting is a box (FreeBSD?) that can be placed between a fibre channel block device (like a RAID array), and a fibre channel host using that block device, and act as a block cache for that device, using the FreeBSD's memory. If it had a significant amount of memory, this could be very useful. If you use the example scsi_target usermode (usr/share/examples/scsi_target), then the buffer cache will be used since its reads/writes are from usermode like normal. If you don't want that behavior, you can set O_DIRECT in the open() call of the backing store file. If you chose to modify the kernel side, you'd have to make sure your accesses were through the VOP layer and then it would be cached. You should check to be sure the target mode performance meets your expectations also. -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
twm doesn"t start with vnc server on FreeBSD l5.4/amd64
I am using FreeBSD5.4/amd5.4 but any windows manager doesn"t start with vnc server. FreeBSD5.4/amd64 has any troubles with X windows? FreeBSD5.4/i386 workede well with vnc and twm. - Original Message - From: "John Baldwin" <[EMAIL PROTECTED]> To: "Craig Boston" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, December 07, 2005 5:20 AM Subject: Re: Weird PCI interrupt delivery problem > On Monday 05 December 2005 10:52 pm, Craig Boston wrote: > > On Mon, Dec 05, 2005 at 07:51:29PM -0600, Craig Boston wrote: > > > With the ACPI timer disabled (debug.acpi.disabled=timer), the ACPI+APIC > > > case now behaves the same as the plain APIC case. Each IRQ gets > > > anywhere from 10,000-500,000 interrupts before it simply stops working. > > > > And to follow up to myself yet again, the i8254 timecounter is also bad > > news for APIC. Switching to it, with or without ACPI, causes things to > > stop working really fast. > > > > Just a stab in the dark, but it sounds like there may be something > > screwy going on in the interconnect between the I/O APIC and the 8259s. > > I'm pretty familiar with old-style (ISA) design, but somewhat fuzzy on > > exactly how those two normally coexist, especially when everything is > > integrated together on a bridge chip somewhere. > > > > IIRC there used to be some mixed-mode hacks that have been cleaned up in > > 6.0. Might Windows still be doing something similar and that's why it > > works? > > No, Windows doesn't use mixed mode. That stuff only had to do with routing > IRQ0 anyways. We use the lapic timer instead of IRQ0 now (as does Windows). > > -- > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/usr/ports/sysutils/sge is broken ? for amd 64
I am trying to install Sun Grid Engine with FreeBSD5.4/amd64. It needs glibc-common-2.3.2-4.80.8.amd64.rpm glibc-common-2.3.2-4.80.8.i386.rpm can be found in ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/rpm/i386/8.0/ but amd64. Where can I get glibc-common-2.3.2-4.80.8.amd64.rpm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
