Re: Console problem with ALT-F# keys
Hi--
On Aug 25, 2011, at 5:56 PM, Pegasus Mc Cleaft wrote:
I am running FreeBSD 9.0-BETA1 r225125 compiled with LLVM on a Xeon
processor (CPUTYPE=core2 and CFLAGS= -mmmx -msse -msse2 -msse3 -O2
-fno-strict-aliasing -pipe)
The FreeBSD kernel doesn't use MMX or SSE by explicit design choice. See
sys/conf/kern.mk:
# [ ... ] Explicitly prohibit the use of SSE and other SIMD
# operations inside the kernel itself. These operations are exclusively
# reserved for user applications.
#
.if ${MACHINE_ARCH} == i386 ${CC} != icc
CFLAGS+=-mno-align-long-strings -mpreferred-stack-boundary=2 \
-mno-mmx -mno-3dnow -mno-sse -mno-sse2
INLINE_LIMIT?= 8000
.endif
Trying to override the default compiler flags to force it to use MMX/SSE is
simply not going to work.
Regards,
--
-Chuck
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
siba_bwn in GENERIC
Good day! Right now we have this line in GENERIC: #device bwn # Broadcom BCM43xx wireless NICs From user POV all he need to do to make his broadcom wifi work, is to uncomment this line and recompile his kernel. But this actually not sufficient - he also need to add device siba_bwn, and then install net/bwn-firmware-kmod. But he will know that after recompiling his kernel when his wireless adapter will not work as expected :). So may be we need to also add siba_bwn (commented out by default) in GENERIC and some reference about net/bwn-firmware-kmod? -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: siba_bwn in GENERIC
On 26 August 2011 15:14, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: Good day! Right now we have this line in GENERIC: #device bwn # Broadcom BCM43xx wireless NICs From user POV all he need to do to make his broadcom wifi work, is to uncomment this line and recompile his kernel. But this actually not sufficient - he also need to add device siba_bwn, and then install net/bwn-firmware-kmod. But he will know that after recompiling his kernel when his wireless adapter will not work as expected :). So may be we need to also add siba_bwn (commented out by default) in GENERIC and some reference about net/bwn-firmware-kmod? I think it's a good idea, along with any other documentation related changes that need to occur. Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
kqueue and device driver experience anyone ?
a question for the kqueue experts out there: I am trying to add kqueue support to a device driver, and am puzzled on what the .f_event() function may assume. I see that some of the examples (e.g. bpf, audit_pipe.c) expect that the function is called with the device lock held (and even have a LOCK_ASSERT). Others (if_tap, cam/scsi/scsi_target.c) either do not use the lock or explicitly acquire it. As far as i can tell the .f_event() function is called in two places: - within knote() which in turn (through KNOTE_*() ) is called by the driver itself near selrecord() . So it is up to the device driver to call it with the device lock held; - within kqueue_scan(), which instead is called from the upper half of the kernel as part of kern_kevent(). Here there seems to be no way that the device lock is acquired when .f_event() is called. Unless, of course, the knote's on which these .f_event() are called are not the same ones attached to devices -- so there is a different .f_event() function called ? So, is there a bug in the kqueue support for bpf.c and audit_pipe.c, or i am missing something important ? cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kqueue and device driver experience anyone ?
On Friday, August 26, 2011 11:39:40 am Luigi Rizzo wrote: a question for the kqueue experts out there: I am trying to add kqueue support to a device driver, and am puzzled on what the .f_event() function may assume. I see that some of the examples (e.g. bpf, audit_pipe.c) expect that the function is called with the device lock held (and even have a LOCK_ASSERT). Others (if_tap, cam/scsi/scsi_target.c) either do not use the lock or explicitly acquire it. As far as i can tell the .f_event() function is called in two places: - within knote() which in turn (through KNOTE_*() ) is called by the driver itself near selrecord() . So it is up to the device driver to call it with the device lock held; - within kqueue_scan(), which instead is called from the upper half of the kernel as part of kern_kevent(). Here there seems to be no way that the device lock is acquired when .f_event() is called. Unless, of course, the knote's on which these .f_event() are called are not the same ones attached to devices -- so there is a different .f_event() function called ? So, is there a bug in the kqueue support for bpf.c and audit_pipe.c, or i am missing something important ? Note that the top-half code may end up locking the device's mutex if the mutex was tied to the knote list when the knote list was created (e.g. knlist_init_mtx()). In general if you want to use locking to protect your knlist, you should tell the knlist about the locking to use, then there are variants of KNOTE() that let it know if the calling code already holds the appropriate lock or not (KNOTE_LOCKED() and KNOTE_UNLOCKED()). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: CARP on 9.0 (was no subject)
How about: %sudo netstat -s carp ...on both machines. A few years ago I submitted (or maybe it was Steve Polyack) a patch to add debugging to CARP, not sure if it ever got commited. Need-more-Cisco'sih-Debugging. ~BAS On Fri, 26 Aug 2011, Patrick Lamaiziere wrote: Le Fri, 26 Aug 2011 15:26:28 +, Johan Hendriks jo...@double-l.nl a ?crit : I am trying to set up CARP under 9.0 ... Also with a higer value like advskew 200 or 254 the role of the servers stays the same. Ok, there is something wrong so. Did you check that the sysctl net.inet.carp.suppress_preempt is equal to zero ? If yes, I don't have any more idea. Regards. Hello first off all thanks for your time. sysctl -a | grep carp on both machines give me the following output sysctl -a | grep carp device carp net.inet.ip.same_prefix_carp_only: 0 net.inet.carp.allow: 1 net.inet.carp.preempt: 0 net.inet.carp.log: 2 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 netstat -s on the master carp: 260 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 11430 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error netstat -s on the slave carp: 11735 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 448 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error tcpdump -i bge0 on slave 20:10:48.868200 IP 192.168.50.40 vrrp.mcast.net: VRRPv2, Advertisement, vrid 1, prio 50, authtype none, intvl 1s, length 36 Here the advskew is set to 50, on the slave it is 20. So the slave should be the master. if i raise the advskew to 254, i see the change in the capture. Both machines are fresh install with nothing changed on them so far just a fresh build from a csup this morning. And installed bash as the shell.. for freebsd-current@ the /etc/rc.conf file again Master ifconfig_bge0=inet 192.168.50.40 netmask 255.255.255.0 defaultrouter=192.168.50.150 # CARP cloned_interfaces=carp0 ifconfig_carp0=vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 255.255.255.0 On the slave i have the following in /etc/rc.conf ifconfig_bge0=inet 192.168.50.41 netmask 255.255.255.0 defaultrouter=192.168.50.150 # CARP cloned_interfaces=carp0 ifconfig_carp0=vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 255.255.255.0 regards, Johan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: F_RDLCK lock to FreeBSD NFS server fails to R/O target file [PATCH]
John wrote:
After pondering the best way to allow the VOP_ACCESS() call to
only query for the permissions really needed, I've come up with
a patch that minimally adds one parameter to the nlm_get_vfs_state()
function call with the lock type from the original argp.
http://people.freebsd.org/~jwd/nlm_prot_impl.c.accmode.patch
I took a look at it and it seemed mostly ok. However, please note that
I am not familiar with the NLM code and try to avoid it like the plague.:-)
One place I would suggest might want to be changed is the nlm_do_unlock()
case. I don't think any file permission checking is needed for an unlock
and it seems like it might fail when the called has VWRITE but not VREAD
permissions on the file? Leaving a file locked is not a good situation.
I would just not even do the VOP_ACCESS() call for that case.
Maybe pass accmode == 0 into nlm_get_vfs_state() to indicate skip the
VOP_ACCESS() call.
I think that this patch might be a little risky to put into head at this
stage of the release cycle so, personally, I'd wait until after the 9.0
release before I'd look at committing it. Others might feel it's ok to
go in now?
rick
I'd appreciate a review and seeing what might be required to commit
this prior to 9 release.
Thanks,
John
- John's Original Message -
Hi Fellow NFS'ers,
I believe I have found the problem we've been having with read
locks
while attaching to a FreeBSD NFS server.
In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there
is a call
to VOP_ACCESS() as follows:
/*
* Check cred.
*/
NLM_DEBUG(3, nlm_get_vfs_state(): Calling
VOP_ACCESS(VWRITE) with cred-cr_uid=%d\n,cred-cr_uid);
error = VOP_ACCESS(vs-vs_vp, VWRITE, cred, curthread);
if (error) {
NLM_DEBUG(3, nlm_get_vfs_state(): caller_name = %s
VOP_ACCESS() returns %d\n,
host-nh_caller_name, error);
goto out;
}
The file being accessed is read only to the user, and open()ed
with
O_RDONLY. The lock being requested is for a read.
fd = open(filename, O_RDONLY, 0);
...
lblk.l_type = F_RDLCK;
lblk.l_start = 0;
lblk.l_whence= SEEK_SET;
lblk.l_len = 0;
lblk.l_pid = 0;
rc = fcntl(fd, F_SETLK, lblk);
Running the above from a remote system, the lock call fails with
errno set to ENOLCK. Given cred-cr_uid comes in as 227 which is
my uid on the remote system. Since the file is R/O to me, and the
VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES,
Permission denied.
The above operations work correctly to some of our other
favorite big-name nfs vendors :-)
Opinions on the correct way to fix this?
1. Since we're only asking for a read lock, why do we need to ask
for VWRITE? I may not understand an underlying requirement for
the VWRITE so please feel free to educate me if needed.
Something like: request == F_RDLCK ? VREAD : VWRITE
(need to figure out where to get the request from in this
context).
2. Attempt VWRITE, fallback to VREAD... seems off to me though.
3. Other?
I appreciate any thoughts on this.
Thanks,
John
While they might not follow style(9) completely, I've uploaded
my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added.
I'd appreciate it if someone would consider committing them so
who ever debugs this file next will have them available.
http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch
___
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kqueue and device driver experience anyone ?
On Fri, Aug 26, 2011 at 01:13:03PM -0400, John Baldwin wrote: On Friday, August 26, 2011 11:39:40 am Luigi Rizzo wrote: a question for the kqueue experts out there: I am trying to add kqueue support to a device driver, and am puzzled on what the .f_event() function may assume. I see that some of the examples (e.g. bpf, audit_pipe.c) expect that the function is called with the device lock held (and even have a LOCK_ASSERT). Others (if_tap, cam/scsi/scsi_target.c) either do not use the lock or explicitly acquire it. As far as i can tell the .f_event() function is called in two places: - within knote() which in turn (through KNOTE_*() ) is called by the driver itself near selrecord() . So it is up to the device driver to call it with the device lock held; - within kqueue_scan(), which instead is called from the upper half of the kernel as part of kern_kevent(). Here there seems to be no way that the device lock is acquired when .f_event() is called. Unless, of course, the knote's on which these .f_event() are called are not the same ones attached to devices -- so there is a different .f_event() function called ? So, is there a bug in the kqueue support for bpf.c and audit_pipe.c, or i am missing something important ? Note that the top-half code may end up locking the device's mutex if the mutex was tied to the knote list when the knote list was created (e.g. knlist_init_mtx()). In general if you want to use locking to protect your knlist, you should tell the knlist about the locking to use, then there are variants of KNOTE() that let it know if the calling code already holds the appropriate lock or not (KNOTE_LOCKED() and KNOTE_UNLOCKED()). ok, got it -- i see that bpf calls knlist_init_mtx() at init time. So i can try to do something similar in my case, though i need to deal with multiqueue cards which might be a bit trickier. The other thing i need (but i believe i know how to handle it) is tell whether .f_event() is called by KNOTE() or by kqueue_scan(), but i believe i can use the hint argument to tell the two. I guess i should add some notes to kqueue(9) once i understand it better. thanks for the clarification luigi The o -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: CARP on 9.0 (was no subject)
SOLVED! Was a typo in /etc/sysctl.conf Sorry for the noise and thanks for your time. regards Johan Van: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] namens Johan Hendriks [jo...@double-l.nl] Verzonden: vrijdag 26 augustus 2011 20:22 Aan: Brian Seklecki (Mobile); freebsd-questi...@freebsd.org CC: freebsd-current@freebsd.org Onderwerp: RE: CARP on 9.0 (was no subject) How about: %sudo netstat -s carp ...on both machines. A few years ago I submitted (or maybe it was Steve Polyack) a patch to add debugging to CARP, not sure if it ever got commited. Need-more-Cisco'sih-Debugging. ~BAS On Fri, 26 Aug 2011, Patrick Lamaiziere wrote: Le Fri, 26 Aug 2011 15:26:28 +, Johan Hendriks jo...@double-l.nl a ?crit : I am trying to set up CARP under 9.0 ... Also with a higer value like advskew 200 or 254 the role of the servers stays the same. Ok, there is something wrong so. Did you check that the sysctl net.inet.carp.suppress_preempt is equal to zero ? If yes, I don't have any more idea. Regards. Hello first off all thanks for your time. sysctl -a | grep carp on both machines give me the following output sysctl -a | grep carp device carp net.inet.ip.same_prefix_carp_only: 0 net.inet.carp.allow: 1 net.inet.carp.preempt: 0 net.inet.carp.log: 2 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 netstat -s on the master carp: 260 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 11430 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error netstat -s on the slave carp: 11735 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 448 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error tcpdump -i bge0 on slave 20:10:48.868200 IP 192.168.50.40 vrrp.mcast.net: VRRPv2, Advertisement, vrid 1, prio 50, authtype none, intvl 1s, length 36 Here the advskew is set to 50, on the slave it is 20. So the slave should be the master. if i raise the advskew to 254, i see the change in the capture. Both machines are fresh install with nothing changed on them so far just a fresh build from a csup this morning. And installed bash as the shell.. for freebsd-current@ the /etc/rc.conf file again Master ifconfig_bge0=inet 192.168.50.40 netmask 255.255.255.0 defaultrouter=192.168.50.150 # CARP cloned_interfaces=carp0 ifconfig_carp0=vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 255.255.255.0 On the slave i have the following in /etc/rc.conf ifconfig_bge0=inet 192.168.50.41 netmask 255.255.255.0 defaultrouter=192.168.50.150 # CARP cloned_interfaces=carp0 ifconfig_carp0=vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 255.255.255.0 regards, Johan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
possible mountroot regression
It seems that after the introduction of the mountroot scripting language a user
now has exactly one chance to try to specify a correct root device at the
mountroot prompt. I am not sure that that is convenient/enough.
I suspect that the following code is the cause:
static void
vfs_mountroot_conf0(struct sbuf *sb)
{
char *s, *tok, *mnt, *opt;
int error;
sbuf_printf(sb, .onfail panic\n);
...
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ichwd attach failure
Got a newish Intel board in and decided to give it a spin. Trying to load the watchdog, I get this error below on CURRENT. Anyone able to get ichwd working on such a motherboard ? full dmesg and devinfo at http://www.tancsa.com/intel.txt and http://www.tancsa.com/intel-asl.txt isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer ichwd0: Intel Cougar Point watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 ppc0: cannot reserve I/O port range pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: mutex pf task mtx owned at /usr/src/sys/contrib/pf/net/if_pfsync.c:3163
I recently upgraded a firewall I'm using for performance testing from a March-ish 9-CURRENT to 9.0-BETA1 (csup run August 21 around 12:00 AM EDT). It's basically a GENERIC kernel with debugging disabled and things like IPsec and ALTQ enabled. Since the upgrade, after approximately an hour after it boots, the firewall stops passing any traffic (IPv4 and IPv6). OpenVPN, for example, logs the following errors: write UDPv4: Operation not permitted (code=1) Quagga, for another example, logs something similar: ripd[1696]: can't send packet : Operation not permitted0 ospfd[1702]: *** sendmsg in ospf_write failed to 172.30.0.3, id 0, off 0, len 76, interface tap0 mtu 1500: Operation not permitted If I try to ping something from the console, I get the same error message: # ping 4.2.2.2 ping: sendto: Operation not permitted It appears that PF isn't removing any entries from the state table. Note that the state table size is at its default of 1 (which correlates to the amount of memory installed on the firewall - 256 MB). State Table Total Rate current entries10013 searches 554801 13.4/s inserts100130.2/s removals 00.0/s I've tried both my current (unmodified and working prior to the upgrade) and experimental PF configurations, neither of which have any effect on the problem. Reloading the PF configuration (/etc/rc.d/pf reload) or restarting PF altogether (/etc/rc.d/pf restart) also have no effect. Only if I shut down PF completely (/etc/rc.d/pf stop) do I regain network connectivity - I can do things like ping hosts (IPv4 and IPv6), browse the web, and pass traffic that's just routed through the firewall (i.e., not requiring NAT). Clearing the state table (pfsync -F state) has no effect. The kernel I'm was running had debugging disabled for performance testing purposes, so I booted a proper debug kernel. It panicked in pfsync_send_plus as soon as init enabled PF (backtrace included below). Starting pflog. pflog0: promiscuous mode enabled Aug 25 20:54:21 pflogd[1611]: [priv]: msg PRIV_OPEN_LOG received Enabling pfpanic: mutex pf task mtx owned at /usr/src/sys/contrib/pf/net/if_pfsync.c:3163 cpuid = 0 KDB: enter: panic [ thread pid 1619 tid 100053 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 1619 tid 100053 td 0xc23da2e0 kdb_enter(c09777c9,c09777c9,c0975d7b,c6fd79e0,0,...) at kdb_enter+0x3a panic(c0975d7b,c0946080,c0944e87,c5b,c6fd7a0c,...) at panic+0x134 _mtx_assert(c0a1b388,0,c0944e87,c5b,c6fd7a24,...) at _mtx_assert+0x127 pfsync_send_plus(c6fd7a24,18,10,ad6,100,...) at pfsync_send_plus+0xf2 pfsync_clear_states(a218d664,c236fb78,c0945f1c,635,c09ae167,...) at pfsync_clear_states+0x8d pfioctl(c22a0800,c0cc4412,c236fb00,3,c23da2e0,...) at pfioctl+0x1b90 devfs_ioctl_f(c23ce578,c0cc4412,c236fb00,c216ce80,c23da2e0,...) at devfs_ioctl_f+0x10b kern_ioctl(c23da2e0,3,c0cc4412,c236fb00,1fd7cec,...) at kern_ioctl+0x21d ioctl(c23da2e0,c6fd7cec,c6fd7d28,c097d93a,0,...) at ioctl+0x134 syscallenter(c23da2e0,c6fd7ce4,c6fd7ce4,0,0,...) at syscallenter+0x263 syscall(c6fd7d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281e6263, esp = 0xbfbfe8ac, ebp = 0xbfbfe998 --- db I'm at a loss as to how to proceed. Is this a known problem with PF? Can anyone suggest a work-around? Best wishes, Matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ichwd attach failure
John was working on this, haven't seen an update recently though. Doug On 08/26/2011 14:24, Mike Tancsa wrote: Got a newish Intel board in and decided to give it a spin. Trying to load the watchdog, I get this error below on CURRENT. Anyone able to get ichwd working on such a motherboard ? full dmesg and devinfo at http://www.tancsa.com/intel.txt and http://www.tancsa.com/intel-asl.txt isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer ichwd0: Intel Cougar Point watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 ppc0: cannot reserve I/O port range pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
NFS mountd version 3 over TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0. When I attempt the mount, it logs this message: The NFS server does not support MOUNT version 3 over TCP Have I configured something wrong and if so what? Or is this something related to the new NFS code? Thanks, Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWEtYAAoJEPXPYrMgexuhWyAIAJ8Mfkjc8gtXxIYpbIDM2ECR B6ke25NNJj4Q41a77gqPsUr6nIePwoa6LlBcTNtQxx8xtC3CobB/QBjiGSLqQKoF cdcXj34tKE6e4cxptw+fYh7JXLalmmqd9BXgkKGf98UzXVDT0elIK7Ke/0thDp4s SOPO8VZ6tdMgo98oONk7qmv8nR2OhnXuJVBRBIc+Xfppq23/5u2GNeaqiJRv3Ace xVEusvPLAFtsCbyivoL27uqvJlNrA/cxA/VjzycYC+OhQ+deF3l8Ba0WNbVFSSjA tDXjT3acrHiAw7iej7Kqs9G1sZByFvymTl86E449+o6Y+1hs2Xn/3POUwWfaCqU= =U1iG -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS mountd version 3 over TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/11 21:41, Steve Wills wrote: Hi, I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0. When I attempt the mount, it logs this message: The NFS server does not support MOUNT version 3 over TCP Have I configured something wrong and if so what? Or is this something related to the new NFS code? I guess a little more info would be helpful... rc.conf has: nfs_server_enable=YES rpcbind_enable=YES mountd_enable=YES rpc_statd_enable=YES rpc_lockd_enable=YES /etc/exports contains, amongst others: /boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask 255.255.255.0 rpcinfo shows: program version netid addressserviceowner 104tcp 0.0.0.0.0.111 rpcbindsuperuser 103tcp 0.0.0.0.0.111 rpcbindsuperuser 102tcp 0.0.0.0.0.111 rpcbindsuperuser 104udp 0.0.0.0.0.111 rpcbindsuperuser 103udp 0.0.0.0.0.111 rpcbindsuperuser 102udp 0.0.0.0.0.111 rpcbindsuperuser 104tcp6 ::.0.111 rpcbindsuperuser 103tcp6 ::.0.111 rpcbindsuperuser 104udp6 ::.0.111 rpcbindsuperuser 103udp6 ::.0.111 rpcbindsuperuser 104local /var/run/rpcbind.sock rpcbindsuperuser 103local /var/run/rpcbind.sock rpcbindsuperuser 102local /var/run/rpcbind.sock rpcbindsuperuser 151udp6 ::.2.224 mountd superuser 153udp6 ::.2.224 mountd superuser 151tcp6 ::.2.224 mountd superuser 153tcp6 ::.2.224 mountd superuser 151udp 0.0.0.0.2.224 mountd superuser 153udp 0.0.0.0.2.224 mountd superuser 151tcp 0.0.0.0.2.224 mountd superuser 153tcp 0.0.0.0.2.224 mountd superuser tcpdump here: http://people.freebsd.org/~swills/nfs_debug.pcap Suggestions appreciated, thanks! Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWFOLAAoJEPXPYrMgexuhCvoH/1ky5qXxfQhgTdtYEDbCsfo4 J3xiFG9es+ajpNa1LtqlaMBrvs5fxfv0F7bzklOvUKmsVE4FPuFrcOd6IvIwTw+T U63UFocls3ZufNH+VjzxkFc5jfQ8hTDWXjKPfGMUxrCekt4pcEX4uze+I3YV/WRR IFLTkfUCLvgEJSHn39Yl7ZmHud6kJaUUQv5ne8vWgd8KRNt4IWQqvqltYZDvwY1f 8ajYxJDwKOkVRMhRwh+4O0Fgs3Owar1W0JyNzmJ+Se9/QIVzTwQS6Q4l3jQjfSrU YvRpMFQrb/ChZGZnH//FrXWhHK3TPg++XcRe1PGdY6KB+Fh1gjz+DRzbf5CzYBo= =dp9s -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS mountd version 3 over TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/11 22:16, Steve Wills wrote: On 08/26/11 21:41, Steve Wills wrote: Hi, I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0. When I attempt the mount, it logs this message: The NFS server does not support MOUNT version 3 over TCP Have I configured something wrong and if so what? Or is this something related to the new NFS code? I guess a little more info would be helpful... rc.conf has: nfs_server_enable=YES rpcbind_enable=YES mountd_enable=YES rpc_statd_enable=YES rpc_lockd_enable=YES /etc/exports contains, amongst others: /boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask 255.255.255.0 rpcinfo shows: program version netid addressserviceowner 104tcp 0.0.0.0.0.111 rpcbindsuperuser 103tcp 0.0.0.0.0.111 rpcbindsuperuser 102tcp 0.0.0.0.0.111 rpcbindsuperuser 104udp 0.0.0.0.0.111 rpcbindsuperuser 103udp 0.0.0.0.0.111 rpcbindsuperuser 102udp 0.0.0.0.0.111 rpcbindsuperuser 104tcp6 ::.0.111 rpcbindsuperuser 103tcp6 ::.0.111 rpcbindsuperuser 104udp6 ::.0.111 rpcbindsuperuser 103udp6 ::.0.111 rpcbindsuperuser 104local /var/run/rpcbind.sock rpcbindsuperuser 103local /var/run/rpcbind.sock rpcbindsuperuser 102local /var/run/rpcbind.sock rpcbindsuperuser 151udp6 ::.2.224 mountd superuser 153udp6 ::.2.224 mountd superuser 151tcp6 ::.2.224 mountd superuser 153tcp6 ::.2.224 mountd superuser 151udp 0.0.0.0.2.224 mountd superuser 153udp 0.0.0.0.2.224 mountd superuser 151tcp 0.0.0.0.2.224 mountd superuser 153tcp 0.0.0.0.2.224 mountd superuser As you might guess, this rpcinfo output indicates nfsd wasn't running. I am seeing this: can't bind udp addr *: Address already in use in syslog. Setting this: nfs_server_flags=-t -n 4 allowed it to startup, but it then timed out an fsinfo call. Adding -o to the nfs_server_flags to use the old nfs server allowed vmware to mount. FWIW, I can't find any reason for the udp message above, nothing seems to be using it that I can find. Ideas? tcpdumps are available if anyone want them. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWF6PAAoJEPXPYrMgexuhHPYIAJ6SVxtORDbesvU35ktAS/id 5iWyTWO3CTHXT42uP4IZBT1o2AWFu6e9wUX84YEZyujMln0E++8hZccaa8zQBJhr febHkZxqPdQOo/mpg1ci5J70Hs1UBV9cxU3uOA83vxunOM6xwA0B+4krfflj/k7P cPtpztmuepQQ8/S5hB5ajnfM/gFOh1f2uPwWTj2/5NSWMoVfN3f0539bh05XKfRa 4X7XKxN/J4HBRGaNjnL8IWu86AW60H9Q3gdisdtT0k9sK4X3DswmiRMlMt4M4rS8 oX0vrgruTiKZf+bsraYvhuo4JyselXMicTnW7rUOVx8jiNVVk1nymSVF1XDUOrw= =MeJv -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
