wireless device cant go thru wap to nfs/smb server
I posted this to -mobile, but im gonna send it here in case anyone might have a better idea. thanks I have a fbsd 4.8 router which also acts as my wireless access point, bridging the wireless interface to the internal nic. on top of that, up until recently, it was my nfs/smb file server as well. Everything was working fine in this setup, so i had to go and change something, and create new problems;) I moved the file serving over to a newer box, that will be dedicated mainly just to NFS and SMB [depending on whether its a windows machine or NIX machine accessing it]. Computers on the network connected over ethernet are able to mount shares and manipulate the data on the shares just fine [copying files back and forth, listening to music, etc]. When i try to mount an NFS or SMB share from a device connected wirelessly, im able to do this just fine. However, with NFS im unable to do much with the data. I can browse thru the data just fine [eg, viewing mp3s in xmms]. But as soon as i try to move data from the remote share to the local system, it seems to cause the share to just sorta hang. If i open up a term, and do a simple ls /share it the term becomes unresponsive. even ctrl+c doesnt save me. the only way ive figured out how to return the system to normal is a umount -f /share and this isnt the most elegant or proper solution. With SMB its a similar story. I after its mounted, i can brown the share. If i go to play a song thru xmms, it will play, but it will pause almost every second, tho it will continue playing [so i guess technically its more affective, at this point, than NFS]. If i switch my wireless devices to a wired connection, then everything works fine. So it seems pretty clear its not an issue with the wireless devices themselves, but the means of connection. My assumption is because im going thru the router/wap to get to the fileserver, this is somehow mucking up the way NFS/SMB do things. But I have no idea exactly why its doing this, and even more importantly, no idea how to fix this problem, besides making the router/wap the fileserver again, or making the new fileserver the wap [and this might not even work, as i havent tried it yet]. and both of these solutions are far from ideal. thanks for the help. yussef update: since making the initial post to mobile, it's become more clear to me this probably isnt an issue with nfs/smb but something to do with the way bridging works. I've yet to have a look thru the code [and im no programmer], tho i plan to look thru, and see if anything catches my eye. in the mean time, i thought maybe someone else more in the know, might have an idea about a solution. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wireless device cant go thru wap to nfs/smb server
Hey, You might consider doing some tests to see if you get packet loss to the NFS/SMB server. That seems to be the issue. It would make sense that nfs would act weird, as nfs doesnt like packet loss :) What is happening with winamp seems logical as well, in this situation. If it does indeed turn out to be packet loss, then i'd consider investing in a real access point and plugging in with a crossover cable into an ethernet interface on your router box. I assume that you currently use a PCMCIA card+adapter. -Anthony On Tue, 21 Oct 2003, yussef wrote: I posted this to -mobile, but im gonna send it here in case anyone might have a better idea. thanks I have a fbsd 4.8 router which also acts as my wireless access point, bridging the wireless interface to the internal nic. on top of that, up until recently, it was my nfs/smb file server as well. Everything was working fine in this setup, so i had to go and change something, and create new problems;) I moved the file serving over to a newer box, that will be dedicated mainly just to NFS and SMB [depending on whether its a windows machine or NIX machine accessing it]. Computers on the network connected over ethernet are able to mount shares and manipulate the data on the shares just fine [copying files back and forth, listening to music, etc]. When i try to mount an NFS or SMB share from a device connected wirelessly, im able to do this just fine. However, with NFS im unable to do much with the data. I can browse thru the data just fine [eg, viewing mp3s in xmms]. But as soon as i try to move data from the remote share to the local system, it seems to cause the share to just sorta hang. If i open up a term, and do a simple ls /share it the term becomes unresponsive. even ctrl+c doesnt save me. the only way ive figured out how to return the system to normal is a umount -f /share and this isnt the most elegant or proper solution. With SMB its a similar story. I after its mounted, i can brown the share. If i go to play a song thru xmms, it will play, but it will pause almost every second, tho it will continue playing [so i guess technically its more affective, at this point, than NFS]. If i switch my wireless devices to a wired connection, then everything works fine. So it seems pretty clear its not an issue with the wireless devices themselves, but the means of connection. My assumption is because im going thru the router/wap to get to the fileserver, this is somehow mucking up the way NFS/SMB do things. But I have no idea exactly why its doing this, and even more importantly, no idea how to fix this problem, besides making the router/wap the fileserver again, or making the new fileserver the wap [and this might not even work, as i havent tried it yet]. and both of these solutions are far from ideal. thanks for the help. yussef update: since making the initial post to mobile, it's become more clear to me this probably isnt an issue with nfs/smb but something to do with the way bridging works. I've yet to have a look thru the code [and im no programmer], tho i plan to look thru, and see if anything catches my eye. in the mean time, i thought maybe someone else more in the know, might have an idea about a solution. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
network lkm
Regards, would you provide me with an example of network module under linux kernel 2.4. -- --peace for all-- ___ Take your business online with Officemaster. Sign up for a free trial today! http://www.officemaster.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
no subject
would you help me in writing network LKM under linux kernel 2.4, small examole would be good. -- --peace for all-- ___ Web-based office space for rent. Free trial! http://www.officemaster.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no subject
maya Haddad writes: would you help me in writing network LKM under linux kernel 2.4, small examol e would be good. You sent this to a FreeBSD list, you need to find a Linux list instead. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Wed, Oct 22, 2003 at 12:22:35PM +1000, Q wrote: Can someone comment on whether this is something that has been done intentionally, or avoided in favour of some other yet to be implemented solution? Or is it still on someones todo list. You can consult the FreeBSD and OpenBSD CVS repositories (http://cvsweb.freebsd.org, the equivalent OpenBSD URL is listed on their website) to find the history of this code. I don't know if there is any Linux source history browser because of the historical lack of published revision control files for the kernel. Kris pgp0.pgp Description: PGP signature
Re: network lkm
On Wed, Oct 22, 2003 at 10:55:50AM +0300, maya Haddad wrote: Regards, would you provide me with an example of network module under linux kernel 2.4. No. Have a nice day! Kris P.S. Try a Linux list :-) pgp0.pgp Description: PGP signature
Re: Some mmap observations compared to Linux 2.6/OpenBSD
In message [EMAIL PROTECTED], Kris Kennaway wrote: On Wed, Oct 22, 2003 at 12:22:35PM +1000, Q wrote: Can someone comment on whether this is something that has been done intentionally, or avoided in favour of some other yet to be implemented solution? Or is it still on someones todo list. You can consult the FreeBSD and OpenBSD CVS repositories (http://cvsweb.freebsd.org, the equivalent OpenBSD URL is listed on their website) to find the history of this code. I don't know if there is any Linux source history browser because of the historical lack of published revision control files for the kernel. After 2.4, Linux use BitKeeper repository and the repository can be browsed on http://linux.bkbits.net/ . ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Wed, Oct 22, 2003 at 05:38:45PM +0900, User Takawata wrote: In message [EMAIL PROTECTED], Kris Kennaway wrote: On Wed, Oct 22, 2003 at 12:22:35PM +1000, Q wrote: Can someone comment on whether this is something that has been done intentionally, or avoided in favour of some other yet to be implemented solution? Or is it still on someones todo list. You can consult the FreeBSD and OpenBSD CVS repositories (http://cvsweb.freebsd.org, the equivalent OpenBSD URL is listed on their website) to find the history of this code. I don't know if there is any Linux source history browser because of the historical lack of published revision control files for the kernel. After 2.4, Linux use BitKeeper repository and the repository can be browsed on http://linux.bkbits.net/ . OK, I'm glad to hear that after 9 years sanity has caught up with them :-) Kris pgp0.pgp Description: PGP signature
Re: Some mmap observations compared to Linux 2.6/OpenBSD
Thanks, I have already looked over the repositories to determine how they differed. I wasn't really asking about the history of these changes in the other projects, but rather the history of why FreeBSD HASN'T also gone down this road. There doesn't appear to be anything in CVS or the mail archives that I can find that would indicate any intention to change the current implementation. Seeya...Q On Wed, 2003-10-22 at 18:29, Kris Kennaway wrote: On Wed, Oct 22, 2003 at 12:22:35PM +1000, Q wrote: Can someone comment on whether this is something that has been done intentionally, or avoided in favour of some other yet to be implemented solution? Or is it still on someones todo list. You can consult the FreeBSD and OpenBSD CVS repositories (http://cvsweb.freebsd.org, the equivalent OpenBSD URL is listed on their website) to find the history of this code. I don't know if there is any Linux source history browser because of the historical lack of published revision control files for the kernel. Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Wed, Oct 22, 2003 at 07:51:28PM +1000, Q wrote: Thanks, I have already looked over the repositories to determine how they differed. I wasn't really asking about the history of these changes in the other projects, but rather the history of why FreeBSD HASN'T also gone down this road. There doesn't appear to be anything in CVS or the mail archives that I can find that would indicate any intention to change the current implementation. I'm assuming that FreeBSD has some version of the historical BSD implementation, and the change was made in OpenBSD (or perhaps NetBSD before the split), and it has not been considered before in FreeBSD. I have no familiarity with the code in question, however. Kris pgp0.pgp Description: PGP signature
Re: Some mmap observations compared to Linux 2.6/OpenBSD
Yes, it would appear this is a legacy thing that existed in the original 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still use this technique, but OpenBSD changed to using Red-Black trees back in Feb 2002. The actual commit quote reads: use a red-black tree to find entries in the vm_map. augment the red-black tree to find free space between entries. speeds up memory allocation, etc... I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Seeya...Q On Wed, 2003-10-22 at 19:57, Kris Kennaway wrote: On Wed, Oct 22, 2003 at 07:51:28PM +1000, Q wrote: Thanks, I have already looked over the repositories to determine how they differed. I wasn't really asking about the history of these changes in the other projects, but rather the history of why FreeBSD HASN'T also gone down this road. There doesn't appear to be anything in CVS or the mail archives that I can find that would indicate any intention to change the current implementation. I'm assuming that FreeBSD has some version of the historical BSD implementation, and the change was made in OpenBSD (or perhaps NetBSD before the split), and it has not been considered before in FreeBSD. I have no familiarity with the code in question, however. Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
boot0/1 problems
I seem to have stubbed my toe on another nasty little bootstrap problem. My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the %dl register when it invokes the MBR bootstrap program, boot0. This forces me to configure the MBR bootstrap with the setdrv option. The noupdate option must also be set because otherwise I risk writing the MBR partition table back to the wrong disk and that would be a major disaster. Here is the problem: the boot1 program depends on the boot0 program setting the active partition flag in the MBR partition table. This doesn't happen if the boot0 noupdate option is set. The boot1 program always boots the active FreeBSD slice (or the first FreeBSD slice if there is no active FreeBSD slice). If you have multiple FreeBSD slices on a disk whose boot0 program is configured with the noupdate option, YOU CAN ONLY BOOT ONE OF THE SLICES. I have release 4.9-RCx and 5.1 slices on the same disk. If the 5.1 slice is active, the system wedges hard if I attempt to boot the 4.9-RCx slice. If the 4.9-RCx slice is active, the system resets if I attempt to boot the 5.1 slice. This really sucks. Can someone who knows how the bootx programs are supposed to work verify that my understanding of the problem is probably correct? Can someone suggest a workaround? I don't have the option of installing the different operating systems on different disks and I can't get the AWARD BIOS fixed. Dan Strick [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
In the last episode (Oct 22), Q said: Yes, it would appear this is a legacy thing that existed in the original 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still use this technique, but OpenBSD changed to using Red-Black trees back in Feb 2002. The actual commit quote reads: use a red-black tree to find entries in the vm_map. augment the red-black tree to find free space between entries. speeds up memory allocation, etc... I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Probably just a case of too much to do and not enough people to do it. FreeBSD already has sys/tree.h, which provides the red-black tree macros. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pb compiled freebsd 49rc3 (iso)
Hi, Im found pb compiled : # cd /sys # make . cc -O -pipe -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOMPORT=0x3f8 -DCOMSPEED=9600 -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -DTERM_EMU -mpreferred-stack-boundary=2 -c i386_module.c -o i386_module.o cc -O -pipe -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOMPORT=0x3f8 -DCOMSPEED=9600 -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -DTERM_EMU -mpreferred-stack-boundary=2 -c nullconsole.c -o nullconsole.o cc -O -pipe -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOMPORT=0x3f8 -DCOMSPEED=9600 -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -DTERM_EMU -mpreferred-stack-boundary=2 -c pxe.c -o pxe.o pxe.c:41: net.h: No such file or directory pxe.c:42: netif.h: No such file or directory pxe.c:43: nfsv2.h: No such file or directory pxe.c:44: iodesc.h: No such file or directory pxe.c:46: bootp.h: No such file or directory pxe.c:84: warning: `struct netif' declared inside parameter list pxe.c:84: warning: its scope is only this definition or declaration, which is probably not what you want. pxe.c:85: warning: `struct netif' declared inside parameter list pxe.c:86: warning: `struct iodesc' declared inside parameter list pxe.c:88: warning: `struct iodesc' declared inside parameter list pxe.c:89: warning: `struct iodesc' declared inside parameter list pxe.c:90: warning: `struct netif' declared inside parameter list pxe.c:100: elements of array `pxe_ifs' have incomplete type pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:102: invalid use of undefined type `struct netif_stats' pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:103: invalid use of undefined type `struct netif_dif' pxe.c:105: variable-size type declared outside of any function pxe.c:107: variable `pxenetif' has initializer but incomplete type pxe.c:108: warning: excess elements in struct initializer pxe.c:108: warning: (near initialization for `pxenetif') pxe.c:109: warning: excess elements in struct initializer pxe.c:109: warning: (near initialization for `pxenetif') pxe.c:110: warning: excess elements in struct initializer pxe.c:110: warning: (near initialization for `pxenetif') pxe.c:111: warning: excess elements in struct initializer pxe.c:111: warning: (near initialization for `pxenetif') pxe.c:112: warning: excess elements in struct initializer pxe.c:112: warning: (near initialization for `pxenetif') pxe.c:113: warning: excess elements in struct initializer pxe.c:113: warning: (near initialization for `pxenetif') pxe.c:114: warning: excess elements in struct initializer pxe.c:114: warning: (near initialization for `pxenetif') pxe.c:115: warning: excess elements in struct initializer pxe.c:115: warning: (near initialization for `pxenetif') pxe.c:117: warning: excess elements in struct initializer pxe.c:117: warning: (near initialization for `pxenetif') pxe.c: In function `pxe_open': pxe.c:256: `FNAME_SIZE' undeclared (first use in this function) pxe.c:256: (Each undeclared identifier is reported only once pxe.c:256: for each function it appears in.) pxe.c:276: `rootip' undeclared (first use in this function) pxe.c:283: `BOOTP_PXE' undeclared (first use in this function) pxe.c:286: `rootpath' undeclared (first use in this function) pxe.c:301: `gateip' undeclared (first use in this function) pxe.c:303: `myip' undeclared (first use in this function) pxe.c:303: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c:304: `netmask' undeclared (first use in this function) pxe.c:304: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c:305: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c:310: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c: In function `pxe_close': pxe.c:339: `rootpath' undeclared (first use in this function) pxe.c: At top level: pxe.c:413: `NFS_FHSIZE' undeclared here (not in a function) pxe.c: In function `pxe_setnfshandle': pxe.c:423: `NFS_FHSIZE' undeclared (first use in this function) pxe.c:423: size of array `buf' has non-integer type pxe.c: At top level: pxe.c:490: warning: `struct netif' declared inside parameter list pxe.c:491: conflicting types for `pxe_netif_match' pxe.c:84: previous declaration of `pxe_netif_match' pxe.c:497: warning: `struct netif'
Re: pb compiled freebsd 49rc3 (iso)
sorry, its my pb and not an Error. Regards On Wed, 22 Oct 2003, rmkml wrote: Date: Wed, 22 Oct 2003 16:47:29 +0200 (CEST) From: rmkml [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: pb compiled freebsd 49rc3 (iso) Hi, Im found pb compiled : # cd /sys # make . cc -O -pipe -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOMPORT=0x3f8 -DCOMSPEED=9600 -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -DTERM_EMU -mpreferred-stack-boundary=2 -c i386_module.c -o i386_module.o cc -O -pipe -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOMPORT=0x3f8 -DCOMSPEED=9600 -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -DTERM_EMU -mpreferred-stack-boundary=2 -c nullconsole.c -o nullconsole.o cc -O -pipe -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOMPORT=0x3f8 -DCOMSPEED=9600 -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -DTERM_EMU -mpreferred-stack-boundary=2 -c pxe.c -o pxe.o pxe.c:41: net.h: No such file or directory pxe.c:42: netif.h: No such file or directory pxe.c:43: nfsv2.h: No such file or directory pxe.c:44: iodesc.h: No such file or directory pxe.c:46: bootp.h: No such file or directory pxe.c:84: warning: `struct netif' declared inside parameter list pxe.c:84: warning: its scope is only this definition or declaration, which is probably not what you want. pxe.c:85: warning: `struct netif' declared inside parameter list pxe.c:86: warning: `struct iodesc' declared inside parameter list pxe.c:88: warning: `struct iodesc' declared inside parameter list pxe.c:89: warning: `struct iodesc' declared inside parameter list pxe.c:90: warning: `struct netif' declared inside parameter list pxe.c:100: elements of array `pxe_ifs' have incomplete type pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:102: invalid use of undefined type `struct netif_stats' pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:102: warning: excess elements in struct initializer pxe.c:102: warning: (near initialization for `pxe_ifs[0]') pxe.c:103: invalid use of undefined type `struct netif_dif' pxe.c:105: variable-size type declared outside of any function pxe.c:107: variable `pxenetif' has initializer but incomplete type pxe.c:108: warning: excess elements in struct initializer pxe.c:108: warning: (near initialization for `pxenetif') pxe.c:109: warning: excess elements in struct initializer pxe.c:109: warning: (near initialization for `pxenetif') pxe.c:110: warning: excess elements in struct initializer pxe.c:110: warning: (near initialization for `pxenetif') pxe.c:111: warning: excess elements in struct initializer pxe.c:111: warning: (near initialization for `pxenetif') pxe.c:112: warning: excess elements in struct initializer pxe.c:112: warning: (near initialization for `pxenetif') pxe.c:113: warning: excess elements in struct initializer pxe.c:113: warning: (near initialization for `pxenetif') pxe.c:114: warning: excess elements in struct initializer pxe.c:114: warning: (near initialization for `pxenetif') pxe.c:115: warning: excess elements in struct initializer pxe.c:115: warning: (near initialization for `pxenetif') pxe.c:117: warning: excess elements in struct initializer pxe.c:117: warning: (near initialization for `pxenetif') pxe.c: In function `pxe_open': pxe.c:256: `FNAME_SIZE' undeclared (first use in this function) pxe.c:256: (Each undeclared identifier is reported only once pxe.c:256: for each function it appears in.) pxe.c:276: `rootip' undeclared (first use in this function) pxe.c:283: `BOOTP_PXE' undeclared (first use in this function) pxe.c:286: `rootpath' undeclared (first use in this function) pxe.c:301: `gateip' undeclared (first use in this function) pxe.c:303: `myip' undeclared (first use in this function) pxe.c:303: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c:304: `netmask' undeclared (first use in this function) pxe.c:304: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c:305: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c:310: warning: passing arg 2 of `setenv' makes pointer from integer without a cast pxe.c: In function `pxe_close': pxe.c:339: `rootpath' undeclared (first use in this function) pxe.c: At top level: pxe.c:413: `NFS_FHSIZE' undeclared here (not in a function) pxe.c: In function `pxe_setnfshandle': pxe.c:423: `NFS_FHSIZE'
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Wed, Oct 22, 2003 at 09:40:44AM -0500, Dan Nelson wrote: The actual commit quote reads: use a red-black tree to find entries in the vm_map. augment the red-black tree to find free space between entries. speeds up memory allocation, etc... I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Probably just a case of too much to do and not enough people to do it. FreeBSD already has sys/tree.h, which provides the red-black tree macros. Now accepting patches! BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wireless device cant go thru wap to nfs/smb server
On Wed, 22 Oct 2003 03:51:58 -0400 (EDT) Anthony Volodkin [EMAIL PROTECTED] wrote: Hey, You might consider doing some tests to see if you get packet loss to the NFS/SMB server. That seems to be the issue. It would make sense that nfs would act weird, as nfs doesnt like packet loss :) What is happening with winamp seems logical as well, in this situation. I ran some basic pings tests between the access point and the wireless devices. No packetloss was seen everything was making it through. I will look into thos more thoroughly as soon as i get a chance. If it does indeed turn out to be packet loss, then i'd consider investing in a real access point and plugging in with a crossover cable into an ethernet interface on your router box. I assume that you currently use a PCMCIA card+adapter. yes im using a prism 2 based pci card. -Anthony On Tue, 21 Oct 2003, yussef wrote: I posted this to -mobile, but im gonna send it here in case anyone might have a better idea. thanks I have a fbsd 4.8 router which also acts as my wireless access point, bridging the wireless interface to the internal nic. on top of that, up until recently, it was my nfs/smb file server as well. Everything was working fine in this setup, so i had to go and change something, and create new problems;) I moved the file serving over to a newer box, that will be dedicated mainly just to NFS and SMB [depending on whether its a windows machine or NIX machine accessing it]. Computers on the network connected over ethernet are able to mount shares and manipulate the data on the shares just fine [copying files back and forth, listening to music, etc]. When i try to mount an NFS or SMB share from a device connected wirelessly, im able to do this just fine. However, with NFS im unable to do much with the data. I can browse thru the data just fine [eg, viewing mp3s in xmms]. But as soon as i try to move data from the remote share to the local system, it seems to cause the share to just sorta hang. If i open up a term, and do a simple ls /share it the term becomes unresponsive. even ctrl+c doesnt save me. the only way ive figured out how to return the system to normal is a umount -f /share and this isnt the most elegant or proper solution. With SMB its a similar story. I after its mounted, i can brown the share. If i go to play a song thru xmms, it will play, but it will pause almost every second, tho it will continue playing [so i guess technically its more affective, at this point, than NFS]. If i switch my wireless devices to a wired connection, then everything works fine. So it seems pretty clear its not an issue with the wireless devices themselves, but the means of connection. My assumption is because im going thru the router/wap to get to the fileserver, this is somehow mucking up the way NFS/SMB do things. But I have no idea exactly why its doing this, and even more importantly, no idea how to fix this problem, besides making the router/wap the fileserver again, or making the new fileserver the wap [and this might not even work, as i havent tried it yet]. and both of these solutions are far from ideal. thanks for the help. yussef update: since making the initial post to mobile, it's become more clear to me this probably isnt an issue with nfs/smb but something to do with the way bridging works. I've yet to have a look thru the code [and im no programmer], tho i plan to look thru, and see if anything catches my eye. in the mean time, i thought maybe someone else more in the know, might have an idea about a solution. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: boot0/1 problems
On 22-Oct-2003 Dan Strick wrote: I seem to have stubbed my toe on another nasty little bootstrap problem. My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the %dl register when it invokes the MBR bootstrap program, boot0. This forces me to configure the MBR bootstrap with the setdrv option. The noupdate option must also be set because otherwise I risk writing the MBR partition table back to the wrong disk and that would be a major disaster. Here is the problem: the boot1 program depends on the boot0 program setting the active partition flag in the MBR partition table. This doesn't happen if the boot0 noupdate option is set. The boot1 program always boots the active FreeBSD slice (or the first FreeBSD slice if there is no active FreeBSD slice). If you have multiple FreeBSD slices on a disk whose boot0 program is configured with the noupdate option, YOU CAN ONLY BOOT ONE OF THE SLICES. I have release 4.9-RCx and 5.1 slices on the same disk. If the 5.1 slice is active, the system wedges hard if I attempt to boot the 4.9-RCx slice. If the 4.9-RCx slice is active, the system resets if I attempt to boot the 5.1 slice. This really sucks. Can someone who knows how the bootx programs are supposed to work verify that my understanding of the problem is probably correct? Yes, it is correct. Can someone suggest a workaround? You can change the device you load the kernel from by changing the 'cuurdev' variable. Thus, if you do 'set currdev=disk1s2a' you can switch from the first slice to the second. You can set the device to mount your root filesystem from by using 'set vfs.root.mountfrom=ufs:/dev/ad0s2a'. You might be able to use the beastie menu in current and hack it to add a menu item for booting your 4.x slice and then always boot into the current loader and pick 4.x from the menu. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
contigmalloc/contigfree vmstat -m
Hi, When contigmalloc and contigfree are used, the type of memory (M_xxx) is ignored. Then vmstat -m does not report any statistics about the memory usage of this kind of object. Is it a bug or a feature ? Regards, Vincent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Wed, Oct 22, 2003 at 04:50:58PM +0100, Bruce M Simpson wrote: On Wed, Oct 22, 2003 at 09:40:44AM -0500, Dan Nelson wrote: The actual commit quote reads: use a red-black tree to find entries in the vm_map. augment the red-black tree to find free space between entries. speeds up memory allocation, etc... I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Probably just a case of too much to do and not enough people to do it. FreeBSD already has sys/tree.h, which provides the red-black tree macros. Now accepting patches! You might want to have a look at fefe's research before you take the OpenBSD way. http://bulk.fefe.de/scalability/ aha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS access_cache not working
We have puzzled long and hard over this one. I have seen similar questions in the past, but no answers: Using a FreeBSD 4.8 NFS client, mount options are the defaults. I watch for NFS activity using tcpdump. Every single stat() or open() causes access RPCs on the wire. In fact, doing cat file causes *three* access RPCs. Two of these are properly cached, but one is not. For instance, if I set vfs.nfs.access_cache_timeout=60 then cat file will cause three access RPCs. Doing the command again within 60 seconds causes just one access RPC. I don't think it should do any. 18:24:07.046508 10.10.10.106.3411144459 10.10.10.197.2049: 128 access fh Unknown/1 003f 18:24:07.049984 10.10.10.106.3411144460 10.10.10.197.2049: 128 access fh Unknown/1 003f 18:24:07.053673 10.10.10.106.3411144461 10.10.10.197.2049: 128 access fh Unknown/1 003f I get the same results using a NetApp server or a Linux server. Looking at nfs/nfs_vnops.c, it look like the result of the access rpc ought to be cached. Is this non-cached behaviour a feature that I can turn off? Other clients running linux happily cache everything, and do not cause any nfs operations until the cache times out, but then linux doesn't do any access rpc calls. The FreeBSD clients are killing the NFS server. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Passthrough block device
Does FreeBSD support a device that will allow for the passing of all reads and writes on it to a userland application? I wish to handle swapping myself, preferably without any kernel hacking. What would happen if the kernel decided to swap out such a process? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
This is interesting, and demonstrates what I have been seeing, however OpenBSD obviously has other issues with it's mmap implementation entirely separate from this discussion. The case we are discussing is only about the choice of search technique used during the allocation of the mmap region from available free space.. an area in which FreeBSD and NetBSD clearly lag behind OpenBSD. This would in no way effect the performance of using the region after it has been allocated. Seeya...Q On Thu, 2003-10-23 at 06:42, Andy wrote: On Wed, Oct 22, 2003 at 04:50:58PM +0100, Bruce M Simpson wrote: On Wed, Oct 22, 2003 at 09:40:44AM -0500, Dan Nelson wrote: The actual commit quote reads: use a red-black tree to find entries in the vm_map. augment the red-black tree to find free space between entries. speeds up memory allocation, etc... I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Probably just a case of too much to do and not enough people to do it. FreeBSD already has sys/tree.h, which provides the red-black tree macros. Now accepting patches! You might want to have a look at fefe's research before you take the OpenBSD way. http://bulk.fefe.de/scalability/ aha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
