On 24 Mar 04 at 11:43, Hans-Peter Jansen wrote:
> On Tuesday 23 March 2004 23:05, Andrei Mikhailovsky wrote:
> > I have successfully installed (well actually upgraded) to 4.5.1
> > from 4.0.5. No patches where required and everything seems to work
> > like a charm.
>
> Am I right, that you're running on i586, while the problem expose
> on x86_64 arch?
Not only. It builds & runs without patches if you use "right" x86_64
kernels. Patch you posted is needed on SuSE (AFAIK) 2.4.x kernels and
on 2.6.x kernels, while RedHat 2.4.x kernels works without patch. On
other side ffs(0) returns 33 on RedHat's 2.4.x kernels (at least on
one...) which can cause machine lockup in endless loop waiting until
ffs(0) will become 0...
On 2.6.x kernels additionally (problem you are hitting now) SIO*BRIDGE
ioctls were moved from "compatible" to "not so compatible" group.
If you'll just mark them as "compatible", it will work sufficiently
well to get networking in VMware.
Unfortunately I'm not aware about any way how to issue x86_64 ioctls
from 32bit ia32 program, and spawning external program just to perform
one ioctl on some file descriptor looks like overkill.
I'll start supporting x86_64 in vmware-any-any- patches as soon as
someone donates x86_64 system to me, or after ~ September 2004, whatever
comes first. Until then you have to get it to work yourself - change
you made is already done in vmware-any-any-update55, unfortunately
other parts of that update do not build on x86_64 yet...
Petr Vandrovec
On Wednesday 24 March 2004 12:59, Petr Vandrovec wrote:
> On 24 Mar 04 at 11:43, Hans-Peter Jansen wrote:
> >
> > Am I right, that you're running on i586, while the problem expose
> > on x86_64 arch?
>
> Not only. It builds & runs without patches if you use "right"
> x86_64 kernels. Patch you posted is needed on SuSE (AFAIK) 2.4.x
> kernels and on 2.6.x kernels, while RedHat 2.4.x kernels works
> without patch. On other side ffs(0) returns 33 on RedHat's 2.4.x
> kernels (at least on one...) which can cause machine lockup in
> endless loop waiting until ffs(0) will become 0...
Hmm, it's a SuSE issue then, nice to know (and easily fixable ;-).
> On 2.6.x kernels additionally (problem you are hitting now)
> SIO*BRIDGE ioctls were moved from "compatible" to "not so
> compatible" group. If you'll just mark them as "compatible", it
> will work sufficiently well to get networking in VMware.
I found it. Fixed it with this patch:
--- include/linux/compat_ioctl.h~ 2004-03-12 18:37:26.000000000 +0100
+++ include/linux/compat_ioctl.h 2004-03-24 12:34:30.000000000 +0100
@@ -247,10 +247,10 @@
COMPATIBLE_IOCTL(SIOCSIFENCAP)
COMPATIBLE_IOCTL(SIOCGIFENCAP)
COMPATIBLE_IOCTL(SIOCSIFNAME)
-/* FIXME: not compatible
+/* FIXME: not compatible */
COMPATIBLE_IOCTL(SIOCSIFBR)
COMPATIBLE_IOCTL(SIOCGIFBR)
-*/
+/* reactivated for vmware */
COMPATIBLE_IOCTL(SIOCSARP)
COMPATIBLE_IOCTL(SIOCGARP)
COMPATIBLE_IOCTL(SIOCDARP)
> Unfortunately I'm not aware about any way how to issue x86_64
> ioctls from 32bit ia32 program, and spawning external program just
> to perform one ioctl on some file descriptor looks like overkill.
Since networking works as expected, I don't see any reason for this
(I probably missing some aspect..)
> I'll start supporting x86_64 in vmware-any-any- patches as soon as
> someone donates x86_64 system to me, or after ~ September 2004,
> whatever comes first. Until then you have to get it to work
Well, I cannot spend you a machine atm, sorry.
As it appears to me, VMware Inc. owes you __at least__ one ;-)
> yourself - change you made is already done in
> vmware-any-any-update55, unfortunately other parts of that update
> do not build on x86_64 yet...
Oh, well...
> Petr Vandrovec
My last issue is a cosmetical one. Is it expected, that in VMware GUI,
the menu and all edit fields are rendered in a fixed space font (looks
like "ETL Fixed"), which looks quite strange?
Thanks for your help,
Pete
Hi!
> Hmm, it's a SuSE issue then, nice to know (and easily fixable ;-).
>
> > On 2.6.x kernels additionally (problem you are hitting now)
> > SIO*BRIDGE ioctls were moved from "compatible" to "not so
> > compatible" group. If you'll just mark them as "compatible", it
> > will work sufficiently well to get networking in VMware.
>
> I found it. Fixed it with this patch:
>
> --- include/linux/compat_ioctl.h~ 2004-03-12 18:37:26.000000000 +0100
> +++ include/linux/compat_ioctl.h 2004-03-24 12:34:30.000000000 +0100
> @@ -247,10 +247,10 @@
> COMPATIBLE_IOCTL(SIOCSIFENCAP)
> COMPATIBLE_IOCTL(SIOCGIFENCAP)
> COMPATIBLE_IOCTL(SIOCSIFNAME)
> -/* FIXME: not compatible
> +/* FIXME: not compatible */
> COMPATIBLE_IOCTL(SIOCSIFBR)
> COMPATIBLE_IOCTL(SIOCGIFBR)
> -*/
> +/* reactivated for vmware */
> COMPATIBLE_IOCTL(SIOCSARP)
> COMPATIBLE_IOCTL(SIOCGARP)
> COMPATIBLE_IOCTL(SIOCDARP)
Marking ioctl compatible when it is not is pretty nasty, right? What
about writing conversion functions?
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Hi Pavel,
On Tuesday 30 March 2004 14:33, Pavel Machek wrote:
> Hi!
>
> Marking ioctl compatible when it is not is pretty nasty, right?
Yup.
> What about writing conversion functions?
FJI: It's underway through the master of x86_64: Andi Kleen.
Tests unfortunately pending..
Cheers,
Pete
On Tue, Mar 30, 2004 at 02:33:31PM +0200, Pavel Machek wrote:
> Hi!
>
> > Hmm, it's a SuSE issue then, nice to know (and easily fixable ;-).
> >
> > > On 2.6.x kernels additionally (problem you are hitting now)
> > > SIO*BRIDGE ioctls were moved from "compatible" to "not so
> > > compatible" group. If you'll just mark them as "compatible", it
> > > will work sufficiently well to get networking in VMware.
> >
> > I found it. Fixed it with this patch:
> >
> > --- include/linux/compat_ioctl.h~ 2004-03-12 18:37:26.000000000 +0100
> > +++ include/linux/compat_ioctl.h 2004-03-24 12:34:30.000000000 +0100
> > @@ -247,10 +247,10 @@
> > COMPATIBLE_IOCTL(SIOCSIFENCAP)
> > COMPATIBLE_IOCTL(SIOCGIFENCAP)
> > COMPATIBLE_IOCTL(SIOCSIFNAME)
> > -/* FIXME: not compatible
> > +/* FIXME: not compatible */
> > COMPATIBLE_IOCTL(SIOCSIFBR)
> > COMPATIBLE_IOCTL(SIOCGIFBR)
> > -*/
> > +/* reactivated for vmware */
> > COMPATIBLE_IOCTL(SIOCSARP)
> > COMPATIBLE_IOCTL(SIOCGARP)
> > COMPATIBLE_IOCTL(SIOCDARP)
>
> Marking ioctl compatible when it is not is pretty nasty, right? What
> about writing conversion functions?
Well, main problem is that VMware uses SIOCSIFBR and SIOCGIFBR with completely
different semantic than everybody else, and for VMware identical translation
is correct for SIOCSIFBR. SIOCGIFBR (for which identical translation is
not correct) does not appear to be used at all.
I'll fill bugreport with VMware. For existing systems correct solution is:
(1a) Mark SIOCSIFBR as COMPATIBLE_IOCTL.
(1b) No change is needed for SIOCGIFBR.
(2) Your bridge control tools must be 64bit app. As they'll not run when built
as 32bit app anyway, no big damage is caused here...
Best regards,
Petr Vandrovec