Re: Kerberized NFSv3 incorrect behavior
Rick Macklem wrote: On Fri, 5 Feb 2010, George Mamalakis wrote: Dear all, I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My configuration is based on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is to share filesystems securely through kerberos authentication. Everything works fine, until I try to kdestroy my tickets or kinit to some other user, where the system insists to think that I am the user that initially obtained their ticket. To be more extensive, my story is as follows: [good stuff snipped] and both client and server have the correct entries about each other (and themselves) in their /etc/hosts, so heimdal works just fine. Both client and server have their respective keytabs stored in /etc/krb5.keytab, and I use two users in my example (that both exist in both systems with the same uid,gid): mamalos and testakis. Unless you have applied the experimental patch, a keytab entry is meaningless in the client. Without that, it was assumed that "root" would never "kinit" as anyone. Basically, it was assumed that "root" would only do the mount and a user, like "mamalos" or "testakis" would be logged in and kinit'd as that user. The short answer is that any principal with TGT in the credentials cache for uid==N will be used to authenticate that user. Once authenticated, that "handle" for the user can be used until it expires (up to the server, but usually set to when the TGT that it found in the credential cache is due to expire). So, when I mount the exported filesystem on the client giving: # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server.example.com:/exports on /mnt (nfs) and try to access the share: # ls /mnt ls: mnt: Permission denied I get the error I am expecting, since root does not have any kerberos tickets assigned, yet. Let's see what happens when I kinit as mamalos: Yep, as expected. # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: mama...@example.com Issued Expires Principal Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/exapmle@example.com # ls -la /mnt/ total 8 drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ drwx-- 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 19:06 testakis/ # touch /mnt/mamalos/myfile # ls -la /mnt/mamalos/myfile rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile Which is the exact behavior that is expected. Now when I kdestroy: # kdestroy # klist klist: No ticket file: /tmp/krb5cc_0 # touch /mnt/mamalos/myfilethatshouldnotbe # ls -la /mnt/mamalos/myfilethatshouldnotbe -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 /mnt/mamalos/myfilethatshouldnotbe Yes, this is a "bug/limitation" in the current implementation. I believe that "kdestroy" should do some sort of system call to inform the NFS client that "credentials for uid==N" should be invalidated. This is not implemented in FreeBSD8 (or Linux for that matter, last I checked). I don't know if dfr@ was planning on doing this and whether or not he thinks it is appropriate to do so? Without that implemented, the "handle" continues to work until the server expires it, normally when the TGT for "mamalos" would have expired if you hadn't kdestroy'd it. And I can do everything in that share as if I were still mamalos, even though I kdestroyed my kerberos ticket. The same thing will happen even if I kinit to testakis after that. klist shows testakis' ticket this time, but I am not allowed to access (rwx) tetakis' files/folders, and I still have full control over mamalos' files and folders. In order to be able to do something as testakis, I have to unmount the share and remount it while having testakis' ticket (or having no ticket at all, and giving kinit testakis after mounting the share). Actually, logging in as "testakis" should allow that user to access the mount as "testakis" once kinit'd as "testakis". The trick is that the credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the uid assigned to "testakis"). Same would apply to "mamalos" if that user were logged in with a non-0 uid. I am not an NFS expert, but I suppose that this behavior is not the one to be expected, except if I am missing some fundamental information about kerberized NFS that explains it. Even so, it would be quite unwise to behave so, since even if the users kdestroys their tickets, they have still all permissions as when they obtained their ticket. Yes, as noted above, I believe that "kdestroy" should get rid of the Kerberized NFS "handles" for the corresponding "uid". It's on my "to discuss with dfr and maybe do" list, but unfortunately not near the top of it. (I'd also like to come up with a good way to do initiator credentials from a keytab entry. The experimental patch is considered unacceptable for FreeBSD-current etc
Re: Inmutable bit in some binaries
HI, just another idea: You may want to take a look at integrity checking systems as an alternative, i.e. tripwire. -- PGP Fingerprint: 05C8 AE29 4147 6933 0EA9 C0C9 89B2 5B38 8AC4 D66B ___ 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"
{HEADSUP] ACPICA 20100121 MFC to stable/8
I am going to MFC ACPICA imports up to 20100121 plus some accompanying changes to stable/8 during the next hour. Please be extra attentive to this area during your next update and promptly report any regressions that you might see. Thank you! Here's a link to ACPI-CA changelog: http://www.acpica.org/download/changes.txt Below are some additional technical details. Original Message Subject: acpica in stable/8 Date: Fri, 05 Feb 2010 10:37:06 +0200 From: Andriy Gapon To: freebsd-a...@freebsd.org, Jung-uk Kim I would like to bring version of ACPICA in stable/8 to that of head, that is 20100121. Here's svn status and svn diff outputs for the merge: http://people.freebsd.org/~avg/stable-8-acpi.status.txt http://people.freebsd.org/~avg/stable-8-acpi.diff I've performed this MFC by doing series of svn merges first to sys, then to usr.sbin/acpi. I hope that this is a correct approach. I have some doubts because of heard suggestions that such merges should be done from vendor area. But, OTOH, in head there were direct commits sys to fix consequences of merge from vendor area. Subversion gurus, please advise! Please also check if I haven't forgot to MFC something or maybe MFC-ed something unneeded, or made some other mistake. The change is compile tested on i386 and amd64, and run-tested on amd64, but on a rather 'plain' machine from ACPI point of view. If you would like and are able to test this change, I will greatly appreciate your feedback! Some arguments for doing this MFC (copied from an earlier email to jkim): First, it gets more testing. Then, I think it would be hard to keep it at the current version forever. Because some bugs get discovered and, as people get newer hardware, they are more likely to hit those bugs, and the people will demand fixes :-) And 8-STABLE is expected to have an active life for at least 2 years. And, the more frequent will be the updates, the easier it should be to catch bugs and fix them. One thing is getting a year's worth of changes, another is that of a month. Below is the list of the MFC-ed changes. It was generated in semi-automated fashion, so I might have made a mistake somewhere and the list could be incorrect: r197104 | jkim | 2009-09-12 01:48:53 +0300 (Sat, 12 Sep 2009) | 4 lines MFV:r196804 Import ACPICA 20090903 r197105 | jkim | 2009-09-12 01:49:34 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. r197106 | jkim | 2009-09-12 01:50:15 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. r197107 | jkim | 2009-09-12 01:56:08 +0300 (Sat, 12 Sep 2009) | 2 lines Canonify include paths for newly added files. r197688 | jkim | 2009-10-01 23:56:15 +0300 (Thu, 01 Oct 2009) | 4 lines Compile ACPI debugger and disassembler for kernel modules unconditionally. These files will generate almost empty object files without ACPI_DEBUG/DDB options. As a result, size of acpi.ko will increase slightly. r198237 | jkim | 2009-10-19 19:12:58 +0300 (Mon, 19 Oct 2009) | 2 lines Merge ACPICA 20091013. r199337 | jkim | 2009-11-16 23:47:12 +0200 (Mon, 16 Nov 2009) | 2 lines Merge ACPICA 20091112. r199338 | jkim | 2009-11-16 23:53:56 +0200 (Mon, 16 Nov 2009) | 2 lines Add a forgotten module Makefile change from the previous commit. r200553 | jkim | 2009-12-15 00:24:04 +0200 (Tue, 15 Dec 2009) | 2 lines Merge ACPICA 20091214. 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. r202771 | jkim | 2010-01-21 23:14:28 +0200 (Thu, 21 Jan 2010) | 2 lines Merge ACPICA 20100121. r202773 | jkim | 2010-01-21 23:31:39 +0200 (Thu, 21 Jan 2010) | 2 lines Fix a new header inclusion. In a raw form with some additional info: /head/usr.sbin/acpi:r197106,198237,199337,202771 /head/sys:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/dev/xen/xenpci:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head
Re: uma_zalloc_arg complaining about non-sleepable locks
On Mon, Feb 01, 2010 at 09:46:57AM -0500, John Baldwin wrote: > On Sunday 31 January 2010 11:28:54 am Marius Strobl wrote: > > On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > > > Sorry for the delay, I was trying to avoid rebooting my server. > > > I've setup a similar environment in VirtualBox to test it. > > > > > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl > wrote: > > > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > > > >be a NOP on architectures without strict alignment requirements > > > >for performance reasons. That's generally fine but unfortunately > > > >that way you don't actually exercise the code which caused the > > > >problem before (unfortunately I still don't manage to hit the > > > >unaligned case myself). > > > > > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > > > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > > > >counter should also increase then. > > > > > > I'm not sure what triggers the unaligned case either - I tried > > > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > > > that caused some unaligned accesses (but also completely wedged > > > the VBox host). I also tried copying a pile of files off my > > > NFS client (FreeBSD-8.x/i386) and that also triggered some > > > unaligned accesses without any errors being reported. > > > > > > Currently, I have: > > > vfs.nfs.realign_count: 12 > > > vfs.nfs.realign_test: 188817 > > > > > > I'd say that your patch works. > > > > John, are you okay with that patch? > > http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > > > It's intention is to: > > - Move nfs_realign() from the NFS client to the shared NFS code and > > remove the NFS server version in order to reduce code duplication. > > The shared version now uses a second parameter how, which is passed > > on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > > client requires M_DONTWAIT, and replaces the the previously unused > > parameter hsiz. > > - Change nfs_realign() to use nfsm_aligned() so as with other NFS code > > the alignment check isn't actually performed on platforms without > > strict alignment requirements for performance reasons because as the > > comment suggests only occasionally occurs with TCP. > > - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > > than M_DONTWAIT because it's called with the RPC sp_lock held. > > > > The only downside of the shared nfs_realign() are the combined > > SYSCTL counters but the fact we incremented them non-atomically > > so far I think already indicates that their intention only is a > > rough indication rather than exact values for client and server. > > This all sounds good to me, but isn't M_NOWAIT == M_DONTWAIT? Hmm, reading > the code more closely, it looks like fha_extract_info() was using M_WAIT > rather than M_DONTWAIT previously. Also, I think you should be careful to > use > M_DONTWAIT instead of M_NOWAIT for mbufs, so I would fix that in > fha_extract_info(). > Ah, of course you're right, the above description should have read: Change fha_extract_info() to use nfs_realign() with M_DONTWAIT rather than M_WAIT because it's called with the RPC sp_lock held. and I had also managed to copy&paste M_NOWAIT instead of M_DONTWAIT into fha_extract_info() despite having read mbuf(9) regarding this topic. Thanks for pointing these out. Marius ___ 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: uma_zalloc_arg complaining about non-sleepable locks
On Mon, Feb 01, 2010 at 11:54:54AM -0500, Rick Macklem wrote: > > > On Mon, 1 Feb 2010, John Baldwin wrote: > > >>>I'd say that your patch works. > >> > >>John, are you okay with that patch? > >>http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > >> > >>It's intention is to: > >>- Move nfs_realign() from the NFS client to the shared NFS code and > >> remove the NFS server version in order to reduce code duplication. > >> The shared version now uses a second parameter how, which is passed > >> on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > >> client requires M_DONTWAIT, and replaces the the previously unused > >> parameter hsiz. > > I don't think the client side can use M_WAIT/M_WAITOK if it wants to. > (I believe that it was once called from the socket upcall and that was > why M_DONTWAIT was used, but that isn't how it is called in the client > now.) > > I mentioned this to dfr@ because I use a version shared between client > and server for the experimental one that does M_WAIT, but he didn't > think the regular client needed to be changed. Basically, I think the > current code in the regular client can return ENOMEM for I/O system calls, > which probably isn't what the app. expected. In the NFS client, you end up > with this "do I wait forever?" or "do I return an error to an I/O system > call which an app. doesn't expect" issue cropping up here and there. I > don't know the correct answer to this, but tend to lean in the "wait > forever" direction. Well, as demonstrated by the problem with fha_extract_info() "waiting forever" must also match the locking so I'd rather leave chanGing the regular NFS client to someone who understands it better than I do :) Btw., newnfs_realign() should use #ifdef __NO_STRICT_ALIGNMENT instead of #if defined(__i386__) in order to bypass realigning on platforms which can deal with unaligned accesses. > > >>- Change nfs_realign() to use nfsm_aligned() so as with other NFS code > >> the alignment check isn't actually performed on platforms without > >> strict alignment requirements for performance reasons because as the > >> comment suggests only occasionally occurs with TCP. > >>- Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > >> than M_DONTWAIT because it's called with the RPC sp_lock held. > >> > > Btw, from an historical perspective, this was originally added for the > DEC PMAX port (MIPS R2000), which would trap whenever an unaligned ptr > was used. Then, there was this involved chunk of MIPS assembly code that > worked around the unaligned ptr access and the trap returned. Obviously > this was a major performance hit and happened fairly frequently for NFS > over ISO TP4. As you've seen, it happens infrequently enough over TCP > (back then, I think it was only when the TCP window size ended up really > small, although I'm way out of date on the TCP stack, so I have no idea > now:-) that I'd only do the re-alignment on achitectures that will crash > if it isn't done? > > I missed the beginning of this. Was there crashes occurring because > the alignment wasn't being done or problems because the alignment > wasn't working correctly? (I guess I'm trying to say that, if the > arch works without nfs_realign(), then you might consider just not > doing it for that arch. I suppose that isn't a good enough reason > to not fix the function, though?;-) The original problem with fha_extract_info() was that it didn't realign the mbuf data at all but called nfsm_srvmtofh_xx() which assumes the 4-byte alignment required by XDR. As mentioned above, changing nfs_realign() to use nfsm_aligned() has the effect you propose of not performing the realignment on platforms which can deal with unaligned acesses. Actually one could take this one step further and #ifdef the whole nfs_realign() like you do with newnfs_realign() but nfsm_aligned() already existed and I'm reluctant to rototill foreign code too much. Also the compiler should be smart enough to optimize this down to just incrementing nfs_realign_test when __NO_STRICT_ALIGNMENT is defined. Marius ___ 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: Recent MFC to 7 causes crash on VMware ESXi
John Baldwin wrote, On 02/05/2010 08:27 AM: > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk >> controller the VM just shuts off. The workaround is to change the disk >> controller to the BusLogic type. Still, it used to work up until last >> week. The change was made around January 26th and based on the commits >> that day I'm guessing it's either r203047 or r203073 >> >> I have the same issue with both amd64 and i386 VMs. This affects HEAD >> and 8-STABLE as well and first affected HEAD over the summer. (I just >> worked around it and went about my business at the time. :-/) I've >> attached a dmesg from a kernel before the problem and one from after it >> started. > > What if you set 'hw.clfush_disable=1' from the loader? > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 and they do not see the problem. I have yet to try 3.5u5 to see if this is a non-issue. 3.5 will be supported for awhile longer from VMware. I'm going to try upgrading the box during the week. tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | ___ 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: samba recplacement
On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: hail, I've installed a recent 8-stable with gnome installed. I needed samba and noticed I have samba4-devel installed. but I can't manage to make it a simple file server as I need. so how to change samba package at minimum harm ? do I need to reinstall all ? a simple make fetch in samba33 says I can't as it conflicts with samba4 and some tbd-something (not in the machine right now). is there easy way ? I'd really like to choose samba version ... I've found a thread in gnome@ about this change (from late december). not a solution though. thanks, matheus pretty sure samba 4 is not stable yet. i played with it and it didnt work too well a few months ago. go back to the 3.x branch. thats easy to config. ___ 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: samba recplacement
On Sat, February 6, 2010 23:44, Eric wrote: > On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >> hail, >> >> I've installed a recent 8-stable with gnome installed. I needed samba >> and >> noticed I have samba4-devel installed. but I can't manage to make it a >> simple file server as I need. so how to change samba package at minimum >> harm ? >> >> do I need to reinstall all ? a simple make fetch in samba33 says I can't >> as it conflicts with samba4 and some tbd-something (not in the machine >> right now). >> >> is there easy way ? >> >> I'd really like to choose samba version ... I've found a thread in >> gnome@ >> about this change (from late december). not a solution though. >> >> thanks, >> >> matheus > > pretty sure samba 4 is not stable yet. i played with it and it didnt > work too well a few months ago. go back to the 3.x branch. thats easy to > config. I think this way too, the problem is how to do it in the least painful way. if I deinstall all samba stuff, gnome will fail to work ? matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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: samba recplacement
Nenhum_de_Nos wrote: On Sat, February 6, 2010 23:44, Eric wrote: On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: hail, I've installed a recent 8-stable with gnome installed. I needed samba and noticed I have samba4-devel installed. but I can't manage to make it a simple file server as I need. so how to change samba package at minimum harm ? do I need to reinstall all ? a simple make fetch in samba33 says I can't as it conflicts with samba4 and some tbd-something (not in the machine right now). is there easy way ? I'd really like to choose samba version ... I've found a thread in gnome@ about this change (from late december). not a solution though. thanks, matheus pretty sure samba 4 is not stable yet. i played with it and it didnt work too well a few months ago. go back to the 3.x branch. thats easy to config. I think this way too, the problem is how to do it in the least painful way. if I deinstall all samba stuff, gnome will fail to work ? matheus This is what I did: go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI option. ___ 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: samba recplacement
On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: > Nenhum_de_Nos wrote: >> >> On Sat, February 6, 2010 23:44, Eric wrote: >>> On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: hail, I've installed a recent 8-stable with gnome installed. I needed samba and noticed I have samba4-devel installed. but I can't manage to make it a simple file server as I need. so how to change samba package at minimum harm ? do I need to reinstall all ? a simple make fetch in samba33 says I can't as it conflicts with samba4 and some tbd-something (not in the machine right now). is there easy way ? I'd really like to choose samba version ... I've found a thread in gnome@ about this change (from late december). not a solution though. thanks, matheus >>> >>> pretty sure samba 4 is not stable yet. i played with it and it didnt >>> work too well a few months ago. go back to the 3.x branch. thats easy >>> to >>> config. >> >> I think this way too, the problem is how to do it in the least painful >> way. if I deinstall all samba stuff, gnome will fail to work ? >> >> matheus > > This is what I did: > > go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI option. what I will loose in functionality ? I'd have to rebuild it all, right ? matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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][hardware] Reproducible kernel panic in 8.0-STABLE
Andriy Gapon wrote: on 03/02/2010 13:23 Stephane LAPIE said the following: I just rebuilt a kernel with debugger options, and obtained the following output upon pulling out one disk : Sleeping thread (tid 100024, pid 0) owns a non-sleepable lock sched_switch() at sched_switch+0xf8 mi_switch() at mi_switch+0x16f sleepq_timedwait() at sleepq_timedwait+0x42 _cv_timedwait() at _cv_timedwait+0x129 _sema_timedwait() at _sema_timedwait+0x55 ata_queue_request() at ata_queue_request+0x526 ata_controlcmd() at ata_controlcmd+0xa1 ata_setmode() at ata_setmode+0xdc ad_init() at ad_init+0x27 ad_reinit() at ad_reinit+0x48 ata_reinit() at ata_reinit+0x268 ata_conn_event() at ata_conn_event+0x49 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8aad30, rbp = 0 --- panic: sleeping thread cpuid = 2 KDB: enter: panic [thread pid 12 tid 18 ] Stopped at kdb_enter+0x3d: movq$0,0x4943d0(%rip) Not sure if I can derive anything useful from here. Someone with more expertise is needed. One thing I noticed is that ata_conn_event and ata_reinit and some other functions up the stack acquire state_mtx recursively, but the mutex is not initialized with MTX_RECURSE. Perhaps, indeed you would have a better luck with AHCI controller _and_ ahci(4) driver. It seems to handle dynamic coming and going of disks much better than ata(4). I just moved half of the "flaky" drives on an AHCI controller. This seems to work much better, starting with disk detection issues being solved, and hotplug working exactly like SCSI does. It does require using camcontrol to recognize the disks again, but that much is not exactly a problem. Although I'm probably dreaming : Did anyone heard about AHCI controllers beside the on-board ones ? Thanks to everyone for their advice. -- Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo signature.asc Description: OpenPGP digital signature
Re: samba recplacement
Nenhum_de_Nos wrote: On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: Nenhum_de_Nos wrote: On Sat, February 6, 2010 23:44, Eric wrote: On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: hail, I've installed a recent 8-stable with gnome installed. I needed samba and noticed I have samba4-devel installed. but I can't manage to make it a simple file server as I need. so how to change samba package at minimum harm ? do I need to reinstall all ? a simple make fetch in samba33 says I can't as it conflicts with samba4 and some tbd-something (not in the machine right now). is there easy way ? I'd really like to choose samba version ... I've found a thread in gnome@ about this change (from late december). not a solution though. thanks, matheus pretty sure samba 4 is not stable yet. i played with it and it didnt work too well a few months ago. go back to the 3.x branch. thats easy to config. I think this way too, the problem is how to do it in the least painful way. if I deinstall all samba stuff, gnome will fail to work ? matheus This is what I did: go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI option. what I will loose in functionality ? I don't know. Some functions related to the mail client "evolution." I'd have to rebuild it all, right ? I think if you just delete samba4-devel and its dependencies, then you can rebuild from there. matheus ___ 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"
Promise SX8 SATA controller on FreeBSD8
Hi, I am at an end. I can't find anything about this device on FreeBSD; searching for it on Google or the FreeBSD site only provides few hits. Is the SX8 controller supported? I have a server with one and 6 disks that I'd really like to be running FreeBSD 8.0 on with ZFS. The device is detected by the the system boot, and it is detected by BSD, but no driver is assigned. Is there a driver in FreeBSD 8.0 i386 that supports it? Thanks A ___ 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: samba recplacement
On Sun, February 7, 2010 01:02, Stephen Montgomery-Smith wrote: > Nenhum_de_Nos wrote: >> >> On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: >>> Nenhum_de_Nos wrote: On Sat, February 6, 2010 23:44, Eric wrote: > On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >> hail, >> >> I've installed a recent 8-stable with gnome installed. I needed >> samba >> and >> noticed I have samba4-devel installed. but I can't manage to make it >> a >> simple file server as I need. so how to change samba package at >> minimum >> harm ? >> >> do I need to reinstall all ? a simple make fetch in samba33 says I >> can't >> as it conflicts with samba4 and some tbd-something (not in the >> machine >> right now). >> >> is there easy way ? >> >> I'd really like to choose samba version ... I've found a thread in >> gnome@ >> about this change (from late december). not a solution though. >> >> thanks, >> >> matheus > > pretty sure samba 4 is not stable yet. i played with it and it didnt > work too well a few months ago. go back to the 3.x branch. thats easy > to > config. I think this way too, the problem is how to do it in the least painful way. if I deinstall all samba stuff, gnome will fail to work ? matheus >>> >>> This is what I did: >>> >>> go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI >>> option. >> >> what I will loose in functionality ? > > I don't know. Some functions related to the mail client "evolution." if just evolution is affected, no problem for me. >> I'd have to rebuild it all, right ? > > I think if you just delete samba4-devel and its dependencies, then you > can rebuild from there. yeah ... I'll need to rebuild ... but I need samba3 for filesharing purposes :) thanks, maheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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: samba recplacement
Nenhum_de_Nos wrote: On Sun, February 7, 2010 01:02, Stephen Montgomery-Smith wrote: Nenhum_de_Nos wrote: On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: Nenhum_de_Nos wrote: On Sat, February 6, 2010 23:44, Eric wrote: On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: hail, I've installed a recent 8-stable with gnome installed. I needed samba and noticed I have samba4-devel installed. but I can't manage to make it a simple file server as I need. so how to change samba package at minimum harm ? do I need to reinstall all ? a simple make fetch in samba33 says I can't as it conflicts with samba4 and some tbd-something (not in the machine right now). is there easy way ? I'd really like to choose samba version ... I've found a thread in gnome@ about this change (from late december). not a solution though. thanks, matheus pretty sure samba 4 is not stable yet. i played with it and it didnt work too well a few months ago. go back to the 3.x branch. thats easy to config. I think this way too, the problem is how to do it in the least painful way. if I deinstall all samba stuff, gnome will fail to work ? matheus This is what I did: go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI option. what I will loose in functionality ? I don't know. Some functions related to the mail client "evolution." if just evolution is affected, no problem for me. I'd have to rebuild it all, right ? I think if you just delete samba4-devel and its dependencies, then you can rebuild from there. yeah ... I'll need to rebuild ... but I need samba3 for filesharing purposes :) And you can install samba3 separately, just like I did. ___ 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"
