Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 10:48:56PM -0400, Chris Ross wrote: On Jun 30, 2015, at 22:36 , Glen Barber g...@freebsd.org wrote: On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross wrote: Yeah, this is the same panic you, I, and others have been seeing on sparc64's with bge's, or at least v240's (and one other IIRC) for many many months. Thanks for grabbing a core! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. A quick search through the PR system returned zero results for this. Did you file a PR previously? (If not, do you know of one that already exists that Kurt can update?) The long thread I see in my emails are with subject FreeBSD 10-STABLE/sparc64 panic. May/June, and then later September and October, and I don't see anyone to have created a PR. I think I got confused and dismayed in June, from reading back, and then never got to trying hard again. The first report I see is from Kurt, http://lists.freebsd.org/pipermail/freebsd-sparc64/2014-March/009261.html, so well over a year ago. But, no mention in that thread about a PR either. Thank you for the reference. I think you may be right, Glen, that there isn't one, and that's on me as well as others. Hopefully, some of the searching through various revisions of 10/stable I documented in the FreeBSD 10-STABLE/sparc64 panic thread in May 2014 may help in the end, though. It's fine, it explains why I could not find one. Kurt, could you please create a PR and point me to the PR number so RE can put it on our watch list? Thanks. Glen Thanks. tl;dr; I don't know of an existing PR. - Chris On Jun 30, 2015, at 22:14 , Kurt Lidl l...@pix.net wrote: I got all excited and decided to give it a try on my dual-cpu V240 as well. I was able to get it installed, but it panics when booting off the mirrored ZFS drives. (Note: I have no reason to believe this is ZFS related.) snip, snip Setting hostname: spork.pix.net. bge0: link state changed to DOWN spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc0575380 at panic+0x20 #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d7b9c at tick_get_timecount_mp+0xdc #4 0xc0583c88 at binuptime+0x48 #5 0xc08a3b8c at timercb+0x6c #6 0xc08d7f00 at tick_intr+0x220 Uptime: 29s Dumping 8192 MB (4 chunks) chunk at 0: 2147483648 bytes ... ok chunk at 0x1: 2147483648 bytes ... ok chunk at 0x10: 2147483648 bytes ... ok chunk at 0x11: 2147483648 bytes ... ok Dump complete snip, snip Now the thing that amazes me is that this happened the first three times after I did the install, and on the fourth boot, it didn't panic. And it was able to 'savecore' the crashdump. Here's the stacktrace from the core.txt.0 file: -Kurt Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. Loaded symbols for /boot/kernel/geom_mirror.ko.symbols Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 262 savectx(dumppcb); (kgdb) #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 #1 0xc0574fb0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 spin lock held too long, ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xc0575388 in panic (fmt=0xc0b22fe0 spin lock held too long) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) at /usr/src/sys/kern/kern_mutex.c:561 #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, tid=18446735277669594832, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:608 #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 #7
Re: suspend/resume regression
On Tue, Jun 30, 2015 at 8:45 AM, John Baldwin j...@freebsd.org wrote: I'm traveling and AFK for a week or so more, but I did test this MFC including suspend/resume with CardBus, etc. on a T440 before committing it. It would be good to know if HEAD works for you. If it does then there's likely another fix from HEAD that you need merged. -- John Baldwin John, I have opened bug # 201239 for the problem. Unfortunately I will be traveling and need a functioning laptop, so I can't test with HEAD right now. I will be back on the 9th and, if no one else has had a chance to test by then, I'll give it a try. It's about time I gave it a shot as I have not run HEAD since 10 was branched. Thanks for looking at this. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Jun 29, 2015, at 00:54, Kevin Oberman rkober...@gmail.com wrote: On Sun, Jun 28, 2015 at 11:07 PM, Adrian Chadd adrian.ch...@gmail.com wrote: Ok, so which subset of changes is the culprit? (sorry, I'm tired.. :( ) The merge of 281874 broke it. Unfortunately, this is a fairly large and important change that touches five files, mainly dev/pci/pci.c and dev/pci/pci_pci.c with a less significant update to dev/pccbb/pccbb_pci.c. Get some rest. This is an annoying regression, but not disastrous. Systems still run and it sounds like many still resume. Unfortunately my T520 and some contemporary ThinkPads don't. I now have enough data to open a fairly coherent ticket. I'll try to open it tomorrow. (I'm tired, too.) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 -a On 28 June 2015 at 22:45, Kevin Oberman rkober...@gmail.com wrote: On Sun, Jun 28, 2015 at 4:54 PM, Kevin Oberman rkober...@gmail.com wrote: On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone j...@ftfl.ca wrote: Adrian Chadd adrian.ch...@gmail.com writes: ok. I've updated my x230 to the latest -head and it is okay at suspend/resume. No problem with -head on the X220 as well. I can go acquire an x220 (now that they're cheap) to have as another reference laptop. You might ping Allan Jude. If I'm not mistaken he had at least two X220s at BSDCan. Maybe he'd be willing to part with one. I have now merged all of the parts of 284034 except for 281874 and resume works correctly. As i suspected, something in that rather large commit is the problem and it is probably something that is tied to some other change in HEAD as Adrian has reported that it works fine in HEAD. I'll have to admit that have no idea how to approach figuring this out. I'm not sure how I can even revert a part of the commit to get 10.2-PRERELEASE working for me. I really wish that a commit as large as this one had been MFCed separately. :-( So far there has been only a single commit to pci and none to pccbb since 284034, so I built stable with the files modified in 281874 manually reverted. I now have r284916M running and it seems to be working fine. All of 284034 committed except for the MFC from 281874. That left three files conflicting with STABLE: /usr/src/sys/dev/pci/pci.c /usr/src/sys/dev/pci/pci_pci.c /usr/src/sys/dev/pccbb/pccbb_pci.c -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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 FreeBSD snapshots available: stable/10 (20150625 r284813)
On 6/30/15 8:16 PM, Glen Barber wrote: On Tue, Jun 30, 2015 at 08:14:07PM -0400, Kurt Lidl wrote: [-stable@ in CC since these are the first 10.2-PRERELEASE builds available since the code slush went into effect, which marks the start of the release cycle.] New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. I was able to download the sparc64 iso image, burn the iso to a cd-rom, and boot a sparc64 V120 from that image. I was also able to perform an install onto a ZFS only setup, and have it work properly. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. Great to hear. Thank you for testing. I got all excited and decided to give it a try on my dual-cpu V240 as well. I was able to get it installed, but it panics when booting off the mirrored ZFS drives. (Note: I have no reason to believe this is ZFS related.) snip, snip Setting hostname: spork.pix.net. bge0: link state changed to DOWN spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc0575380 at panic+0x20 #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d7b9c at tick_get_timecount_mp+0xdc #4 0xc0583c88 at binuptime+0x48 #5 0xc08a3b8c at timercb+0x6c #6 0xc08d7f00 at tick_intr+0x220 Uptime: 29s Dumping 8192 MB (4 chunks) chunk at 0: 2147483648 bytes ... ok chunk at 0x1: 2147483648 bytes ... ok chunk at 0x10: 2147483648 bytes ... ok chunk at 0x11: 2147483648 bytes ... ok Dump complete snip, snip Now the thing that amazes me is that this happened the first three times after I did the install, and on the fourth boot, it didn't panic. And it was able to 'savecore' the crashdump. Here's the stacktrace from the core.txt.0 file: -Kurt Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. Loaded symbols for /boot/kernel/geom_mirror.ko.symbols Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 262 savectx(dumppcb); (kgdb) #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 #1 0xc0574fb0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 spin lock held too long, ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xc0575388 in panic (fmt=0xc0b22fe0 spin lock held too long) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) at /usr/src/sys/kern/kern_mutex.c:561 #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, tid=18446735277669594832, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:608 #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 #7 0xc0583c90 in binuptime (bt=0x1fa2da980) at /usr/src/sys/kern/kern_tc.c:188 #8 0xc08a3b94 in timercb (et=0xc0d13308, arg=value optimized out) at time.h:418 #9 0xc08d7f08 in tick_intr (tf=0x1fa2dab20) at /usr/src/sys/sparc64/sparc64/tick.c:252 #10 0xc00a11bc in tl1_intr () #11 0xc08c934c in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:244 #12 0xc08c9330 in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:240 #13 0xc051a194 in cnputs (p=0x1fa2db11a ) at /usr/src/sys/kern/kern_cons.c:530 #14 0xc05c06e0 in putchar (c=10, arg=0x1fa2db0c8) at /usr/src/sys/kern/subr_prf.c:437 #15 0xc05bee90 in kvprintf (fmt=0xc0b2fb95 , func=0xc05c02e0 putchar, arg=0x1fa2db0c8, radix=10, ap=0x1fa2db300) at /usr/src/sys/kern/subr_prf.c:655 #16 0xc05bfe80 in _vprintf (level=5, flags=1, fmt=0xc0b2fb78 %s: link state changed to %s\n, ap=0x1fa2db2f0) at /usr/src/sys/kern/subr_prf.c:281 #17 0xc05c0270 in log (level=5, fmt=0xc0b2fb78 %s: link state changed to %s\n) at /usr/src/sys/kern/subr_prf.c:308 #18 0xc064ec28 in do_link_state_change (arg=0xf80003396800, pending=1) at /usr/src/sys/net/if.c:2131 #19 0xc05cab38 in taskqueue_run_locked
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
Yeah, this is the same panic you, I, and others have been seeing on sparc64's with bge's, or at least v240's (and one other IIRC) for many many months. Thanks for grabbing a core! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. - Chris On Jun 30, 2015, at 22:14 , Kurt Lidl l...@pix.net wrote: I got all excited and decided to give it a try on my dual-cpu V240 as well. I was able to get it installed, but it panics when booting off the mirrored ZFS drives. (Note: I have no reason to believe this is ZFS related.) snip, snip Setting hostname: spork.pix.net. bge0: link state changed to DOWN spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc0575380 at panic+0x20 #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d7b9c at tick_get_timecount_mp+0xdc #4 0xc0583c88 at binuptime+0x48 #5 0xc08a3b8c at timercb+0x6c #6 0xc08d7f00 at tick_intr+0x220 Uptime: 29s Dumping 8192 MB (4 chunks) chunk at 0: 2147483648 bytes ... ok chunk at 0x1: 2147483648 bytes ... ok chunk at 0x10: 2147483648 bytes ... ok chunk at 0x11: 2147483648 bytes ... ok Dump complete snip, snip Now the thing that amazes me is that this happened the first three times after I did the install, and on the fourth boot, it didn't panic. And it was able to 'savecore' the crashdump. Here's the stacktrace from the core.txt.0 file: -Kurt Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. Loaded symbols for /boot/kernel/geom_mirror.ko.symbols Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 262 savectx(dumppcb); (kgdb) #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 #1 0xc0574fb0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 spin lock held too long, ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xc0575388 in panic (fmt=0xc0b22fe0 spin lock held too long) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) at /usr/src/sys/kern/kern_mutex.c:561 #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, tid=18446735277669594832, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:608 #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 #7 0xc0583c90 in binuptime (bt=0x1fa2da980) at /usr/src/sys/kern/kern_tc.c:188 #8 0xc08a3b94 in timercb (et=0xc0d13308, arg=value optimized out) at time.h:418 #9 0xc08d7f08 in tick_intr (tf=0x1fa2dab20) at /usr/src/sys/sparc64/sparc64/tick.c:252 #10 0xc00a11bc in tl1_intr () #11 0xc08c934c in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:244 #12 0xc08c9330 in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:240 #13 0xc051a194 in cnputs (p=0x1fa2db11a ) at /usr/src/sys/kern/kern_cons.c:530 #14 0xc05c06e0 in putchar (c=10, arg=0x1fa2db0c8) at /usr/src/sys/kern/subr_prf.c:437 #15 0xc05bee90 in kvprintf (fmt=0xc0b2fb95 , func=0xc05c02e0 putchar, arg=0x1fa2db0c8, radix=10, ap=0x1fa2db300) at /usr/src/sys/kern/subr_prf.c:655 #16 0xc05bfe80 in _vprintf (level=5, flags=1, fmt=0xc0b2fb78 %s: link state changed to %s\n, ap=0x1fa2db2f0) at /usr/src/sys/kern/subr_prf.c:281 #17 0xc05c0270 in log (level=5, fmt=0xc0b2fb78 %s: link state changed to %s\n) at /usr/src/sys/kern/subr_prf.c:308 #18 0xc064ec28 in do_link_state_change (arg=0xf80003396800, pending=1) at /usr/src/sys/net/if.c:2131 #19 0xc05cab38 in taskqueue_run_locked (queue=0xf80003288000) at /usr/src/sys/kern/subr_taskqueue.c:342 #20 0xc05cacec in taskqueue_run (queue=0xf80003288000) at
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Jun 30, 2015, at 22:36 , Glen Barber g...@freebsd.org wrote: On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross wrote: Yeah, this is the same panic you, I, and others have been seeing on sparc64's with bge's, or at least v240's (and one other IIRC) for many many months. Thanks for grabbing a core! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. A quick search through the PR system returned zero results for this. Did you file a PR previously? (If not, do you know of one that already exists that Kurt can update?) The long thread I see in my emails are with subject FreeBSD 10-STABLE/sparc64 panic. May/June, and then later September and October, and I don't see anyone to have created a PR. I think I got confused and dismayed in June, from reading back, and then never got to trying hard again. The first report I see is from Kurt, http://lists.freebsd.org/pipermail/freebsd-sparc64/2014-March/009261.html, so well over a year ago. But, no mention in that thread about a PR either. I think you may be right, Glen, that there isn't one, and that's on me as well as others. Hopefully, some of the searching through various revisions of 10/stable I documented in the FreeBSD 10-STABLE/sparc64 panic thread in May 2014 may help in the end, though. Thanks. tl;dr; I don't know of an existing PR. - Chris On Jun 30, 2015, at 22:14 , Kurt Lidl l...@pix.net wrote: I got all excited and decided to give it a try on my dual-cpu V240 as well. I was able to get it installed, but it panics when booting off the mirrored ZFS drives. (Note: I have no reason to believe this is ZFS related.) snip, snip Setting hostname: spork.pix.net. bge0: link state changed to DOWN spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc0575380 at panic+0x20 #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d7b9c at tick_get_timecount_mp+0xdc #4 0xc0583c88 at binuptime+0x48 #5 0xc08a3b8c at timercb+0x6c #6 0xc08d7f00 at tick_intr+0x220 Uptime: 29s Dumping 8192 MB (4 chunks) chunk at 0: 2147483648 bytes ... ok chunk at 0x1: 2147483648 bytes ... ok chunk at 0x10: 2147483648 bytes ... ok chunk at 0x11: 2147483648 bytes ... ok Dump complete snip, snip Now the thing that amazes me is that this happened the first three times after I did the install, and on the fourth boot, it didn't panic. And it was able to 'savecore' the crashdump. Here's the stacktrace from the core.txt.0 file: -Kurt Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. Loaded symbols for /boot/kernel/geom_mirror.ko.symbols Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 262 savectx(dumppcb); (kgdb) #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 #1 0xc0574fb0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 spin lock held too long, ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xc0575388 in panic (fmt=0xc0b22fe0 spin lock held too long) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) at /usr/src/sys/kern/kern_mutex.c:561 #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, tid=18446735277669594832, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:608 #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 #7 0xc0583c90 in binuptime (bt=0x1fa2da980) at /usr/src/sys/kern/kern_tc.c:188 #8 0xc08a3b94 in timercb (et=0xc0d13308, arg=value optimized out) at time.h:418 #9 0xc08d7f08 in tick_intr (tf=0x1fa2dab20) at /usr/src/sys/sparc64/sparc64/tick.c:252 #10 0xc00a11bc in tl1_intr () #11 0xc08c934c in spinlock_exit () at
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
[-stable@ in CC since these are the first 10.2-PRERELEASE builds available since the code slush went into effect, which marks the start of the release cycle.] New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. I was able to download the sparc64 iso image, burn the iso to a cd-rom, and boot a sparc64 V120 from that image. I was also able to perform an install onto a ZFS only setup, and have it work properly. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. -Kurt dmesg follows: Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.2-PRERELEASE #1: Tue Jun 30 19:51:35 EDT 2015 r...@ton.pix.net:/usr/obj/usr/src/sys/V120 sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 4294967296 (4096 MB) avail memory = 4175503360 (3982 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU) WARNING: VIMAGE (virtualized network stack) is a highly experimental feature. random: Software, Yarrow initialized nexus0: Open Firmware Nexus device pcib0: U2P UPA-PCI bridge mem 0x1fe-0x1fe,0x1fe0100-0x1fe01ff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 66MHz pcib0: DVMA map: 0xc000 to 0xc3ff 8192 entries pcib0: [GIANT-LOCKED] pci0: OFW PCI bus on pcib0 pcib1: APB PCI-PCI bridge at device 1.1 on pci0 pci1: OFW PCI bus on pcib1 ebus0: PCI-EBus3 bridge mem 0xf000-0xf0ff,0xf100-0xf17f at device 12.0 on pci1 ebus0: idprom: incomplete pcib2: APB PCI-PCI bridge at device 1.0 on pci0 pci2: OFW PCI bus on pcib2 ebus0: flashprom addr 0x10-0x1f (no driver attached) eeprom0: EEPROM/clock addr 0x14-0x141fff on ebus0 eeprom0: model mk48t59 ebus0: SUNW,lomh addr 0x140020-0x140023 irq 42 (no driver attached) pci1: old, non-VGA display device at device 3.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci1 isa0: ISA bus on isab0 gem0: Sun ERI 10/100 Ethernet mem 0xe040-0xe041 at device 12.1 on pci1 miibus0: MII bus on gem0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow gem0: 2kB RX FIFO, 2kB TX FIFO gem0: Ethernet address: 00:03:ba:2f:fc:50 ohci0: Sun PCIO-2 USB controller mem 0xe200-0xe2007fff at device 12.3 on pci1 usbus0 on ohci0 atapci0: AcerLabs M5229 UDMA66 controller port 0x400-0x407,0x418-0x41b,0x410-0x417,0x408-0x40b,0x420-0x42f at device 13.0 on pci1 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: ATA channel at channel 0 on atapci0 ata3: ATA channel at channel 1 on atapci0 gem1: Sun ERI 10/100 Ethernet mem 0xe044-0xe045 at device 5.1 on pci1 miibus1: MII bus on gem1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow gem1: 2kB RX FIFO, 2kB TX FIFO gem1: Ethernet address: 00:03:ba:2f:fc:51 ohci1: Sun PCIO-2 USB controller mem 0xe500-0xe5007fff at device 5.3 on pci1 usbus1 on ohci1 sym0: 896 port 0xc0-0xc000ff mem 0x2000-0x23ff,0x4000-0x5fff at device 8.0 on pci2 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym1: 896 port 0xc00100-0xc001ff mem 0x6000-0x63ff,0x8000-0x9fff at device 8.1 on pci2 sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking uart0: 16550 or compatible at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2e8-0x2ef irq 43 on isa0 usbus0: 12Mbps Full Speed USB v1.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter tick frequency 64800 Hz quality 1000 Event timer tick frequency 64800 Hz quality 1000 Timecounters tick every 1.000 msec usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: SUN at usbus0 uhub0: SUN OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: SUN at usbus1 uhub1: SUN OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 uhub0: 4 ports with 4 removable, self powered uhub1: 4 ports with 4 removable, self powered random: unblocking device. da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: FUJITSU MAT3073NC 0108 Fixed Direct Access SCSI-3 device da0: Serial Number AAL0P58055P6 da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da0: Command Queueing enabled da0: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) da1
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 08:14:07PM -0400, Kurt Lidl wrote: [-stable@ in CC since these are the first 10.2-PRERELEASE builds available since the code slush went into effect, which marks the start of the release cycle.] New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. I was able to download the sparc64 iso image, burn the iso to a cd-rom, and boot a sparc64 V120 from that image. I was also able to perform an install onto a ZFS only setup, and have it work properly. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. Great to hear. Thank you for testing. Glen pgpyXuCt7xrYJ.pgp Description: PGP signature
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 10:14:19PM -0400, Kurt Lidl wrote: On 6/30/15 8:16 PM, Glen Barber wrote: On Tue, Jun 30, 2015 at 08:14:07PM -0400, Kurt Lidl wrote: [-stable@ in CC since these are the first 10.2-PRERELEASE builds available since the code slush went into effect, which marks the start of the release cycle.] New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. I was able to download the sparc64 iso image, burn the iso to a cd-rom, and boot a sparc64 V120 from that image. I was also able to perform an install onto a ZFS only setup, and have it work properly. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. Great to hear. Thank you for testing. I got all excited and decided to give it a try on my dual-cpu V240 as well. I was able to get it installed, but it panics when booting off the mirrored ZFS drives. (Note: I have no reason to believe this is ZFS related.) Can you please file a PR with this information? FWIW, updated builds are in-flight now, and should be available on FTP mirrors tomorrow. I'll CC -stable@ on the announcement email; will you be able to test the updated build? Glen snip, snip Setting hostname: spork.pix.net. bge0: link state changed to DOWN spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc0575380 at panic+0x20 #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d7b9c at tick_get_timecount_mp+0xdc #4 0xc0583c88 at binuptime+0x48 #5 0xc08a3b8c at timercb+0x6c #6 0xc08d7f00 at tick_intr+0x220 Uptime: 29s Dumping 8192 MB (4 chunks) chunk at 0: 2147483648 bytes ... ok chunk at 0x1: 2147483648 bytes ... ok chunk at 0x10: 2147483648 bytes ... ok chunk at 0x11: 2147483648 bytes ... ok Dump complete snip, snip Now the thing that amazes me is that this happened the first three times after I did the install, and on the fourth boot, it didn't panic. And it was able to 'savecore' the crashdump. Here's the stacktrace from the core.txt.0 file: -Kurt Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. Loaded symbols for /boot/kernel/geom_mirror.ko.symbols Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 262 savectx(dumppcb); (kgdb) #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 #1 0xc0574fb0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 spin lock held too long, ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xc0575388 in panic (fmt=0xc0b22fe0 spin lock held too long) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) at /usr/src/sys/kern/kern_mutex.c:561 #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, tid=18446735277669594832, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:608 #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 #7 0xc0583c90 in binuptime (bt=0x1fa2da980) at /usr/src/sys/kern/kern_tc.c:188 #8 0xc08a3b94 in timercb (et=0xc0d13308, arg=value optimized out) at time.h:418 #9 0xc08d7f08 in tick_intr (tf=0x1fa2dab20) at /usr/src/sys/sparc64/sparc64/tick.c:252 #10 0xc00a11bc in tl1_intr () #11 0xc08c934c in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:244 #12 0xc08c9330 in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:240 #13 0xc051a194 in cnputs (p=0x1fa2db11a ) at /usr/src/sys/kern/kern_cons.c:530 #14 0xc05c06e0 in putchar (c=10, arg=0x1fa2db0c8) at /usr/src/sys/kern/subr_prf.c:437 #15 0xc05bee90 in kvprintf (fmt=0xc0b2fb95 , func=0xc05c02e0 putchar, arg=0x1fa2db0c8, radix=10, ap=0x1fa2db300) at /usr/src/sys/kern/subr_prf.c:655 #16 0xc05bfe80 in _vprintf (level=5, flags=1,
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross wrote: Yeah, this is the same panic you, I, and others have been seeing on sparc64's with bge's, or at least v240's (and one other IIRC) for many many months. Thanks for grabbing a core! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. A quick search through the PR system returned zero results for this. Did you file a PR previously? (If not, do you know of one that already exists that Kurt can update?) Glen - Chris On Jun 30, 2015, at 22:14 , Kurt Lidl l...@pix.net wrote: I got all excited and decided to give it a try on my dual-cpu V240 as well. I was able to get it installed, but it panics when booting off the mirrored ZFS drives. (Note: I have no reason to believe this is ZFS related.) snip, snip Setting hostname: spork.pix.net. bge0: link state changed to DOWN spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc0575380 at panic+0x20 #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d7b9c at tick_get_timecount_mp+0xdc #4 0xc0583c88 at binuptime+0x48 #5 0xc08a3b8c at timercb+0x6c #6 0xc08d7f00 at tick_intr+0x220 Uptime: 29s Dumping 8192 MB (4 chunks) chunk at 0: 2147483648 bytes ... ok chunk at 0x1: 2147483648 bytes ... ok chunk at 0x10: 2147483648 bytes ... ok chunk at 0x11: 2147483648 bytes ... ok Dump complete snip, snip Now the thing that amazes me is that this happened the first three times after I did the install, and on the fourth boot, it didn't panic. And it was able to 'savecore' the crashdump. Here's the stacktrace from the core.txt.0 file: -Kurt Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. Loaded symbols for /boot/kernel/geom_mirror.ko.symbols Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 262 savectx(dumppcb); (kgdb) #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 #1 0xc0574fb0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 spin lock held too long, ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xc0575388 in panic (fmt=0xc0b22fe0 spin lock held too long) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) at /usr/src/sys/kern/kern_mutex.c:561 #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, tid=18446735277669594832, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:608 #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 #7 0xc0583c90 in binuptime (bt=0x1fa2da980) at /usr/src/sys/kern/kern_tc.c:188 #8 0xc08a3b94 in timercb (et=0xc0d13308, arg=value optimized out) at time.h:418 #9 0xc08d7f08 in tick_intr (tf=0x1fa2dab20) at /usr/src/sys/sparc64/sparc64/tick.c:252 #10 0xc00a11bc in tl1_intr () #11 0xc08c934c in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:244 #12 0xc08c9330 in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:240 #13 0xc051a194 in cnputs (p=0x1fa2db11a ) at /usr/src/sys/kern/kern_cons.c:530 #14 0xc05c06e0 in putchar (c=10, arg=0x1fa2db0c8) at /usr/src/sys/kern/subr_prf.c:437 #15 0xc05bee90 in kvprintf (fmt=0xc0b2fb95 , func=0xc05c02e0 putchar, arg=0x1fa2db0c8, radix=10, ap=0x1fa2db300) at /usr/src/sys/kern/subr_prf.c:655 #16 0xc05bfe80 in _vprintf (level=5, flags=1, fmt=0xc0b2fb78 %s: link state changed to %s\n, ap=0x1fa2db2f0) at /usr/src/sys/kern/subr_prf.c:281 #17 0xc05c0270 in log (level=5, fmt=0xc0b2fb78 %s: link state changed to %s\n) at
Re: suspend/resume regression
I'm traveling and AFK for a week or so more, but I did test this MFC including suspend/resume with CardBus, etc. on a T440 before committing it. It would be good to know if HEAD works for you. If it does then there's likely another fix from HEAD that you need merged. -- John Baldwin On Jun 29, 2015, at 00:54, Kevin Oberman rkober...@gmail.com wrote: On Sun, Jun 28, 2015 at 11:07 PM, Adrian Chadd adrian.ch...@gmail.com wrote: Ok, so which subset of changes is the culprit? (sorry, I'm tired.. :( ) The merge of 281874 broke it. Unfortunately, this is a fairly large and important change that touches five files, mainly dev/pci/pci.c and dev/pci/pci_pci.c with a less significant update to dev/pccbb/pccbb_pci.c. Get some rest. This is an annoying regression, but not disastrous. Systems still run and it sounds like many still resume. Unfortunately my T520 and some contemporary ThinkPads don't. I now have enough data to open a fairly coherent ticket. I'll try to open it tomorrow. (I'm tired, too.) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 -a On 28 June 2015 at 22:45, Kevin Oberman rkober...@gmail.com wrote: On Sun, Jun 28, 2015 at 4:54 PM, Kevin Oberman rkober...@gmail.com wrote: On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone j...@ftfl.ca wrote: Adrian Chadd adrian.ch...@gmail.com writes: ok. I've updated my x230 to the latest -head and it is okay at suspend/resume. No problem with -head on the X220 as well. I can go acquire an x220 (now that they're cheap) to have as another reference laptop. You might ping Allan Jude. If I'm not mistaken he had at least two X220s at BSDCan. Maybe he'd be willing to part with one. I have now merged all of the parts of 284034 except for 281874 and resume works correctly. As i suspected, something in that rather large commit is the problem and it is probably something that is tied to some other change in HEAD as Adrian has reported that it works fine in HEAD. I'll have to admit that have no idea how to approach figuring this out. I'm not sure how I can even revert a part of the commit to get 10.2-PRERELEASE working for me. I really wish that a commit as large as this one had been MFCed separately. :-( So far there has been only a single commit to pci and none to pccbb since 284034, so I built stable with the files modified in 281874 manually reverted. I now have r284916M running and it seems to be working fine. All of 284034 committed except for the MFC from 281874. That left three files conflicting with STABLE: /usr/src/sys/dev/pci/pci.c /usr/src/sys/dev/pci/pci_pci.c /usr/src/sys/dev/pccbb/pccbb_pci.c -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Bug 201072
On 29/06/2015 8:18 PM, Kimmo Paasiala wrote: It looks like the atf directories were removed from /etc/mtree/* in: https://svnweb.freebsd.org/base?view=revisionrevision=260024 They were later put back in this commit: https://svnweb.freebsd.org/base?view=revisionrevision=277457 My patch is not valid apparently because it would break the tests stuff again, I had no idea how complex the issue was... Hi Kimmo, thanks for the report :) Please add your comment to the issue, I have triaged it and cc'd our testing gurus who can hopefully help ./koobs ___ 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: Bug 201072
On Tue, Jun 30, 2015 at 8:02 PM, Kubilay Kocak ko...@freebsd.org wrote: On 29/06/2015 8:18 PM, Kimmo Paasiala wrote: It looks like the atf directories were removed from /etc/mtree/* in: https://svnweb.freebsd.org/base?view=revisionrevision=260024 They were later put back in this commit: https://svnweb.freebsd.org/base?view=revisionrevision=277457 My patch is not valid apparently because it would break the tests stuff again, I had no idea how complex the issue was... Hi Kimmo, thanks for the report :) Please add your comment to the issue, I have triaged it and cc'd our testing gurus who can hopefully help ./koobs Done. -Kimmo ___ 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: Sharing NTFS via NFS
Sergey Matveychuk wrote: 01.07.2015 1:26, Rick Macklem wrote: Sergey Matveychuk wrote: Hi. For some reason I need to share USB disk with NTFS via NFS. I use fusefs-ntfs to mount the USB disk. But can't export it. I've got this message from mountd(8): mountd[85534]: can't export /mnt After googling I found out Linux can export Ntfs-3g with option no_root_squash: http://ubuntuforums.org/showthread.php?t=1791330 But how to do this with FreeBSD (10.0-RELEASE now)? Short answer is you can't. Fuse file systems on FreeBSD can't be exported. I'd like to read a long answer. Why? What limitations? Fuse on FreeBSD doesn't support VFS operations that are required by the NFS server. VFS_FHTOVP(), VFS_VPTOFH() and the stuff that allows a mount point to be exported are some, there are probably others. How much work would it be to add this capability. At this time I have no idea since I am not conversant with Fuse. rick ___ 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Sharing NTFS via NFS
Hi. For some reason I need to share USB disk with NTFS via NFS. I use fusefs-ntfs to mount the USB disk. But can't export it. I've got this message from mountd(8): mountd[85534]: can't export /mnt After googling I found out Linux can export Ntfs-3g with option no_root_squash: http://ubuntuforums.org/showthread.php?t=1791330 But how to do this with FreeBSD (10.0-RELEASE now)? ___ 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: Sharing NTFS via NFS
Sergey Matveychuk wrote: Hi. For some reason I need to share USB disk with NTFS via NFS. I use fusefs-ntfs to mount the USB disk. But can't export it. I've got this message from mountd(8): mountd[85534]: can't export /mnt After googling I found out Linux can export Ntfs-3g with option no_root_squash: http://ubuntuforums.org/showthread.php?t=1791330 But how to do this with FreeBSD (10.0-RELEASE now)? Short answer is you can't. Fuse file systems on FreeBSD can't be exported. rick ___ 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-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: Sharing NTFS via NFS
01.07.2015 1:26, Rick Macklem wrote: Sergey Matveychuk wrote: Hi. For some reason I need to share USB disk with NTFS via NFS. I use fusefs-ntfs to mount the USB disk. But can't export it. I've got this message from mountd(8): mountd[85534]: can't export /mnt After googling I found out Linux can export Ntfs-3g with option no_root_squash: http://ubuntuforums.org/showthread.php?t=1791330 But how to do this with FreeBSD (10.0-RELEASE now)? Short answer is you can't. Fuse file systems on FreeBSD can't be exported. I'd like to read a long answer. Why? What limitations? ___ 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
