Re: Ethernet tunnel device
* Mark Santcroos [EMAIL PROTECTED] [020220 03:52] wrote: It was indeed a linux_compat specific resource cleanup issue. I managed to create a simple linux program that had the same problem. From there on it was easy... The problem was created by Alfred's locking commit of Jan 13. (No hard feelings, it helped me to understand the code alot better! ;) ) Can someone please commit the attached (trivial) patch? Done. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
Mark Santcroos wrote: On Sat, Feb 16, 2002 at 01:02:09AM -0800, Terry Lambert wrote: Pretty clearly, if it happens, and the process is truly gone, then there is a resource track cleanup that's missing (perhaps it's a reference that results from the Linux mmap resource track cleanup not releasing it?). It was indeed a linux_compat specific resource cleanup issue. Cool. No zebras. 8-). I managed to create a simple linux program that had the same problem. From there on it was easy... The problem was created by Alfred's locking commit of Jan 13. (No hard feelings, it helped me to understand the code alot better! ;) ) Can someone please commit the attached (trivial) patch? Alfred... that would be for you? 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
* Terry Lambert [EMAIL PROTECTED] [020220 11:13] wrote: Mark Santcroos wrote: I managed to create a simple linux program that had the same problem. From there on it was easy... The problem was created by Alfred's locking commit of Jan 13. (No hard feelings, it helped me to understand the code alot better! ;) ) Can someone please commit the attached (trivial) patch? Alfred... that would be for you? 8-). All patches are trivial, it's the bugs that are a b*tch. Yes, the patch has been committed. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
Brooks Davis wrote: I think there's something else going on. You can hold open a vmnet device by the simple expedient of cat /dev/vmnet0 and when I tested with a Linux cat and killed it with a kill -9 it closed the descriptor properly. Some things I haven't tried, but though might have an effect were using fork or linux threads to create multiple refrences to the device and then closing them oddly. My next suggestion would be breaking to the kernel debugger, and finding out who holds the reference to the thing by walking through everything. The lsof program might end up being useful. Pretty clearly, if it happens, and the process is truly gone, then there is a resource track cleanup that's missing (perhaps it's a reference that results from the Linux mmap resource track cleanup not releasing it?). In any case, it might also help to put in printf's that spew each time a reference to that particular device is created or destroy; _that_, at least, would tell you about the unmatched reference that is being left around. If there were no reference around, then it wouldn't be a problem, and if it were something simple, your Linux cat test would have done the job in reproducing it. Short of asking the VMWare people for help, there's not really any way I'm going to be able to get you closer to the problem then by eliminating what can't be causing the symptoms you are seeing. I guess let us know if the printf's lead nowhere. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
On Fri, Feb 15, 2002 at 07:35:39PM -0800, Terry Lambert wrote: Maybe it's losing an open instance in the resource track on close? That seems the most likely culprit... Do you mean in the linux emu case? If so, please see my message stating that I also used a linux emu program to test this. If not, can you please be a bit more detailed? Yes. I saw your message. It wasn't clear to me that you were simply exiting in the test, instead of actually closing the descriptor. I suspect that vmware just exits, and expects a resource tracking close on exit to free the reference count. If the Linux ABI code has not been updated with all the necessary hand waving (old code was OK, new code is broke ::= that's what's happening), then that could easily cause the problem, whereas a test case that does all the right manual shutdown would not have a problem. Hi Terry, I did do an explicit close() in my test. However, using ktrace I also see a explicit close from vmware. That one doesn't reach the tap device however. So we are back to the original question, where does the close gets lost. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
Hi Terry, On Wed, Feb 13, 2002 at 04:59:41PM -0800, Terry Lambert wrote: There's one difference between vmware and a little hacked up test app. Linux emulation. It certaintly shouldn't matter, but it might be worth compiling the test program on a linux machine and seeing it it leaves the device in a weird state like vmware. Maybe it's losing an open instance in the resource track on close? That seems the most likely culprit... Do you mean in the linux emu case? If so, please see my message stating that I also used a linux emu program to test this. If not, can you please be a bit more detailed? Thanks alot. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
Mark Santcroos wrote: On Wed, Feb 13, 2002 at 04:59:41PM -0800, Terry Lambert wrote: There's one difference between vmware and a little hacked up test app. Linux emulation. It certaintly shouldn't matter, but it might be worth compiling the test program on a linux machine and seeing it it leaves the device in a weird state like vmware. Maybe it's losing an open instance in the resource track on close? That seems the most likely culprit... Do you mean in the linux emu case? If so, please see my message stating that I also used a linux emu program to test this. If not, can you please be a bit more detailed? Yes. I saw your message. It wasn't clear to me that you were simply exiting in the test, instead of actually closing the descriptor. I suspect that vmware just exits, and expects a resource tracking close on exit to free the reference count. If the Linux ABI code has not been updated with all the necessary hand waving (old code was OK, new code is broke ::= that's what's happening), then that could easily cause the problem, whereas a test case that does all the right manual shutdown would not have a problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
On Fri, Feb 15, 2002 at 07:35:39PM -0800, Terry Lambert wrote: I saw your message. It wasn't clear to me that you were simply exiting in the test, instead of actually closing the descriptor. I suspect that vmware just exits, and expects a resource tracking close on exit to free the reference count. If the Linux ABI code has not been updated with all the necessary hand waving (old code was OK, new code is broke ::= that's what's happening), then that could easily cause the problem, whereas a test case that does all the right manual shutdown would not have a problem. I think there's something else going on. You can hold open a vmnet device by the simple expedient of cat /dev/vmnet0 and when I tested with a Linux cat and killed it with a kill -9 it closed the descriptor properly. Some things I haven't tried, but though might have an effect were using fork or linux threads to create multiple refrences to the device and then closing them oddly. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg34788/pgp0.pgp Description: PGP signature
Re: Ethernet tunnel device
FROM: Mark SantcroosDATE: 02/12/2002 02:58:30SUBJECT: RE: Ethernet tunnel device On Mon, Feb 11, 2002 at 12:14:32PM -0800, Brooks Davis wrote: | It sounds like there's some sort of a bug in the close code. You are | sure the previous instance is really gone, right? If it is, that's | another issue. | |The tapclose() function is not called at all in this case. (I've put some |debugging statement in the tap driver) |I don't understand because I do see a successful close() from vmware |(using ktrace). | |Writing a simple app that opens '/dev/vmnet1' and closes it again works |fine. | |What would be the difference for this simple case and the vmware case? |(I also made a linux binary of the same simple program and that one works |too, just to be sure) | |Making a simple (and very possible wrong) conclusion is that the open call |gets lost between userland and the driver. (vfs layer?) | |Any hints on where too look further would be very helpful. | |Mark how come it gets lost in the vmware case and not in your simple app. also does ifconfig report that the vmnet device is opened by the pid of your app between open and close of the simple app? I dont know much either just some shots in the dark!! Saurabh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
On Wed, Feb 13, 2002 at 11:13:58AM -0800, whoever wrote: how come it gets lost in the vmware case and not in your simple app. also does ifconfig report that the vmnet device is opened by the pid of your app between open and close of the simple app? There's one difference between vmware and a little hacked up test app. Linux emulation. It certaintly shouldn't matter, but it might be worth compiling the test program on a linux machine and seeing it it leaves the device in a weird state like vmware. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg34734/pgp0.pgp Description: PGP signature
Re: Ethernet tunnel device
On Wed, Feb 13, 2002 at 11:19:37AM -0800, Brooks Davis wrote: On Wed, Feb 13, 2002 at 11:13:58AM -0800, whoever wrote: how come it gets lost in the vmware case and not in your simple app. also does ifconfig report that the vmnet device is opened by the pid of your app between open and close of the simple app? There's one difference between vmware and a little hacked up test app. Linux emulation. It certaintly shouldn't matter, but it might be worth compiling the test program on a linux machine and seeing it it leaves the device in a weird state like vmware. -- Brooks Mark tried that too, see message #7812934 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
Brooks Davis wrote: On Wed, Feb 13, 2002 at 11:13:58AM -0800, whoever wrote: how come it gets lost in the vmware case and not in your simple app. also does ifconfig report that the vmnet device is opened by the pid of your app between open and close of the simple app? There's one difference between vmware and a little hacked up test app. Linux emulation. It certaintly shouldn't matter, but it might be worth compiling the test program on a linux machine and seeing it it leaves the device in a weird state like vmware. Maybe it's losing an open instance in the resource track on close? That seems the most likely culprit... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
On Mon, Feb 11, 2002 at 12:14:32PM -0800, Brooks Davis wrote: It sounds like there's some sort of a bug in the close code. You are sure the previous instance is really gone, right? If it is, that's another issue. The tapclose() function is not called at all in this case. (I've put some debugging statement in the tap driver) I don't understand because I do see a successful close() from vmware (using ktrace). Writing a simple app that opens '/dev/vmnet1' and closes it again works fine. What would be the difference for this simple case and the vmware case? (I also made a linux binary of the same simple program and that one works too, just to be sure) Making a simple (and very possible wrong) conclusion is that the open call gets lost between userland and the driver. (vfs layer?) Any hints on where too look further would be very helpful. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Ethernet tunnel device
Hi I am running FreeBSD current and barely got vmware working on it. Now I have another problem which I cant resolve. If I close down the vmware program and restart I get an error that vmnet(1,2,3,0 whatever) device is busy and can not be used. using /usr/local/etc/rc.d/vmware.sh stop and then start again didnt help either. running ifconfig gave me the following output (for vmnet2 which i was and intend to use again) vmnet2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.254.1 netmask 0xff00 broadcast 192.168.254.255 inet6 fe80::2bd:fff:fe0f:2%vmnet2 prefixlen 64 scopeid 0x8 ether 00:bd:0f:0f:00:02 Opened by PID 698 clearly the device is opened by the previous instance of the program and is not closed. deleting the devices and recreating them didnt help any (using devfs which comes stock in current - 5.0) strangely even after deleting these devices from /dev ifconfig still lists them !! may be its because of devfs ... but there ought to be someway. trying to destroy the device using ifconfig gives an error too which (i believe) it should because destroy is not for ethernet tunnel device if I am not wrong. but there are no options to destroy the ethernet tunnel device in ifconfig Should there be? I cant think anymore ... would appreciate input from you guys . Any input. Please dont shy about telling me that I am going the wrong ally thanks a bunch Saurabh Gupta To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
--lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2002 at 03:23:36AM -0800, whoever wrote: clearly the device is opened by the previous=20 instance of the program and is not closed.=20 deleting the devices and recreating them didnt help any (using devfs which comes stock in current - 5.0) strangely even after deleting these devices from /dev ifconfig still lists them !! may be its because of devfs ... but there ought to be someway. There is no notification of last delete in devfs so deleting a node doesn't do anyway. trying to destroy the device using ifconfig gives an error too which (i believe) it should because destroy is not for ethernet tunnel device if I am not wrong. =20 but there are no options to destroy the ethernet tunnel device in ifconfig Should there be? Yes, I think we should add support for network device cloning and consider removing support for devfs cloning since it doesn't behave very logicaly. It's not there now, though it wouldn't be very hard to add. I cant think anymore ... would appreciate input from you=20 guys . Any input. Please dont shy about telling me that I am going the wrong ally It sounds like there's some sort of a bug in the close code. You are sure the previous instance is really gone, right? If it is, that's another issue. -- Brooks --=20 Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aCYnXY6L6fI4GtQRAsrzAJsGBJKje2qLcu4yYKaizVbp2gk3NQCeIzrr 4NSEbRRRJm4BTeaLT9KpV60= =F2rR -END PGP SIGNATURE- --lrZ03NoBR/3+SXJZ-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
On Mon, Feb 11, 2002 at 03:23:36AM -0800, whoever wrote: I am running FreeBSD current and barely got vmware working on it. Now I have another problem which I cant resolve. If I close down the vmware program and restart I get an error that vmnet(1,2,3,0 whatever) device is busy and can not be used. using /usr/local/etc/rc.d/vmware.sh stop and then start again didnt help either. running ifconfig gave me the following output (for vmnet2 which i was and intend to use again) vmnet2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.254.1 netmask 0xff00 broadcast 192.168.254.255 inet6 fe80::2bd:fff:fe0f:2%vmnet2 prefixlen 64 scopeid 0x8 ether 00:bd:0f:0f:00:02 Opened by PID 698 clearly the device is opened by the previous instance of the program and is not closed. deleting the devices and recreating them didnt help any (using devfs which comes stock in current - 5.0) strangely even after deleting these devices from /dev ifconfig still lists them !! may be its because of devfs ... but there ought to be someway. trying to destroy the device using ifconfig gives an error too which (i believe) it should because destroy is not for ethernet tunnel device if I am not wrong. but there are no options to destroy the ethernet tunnel device in ifconfig Should there be? I cant think anymore ... would appreciate input from you guys . Any input. Please dont shy about telling me that I am going the wrong ally Hi, I recently asked for this on mobile- if more people experienced this behaviour. I will be looking into this now I know more people have it. Monitor [EMAIL PROTECTED] for updates on this. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
