Re: si_drv1 used already?
In message <[EMAIL PROTECTED]>, Julian Elischer writes: >Poul-Henning Kamp wrote: >> >> In message <[EMAIL PROTECTED]>, Julian Elischer writes: >> > >> >The vmware vmmon driver used to use si_drv1 but suddenly it appears to >> >have already been used (at least it is no-longer non-zero). >> >It would fail to open because it checks it before using it during open. >> >Changing the driver to use si_drv2 fixes the problem. >> > >> >Since drv1 is defined as 'for the use of the driver' >> >I am not sure that it is wrong for the driver to use it. >> >In fact many other drivers do use it without testing it. >> > >> >I see it's used in freedev() and make_dev_alias(). >> >Is it safe for the driver to use it even if it is non-zero? >> >> I think you need to give me a bit more details before I an answer >> meaningfully... >> >> Are you sure that the value is not from previous use by vmmon ? > >no I am not sure.. I will test further. >the sequence: >1/ failed to open >2/ unload module Make sure vmmon calles destroy_dev() on all dev_t's created with make_dev() or make_dev_alias() when unloaded. This process is not automatic, and I am not sure we can safely make it automatic. We may be able to make it easier though. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: si_drv1 used already?
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Julian Elischer writes: > > > >The vmware vmmon driver used to use si_drv1 but suddenly it appears to > >have already been used (at least it is no-longer non-zero). > >It would fail to open because it checks it before using it during open. > >Changing the driver to use si_drv2 fixes the problem. > > > >Since drv1 is defined as 'for the use of the driver' > >I am not sure that it is wrong for the driver to use it. > >In fact many other drivers do use it without testing it. > > > >I see it's used in freedev() and make_dev_alias(). > >Is it safe for the driver to use it even if it is non-zero? > > I think you need to give me a bit more details before I an answer > meaningfully... > > Are you sure that the value is not from previous use by vmmon ? no I am not sure.. I will test further. the sequence: 1/ failed to open 2/ unload module 3/ load newly compiled module with printfs 4/ discover si_drv1 in use 5/ unload, load new version using si_drv2 6/ succeed. it is possible that the recompile fixed another problem that had caused another abort, but had left si_drv1 non-zero. I'll need to recompile and reboot to confirm. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: si_drv1 used already?
In message <[EMAIL PROTECTED]>, Julian Elischer writes: > >The vmware vmmon driver used to use si_drv1 but suddenly it appears to >have already been used (at least it is no-longer non-zero). >It would fail to open because it checks it before using it during open. >Changing the driver to use si_drv2 fixes the problem. > >Since drv1 is defined as 'for the use of the driver' >I am not sure that it is wrong for the driver to use it. >In fact many other drivers do use it without testing it. > >I see it's used in freedev() and make_dev_alias(). >Is it safe for the driver to use it even if it is non-zero? I think you need to give me a bit more details before I an answer meaningfully... Are you sure that the value is not from previous use by vmmon ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
