two x86_64 fixes for 2.4.21-pre3

two x86_64 fixes for 2.4.21-pre3

[Mikael Pettersson]

Andi,

1. The new IDE code in -pre references a few new macros and
   inlines from <asm/system.h> that x86_64 doesn't provide.
2. bootsect.S has the same bug that i386' bootsect.S had
   until I fixed it in 2.4.14 or so: it stops the floppy
   controller in a way that cause newer FDCs to lock up.
   The same patch as in i386' bootsect.S fixes the problem.

The x86_64 kernel boots RH8.0 fairly well, but the IA32 emulation
has some rough spots. In particular, "sleep" SEGVs with a #GP
every time, and sys32_ioctl() complains:

sleep[15] general protection rip:4004441c rsp:ffffed60 error:0
sys32_ioctl(hwclock:23): Unknown cmd fd(3) cmd(00004b50) arg(ffffeb50)
date[28] general protection rip:4002141c rsp:ffffebc0 error:0
date[30] general protection rip:400204ee rsp:ffffe4c4 error:0
sys32_ioctl(mount:62): Unknown cmd fd(4) cmd(80041272) arg(ffff6948)
sys32_ioctl(mount:62): Unknown cmd fd(4) cmd(80041272) arg(ffff6948)
sys32_ioctl(mount:69): Unknown cmd fd(4) cmd(80041272) arg(ffff6968)
sys32_ioctl(mount:69): Unknown cmd fd(4) cmd(80041272) arg(ffff6968)
rpmq[120] general protection rip:401c641c rsp:ffffed40 error:0
sleep[140] general protection rip:4003ebe5 rsp:ffffed60 error:0
sys32_ioctl(iwconfig:183): Unknown cmd fd(3) cmd(00008b01) arg(ffffea90)
sleep[196] general protection rip:4003ebe5 rsp:ffffed20 error:0

(The system is vanilla RH8.0 with Athlon binaries, running under
the Virtutech Simics 1.4.7 simulator. The x86_64 kernel was
cross-compiled with binutils-2.13.2.1 and gcc-3.2.1.)

/Mikael

--- linux-2.4.21-pre3/arch/x86_64/boot/bootsect.S.~1~	2002-11-30 17:12:24.000000000 +0100
+++ linux-2.4.21-pre3/arch/x86_64/boot/bootsect.S	2003-01-24 19:15:28.000000000 +0100
@@ -395,9 +395,15 @@
 # NOTE: Doesn't save %ax or %dx; do it yourself if you need to.
 
 kill_motor:
+#if 1
+	xorw	%ax, %ax		# reset FDC
+	xorb	%dl, %dl
+	int	$0x13
+#else
 	movw	$0x3f2, %dx
 	xorb	%al, %al
 	outb	%al, %dx
+#endif
 	ret
 
 sectors:	.word 0
--- linux-2.4.21-pre3/include/asm-x86_64/system.h.~1~	2003-01-24 14:03:58.000000000 +0100
+++ linux-2.4.21-pre3/include/asm-x86_64/system.h	2003-01-24 19:03:39.000000000 +0100
@@ -246,9 +246,14 @@
 /* used in the idle loop; sti takes one instruction cycle to complete */
 #define safe_halt()		__asm__ __volatile__("sti; hlt": : :"memory")
 
+#define __save_and_cli(x)	do { __save_flags(x); __cli(); } while(0);
+#define __save_and_sti(x)	do { __save_flags(x); __sti(); } while(0);
+
 /* For spinlocks etc */
-#define local_irq_save(x) 	do { warn_if_not_ulong(x); __asm__ __volatile__("# local_irq_save \n\t pushfq ; popq %0 ; cli":"=g" (x): /* no input */ :"memory"); } while (0)
-#define local_irq_restore(x)	__asm__ __volatile__("# local_irq_restore \n\t pushq %0 ; popfq": /* no output */ :"g" (x):"memory")
+#define local_irq_save(x)	__save_and_cli(x)
+#define local_irq_set(x)	__save_and_sti(x)
+
+#define local_irq_restore(x)	__restore_flags(x)
 #define local_irq_disable()	__cli()
 #define local_irq_enable()	__sti()
 
@@ -262,6 +267,8 @@
 #define sti() __global_sti()
 #define save_flags(x) ((x)=__global_save_flags())
 #define restore_flags(x) __global_restore_flags(x)
+#define save_and_cli(x) do { save_flags(x); cli(); } while(0);
+#define save_and_sti(x) do { save_flags(x); sti(); } while(0);
 
 #else
 
@@ -269,6 +276,8 @@
 #define sti() __sti()
 #define save_flags(x) __save_flags(x)
 #define restore_flags(x) __restore_flags(x)
+#define save_and_cli(x) __save_and_cli(x)
+#define save_and_sti(x) __save_and_sti(x)
 
 #endif
 

Re: two x86_64 fixes for 2.4.21-pre3

[Andi Kleen]

On Fri, Jan 24, 2003 at 08:16:59PM +0100, Mikael Pettersson wrote:
> 1. The new IDE code in -pre references a few new macros and
>    inlines from <asm/system.h> that x86_64 doesn't provide.

Already fixed in my tree, but thanks for the reminder to push 
it to Marcelo. I have some more bug fixes that I will push to
him soon too.

> 2. bootsect.S has the same bug that i386' bootsect.S had
>    until I fixed it in 2.4.14 or so: it stops the floppy
>    controller in a way that cause newer FDCs to lock up.
>    The same patch as in i386' bootsect.S fixes the problem.

Ok, will check that.

> 
> The x86_64 kernel boots RH8.0 fairly well, but the IA32 emulation
> has some rough spots. In particular, "sleep" SEGVs with a #GP
> every time, and sys32_ioctl() complains:

The sys32_ioctl warnings are usually harmless.
I think some i386 hwclock versions even call bogus ioctls just in case
it is running on m68k or something like that.
I believe I fixed up all rtc clock ioctls that are actually used.
[someone familiar with rtc double checking it would be welcome of course]

Of course patches are always welcome.

> 
> sleep[15] general protection rip:4004441c rsp:ffffed60 error:0
> sys32_ioctl(hwclock:23): Unknown cmd fd(3) cmd(00004b50) arg(ffffeb50)
> date[28] general protection rip:4002141c rsp:ffffebc0 error:0
> date[30] general protection rip:400204ee rsp:ffffe4c4 error:0
> sys32_ioctl(mount:62): Unknown cmd fd(4) cmd(80041272) arg(ffff6948)
> sys32_ioctl(mount:62): Unknown cmd fd(4) cmd(80041272) arg(ffff6948)
> sys32_ioctl(mount:69): Unknown cmd fd(4) cmd(80041272) arg(ffff6968)
> sys32_ioctl(mount:69): Unknown cmd fd(4) cmd(80041272) arg(ffff6968)
> rpmq[120] general protection rip:401c641c rsp:ffffed40 error:0
> sleep[140] general protection rip:4003ebe5 rsp:ffffed60 error:0
> sys32_ioctl(iwconfig:183): Unknown cmd fd(3) cmd(00008b01) arg(ffffea90)
> sleep[196] general protection rip:4003ebe5 rsp:ffffed20 error:0
> 
> (The system is vanilla RH8.0 with Athlon binaries, running under
> the Virtutech Simics 1.4.7 simulator. The x86_64 kernel was
> cross-compiled with binutils-2.13.2.1 and gcc-3.2.1.)

Works for me on Simics with a SuSE 32bit userland.

You have to figure out what breaks on RedHat yourself.

We had some problems with the TLS register used on very new glibcs
(%gs), but they should be fixed now in the codedrop in 2.4.21pre3.

-Andi

Re: two x86_64 fixes for 2.4.21-pre3

[Mikael Pettersson]

Andi Kleen writes:
 > On Fri, Jan 24, 2003 at 08:16:59PM +0100, Mikael Pettersson wrote:
...
 > > sleep[196] general protection rip:4003ebe5 rsp:ffffed20 error:0
 > > 
 > > (The system is vanilla RH8.0 with Athlon binaries, running under
...
 > Works for me on Simics with a SuSE 32bit userland.
 > 
 > You have to figure out what breaks on RedHat yourself.
 > 
 > We had some problems with the TLS register used on very new glibcs
 > (%gs), but they should be fixed now in the codedrop in 2.4.21pre3.

It looks as if %gs handling isn't quite right.

pthread_setcanceltype() SIGSEGVs in THREAD_SETMEM(self, p_canceltype, type).
The instruction that fails is "mov %dl,%gs:0x81", and %gs is zero.

RedHat linked /bin/sleep against libpthread.so, which (at least in the
glibc-2.2.93 used in RedHat 8.0) causes the nanosleep() system call
to be wrapped between a pair of pthread_setcanceltype() calls.
That's why /bin/sleep failed. Compile it yourself w/o -lpthread and it works.

Also: running gdb on a live process didn't work. I got "int3" errors in
the kernel's log, and gdb seemed to hang or loop somewhere. Postmortem
debugs of core files worked ok though.

/Mikael

Re: two x86_64 fixes for 2.4.21-pre3

[Andi Kleen]

> It looks as if %gs handling isn't quite right.

You are running vanilla 2.4.21pre3, right? 

I just noticed that my big update which has this all fixed went 
only in after pre3. Get one of the bitkeeper snapshots from Marcelo
or alternatively if you want the latest'n'greatest check out an 
CVS tree from cvs.x86-64.org (www.x86-64.org has instructions)

-Andi

Re: two x86_64 fixes for 2.4.21-pre3

[Mikael Pettersson]

Andi Kleen writes:
 > > It looks as if %gs handling isn't quite right.
 > 
 > You are running vanilla 2.4.21pre3, right? 
 > 
 > I just noticed that my big update which has this all fixed went 
 > only in after pre3.

I got 2.4.21-pre4 which has your x86_64 updates. It works MUCH better.
Still some problems remain:

1. One unknown ioctl is logged from RH8.0 init:

ioctl32(iwconfig:185): Unknown cmd fd(3) cmd(00008b01){00} arg(ffffda90) on socket:[389]

2. gdb still seems broken. gdb ./sleep [where ./sleep is simply main() calling
   nanosleep(), but linked with -lpthread] hangs or loops and takes forever
   to respond to ^C.

3. bootsect.S still needs a patch to prevent 'bzdisk' kernels from
   disabling the FDC

/Mikael

--- linux-2.4.21-pre4/arch/x86_64/boot/bootsect.S.~1~	2002-11-30 17:12:24.000000000 +0100
+++ linux-2.4.21-pre4/arch/x86_64/boot/bootsect.S	2003-01-29 16:08:38.000000000 +0100
@@ -395,9 +395,15 @@
 # NOTE: Doesn't save %ax or %dx; do it yourself if you need to.
 
 kill_motor:
+#if 1
+	xorw	%ax, %ax		# reset FDC
+	xorb	%dl, %dl
+	int	$0x13
+#else
 	movw	$0x3f2, %dx
 	xorb	%al, %al
 	outb	%al, %dx
+#endif
 	ret
 
 sectors:	.word 0

Re: two x86_64 fixes for 2.4.21-pre3

[Andi Kleen]

> 1. One unknown ioctl is logged from RH8.0 init:
> 
> ioctl32(iwconfig:185): Unknown cmd fd(3) cmd(00008b01){00} arg(ffffda90) on socket:[389]

Probably harmless, but if you figure it out please send me a patch.

Basically the steps are:

- find out which ioctl it is.

- check its arguments. if the arguments are 64bit clean (see
http://www.firstfloor.org/~andi/writing-ioctl32 for a definition) you just
add it as COMPATIBLE_IOCTL to arch/x86_64/ia32/ia32_ioctl.c

If not you have to write a conversion handler, also following the tutorial
in writing-ioctl32.

> 
> 2. gdb still seems broken. gdb ./sleep [where ./sleep is simply main() calling
>    nanosleep(), but linked with -lpthread] hangs or loops and takes forever
>    to respond to ^C.

It works with the SuSE 32bit gdb/userland.

I think RedHat has a different libpthread. I don't have a RedHat userland,
so someone else will have to debug it.

> 
> 3. bootsect.S still needs a patch to prevent 'bzdisk' kernels from
>    disabling the FDC

I put your previous patch already into CVS, but that was after the 
last Marcelo sync.

-Andi

Re: two x86_64 fixes for 2.4.21-pre3

[Mikael Pettersson]

Andi Kleen writes:
 > > 1. One unknown ioctl is logged from RH8.0 init:
 > > 
 > > ioctl32(iwconfig:185): Unknown cmd fd(3) cmd(00008b01){00} arg(ffffda90) on socket:[389]
 > 
 > Probably harmless, but if you figure it out please send me a patch.

The ioctl is SIOCGIWNAME, which is used by iwconfig from the wireless-tools
package to check if a given net dev is a wireless thing or not (called from
ifup in RedHat as a type test on the net dev).

Unfortunately, include/linux/wireless.h has a big pile of ioctls and arg/res
types that would need to be checked, so I'll defer this to Jean Tourrilhes (cc:d).

/Mikael

Re: two x86_64 fixes for 2.4.21-pre3

[Jean Tourrilhes]

On Mon, Feb 03, 2003 at 08:17:39PM +0100, Mikael Pettersson wrote:
> Andi Kleen writes:
>  > > 1. One unknown ioctl is logged from RH8.0 init:
>  > > 
>  > > ioctl32(iwconfig:185): Unknown cmd fd(3) cmd(00008b01){00} arg(ffffda90) on socket:[389]
>  > 
>  > Probably harmless, but if you figure it out please send me a patch.
> 
> The ioctl is SIOCGIWNAME, which is used by iwconfig from the wireless-tools
> package to check if a given net dev is a wireless thing or not (called from
> ifup in RedHat as a type test on the net dev).
> 
> Unfortunately, include/linux/wireless.h has a big pile of ioctls and arg/res
> types that would need to be checked, so I'll defer this to Jean Tourrilhes (cc:d).
> 
> /Mikael

	Why don't you just recompile the Wireless Tools (iwconfig and
friends) for 64 bits ?
	The source of Wireless Tools should be 64 bit clean (was
working on Alpha), and I don't think it's worth adding a whole pile of
cruft in the kernel when it's used by a few system utilities that you
can simply recompile. Personally, I expect every distribution to ship
the base system compiled natively.
	With regards to this specific problem, just return an
error. The Wireless Tools should gracefully handle it and report to
the user. I would appreciate if you would use a "distinctive" error
message, such as ENOEXEC, so that I can point users in the correct
direction.

	Just food for thought... I you think the wireless ioctls are
bad, there is worse. The linux-wlan-ng driver defines it's own driver
specific ioctls, and it has 3 times the number of ioctls. Just for one
driver. And the ioctl format sometimes changes with revision.
	So, clearly you can't expect to deal with every ioctl under
the sun, that's just not practical.

	Have fun...

	Jean

Re: two x86_64 fixes for 2.4.21-pre3

[Andi Kleen]

On Mon, Feb 03, 2003 at 11:49:23AM -0800, Jean Tourrilhes wrote:
> On Mon, Feb 03, 2003 at 08:17:39PM +0100, Mikael Pettersson wrote:
> > Andi Kleen writes:
> >  > > 1. One unknown ioctl is logged from RH8.0 init:
> >  > > 
> >  > > ioctl32(iwconfig:185): Unknown cmd fd(3) cmd(00008b01){00} arg(ffffda90) on socket:[389]
> >  > 
> >  > Probably harmless, but if you figure it out please send me a patch.
> > 
> > The ioctl is SIOCGIWNAME, which is used by iwconfig from the wireless-tools
> > package to check if a given net dev is a wireless thing or not (called from
> > ifup in RedHat as a type test on the net dev).
> > 
> > Unfortunately, include/linux/wireless.h has a big pile of ioctls and arg/res
> > types that would need to be checked, so I'll defer this to Jean Tourrilhes (cc:d).
> > 
> > /Mikael
> 
> 	Why don't you just recompile the Wireless Tools (iwconfig and
> friends) for 64 bits ?

We normally try to at least support all ioctls which are used in 
standard distributions as 32bit. This way users can easily switch
between 32bit and 64bit userland. The coverage is very good
(standing on the shoulders of sparc64 emulation gigants).

Of course 64bit tools exist, just the 64bit distributions are not commonly
available yet and it's still nice to switch at will.

Also some ports rely on emulation for all user land (sparc64, ppc64, mips64);
for these it would be eventually needed anyways.

> 	The source of Wireless Tools should be 64 bit clean (was
> working on Alpha), and I don't think it's worth adding a whole pile of
> cruft in the kernel when it's used by a few system utilities that you
> can simply recompile. Personally, I expect every distribution to ship
> the base system compiled natively.
> 	With regards to this specific problem, just return an
> error. The Wireless Tools should gracefully handle it and report to

That is currently done (-EINVAL), but the emulation layer logs an 
warning.

> 	Just food for thought... I you think the wireless ioctls are
> bad, there is worse. The linux-wlan-ng driver defines it's own driver
> specific ioctls, and it has 3 times the number of ioctls. Just for one
> driver. And the ioctl format sometimes changes with revision.

That's bad. Do they at least have unique numbers?

> 	So, clearly you can't expect to deal with every ioctl under
> the sun, that's just not practical.

So far it works.

-Andi

Re: two x86_64 fixes for 2.4.21-pre3

[Jean Tourrilhes]

On Mon, Feb 03, 2003 at 09:12:55PM +0100, Andi Kleen wrote:
> > 
> > 	Why don't you just recompile the Wireless Tools (iwconfig and
> > friends) for 64 bits ?
> 
> We normally try to at least support all ioctls which are used in 
> standard distributions as 32bit. This way users can easily switch
> between 32bit and 64bit userland. The coverage is very good
> (standing on the shoulders of sparc64 emulation gigants).

	In this case, the degradation is quite graceful. The Wireless
Tools just assume that the card doesn't support Wireless Extension, so
you won't get extra stats and configuration, but you can still use the
driver.

> Of course 64bit tools exist, just the 64bit distributions are not commonly
> available yet and it's still nice to switch at will.

	I believe that *BSD consider all system tools as part of the
base OS, and is compiled alongside the kernel, so you don't have this
issue, because kernel and tools are "in sync".
	Anyway, I believe that 64 bit platforms will need to become
mainstream before the issue of wireless on 64 bit is pressing, and by
that time most distro will have made the jump.

> > 	With regards to this specific problem, just return an
> > error. The Wireless Tools should gracefully handle it and report to
> 
> That is currently done (-EINVAL), but the emulation layer logs an 
> warning.

	It's just a shame that it's not more distinctive, because the
error message wouldn't lead me to think "doh, I need a recompile".

> > 	Just food for thought... I you think the wireless ioctls are
> > bad, there is worse. The linux-wlan-ng driver defines it's own driver
> > specific ioctls, and it has 3 times the number of ioctls. Just for one
> > driver. And the ioctl format sometimes changes with revision.
> 
> That's bad. Do they at least have unique numbers?

	They use the device private ioctls and subclass them. They use
one ioctl to query the driver for support of the API.

> > 	So, clearly you can't expect to deal with every ioctl under
> > the sun, that's just not practical.
> 
> So far it works.

	Of course, because you have dealt with the most common
subset. I want to remain pragmatic and try to define how far we need
to go. 100% coverage is unrealistic, and there is always the tradeof
between amount of work and number of users.
	I just believe that in thise case the number of users is not
there yet, and we can re-evaluate our options when we have those
users, because at that point we may have new options available.

	Also note that I made a first step in your direction. Since
WE-13, most of the metadata describing the ioctls is in the kernel
itself and the copy_to/from_user is centralised, which should make
things easier once all drivers are converted...

> -Andi

	Have fun...

	Jean

32bit emulation of wireless ioctls

[Andi Kleen]

On Mon, Feb 03, 2003 at 01:43:25PM -0800, Jean Tourrilhes wrote:
> 	In this case, the degradation is quite graceful. The Wireless
> Tools just assume that the card doesn't support Wireless Extension, so
> you won't get extra stats and configuration, but you can still use the
> driver.

Ok that's good.

> 
> > Of course 64bit tools exist, just the 64bit distributions are not commonly
> > available yet and it's still nice to switch at will.
> 
> 	I believe that *BSD consider all system tools as part of the
> base OS, and is compiled alongside the kernel, so you don't have this
> issue, because kernel and tools are "in sync".

But this is not BSD...

> 	Anyway, I believe that 64 bit platforms will need to become
> mainstream before the issue of wireless on 64 bit is pressing, and by
> that time most distro will have made the jump.

Hmm, not so sure. I guess people will sooner than later plug wireless
cards into 64bit boxes, especially with x86-64 which will hopefully
be quite "mainstream".

> 
> > > 	With regards to this specific problem, just return an
> > > error. The Wireless Tools should gracefully handle it and report to
> > 
> > That is currently done (-EINVAL), but the emulation layer logs an 
> > warning.
> 
> 	It's just a shame that it's not more distinctive, because the
> error message wouldn't lead me to think "doh, I need a recompile".

Do you have a better suggestion?

> 
> > > 	Just food for thought... I you think the wireless ioctls are
> > > bad, there is worse. The linux-wlan-ng driver defines it's own driver
> > > specific ioctls, and it has 3 times the number of ioctls. Just for one
> > > driver. And the ioctl format sometimes changes with revision.
> > 
> > That's bad. Do they at least have unique numbers?
> 
> 	They use the device private ioctls and subclass them. They use
> one ioctl to query the driver for support of the API.

That's very bad, because the ioctl emulation needs unique numbers currently.

There was some hack added for PPP, but it may not extend to wireless.

> 	Also note that I made a first step in your direction. Since
> WE-13, most of the metadata describing the ioctls is in the kernel
> itself and the copy_to/from_user is centralised, which should make
> things easier once all drivers are converted...

Anyways: for me it is just slightly annoying to not have 32bit 
emulation for something, but for other ports like sparc64/ppc64/mips64 
it can be show stopper because they only have 32bit userland.

Expect trouble when DaveM wants to plug a wireless card into one of 
his sparc64 boxes ;-)

-Andi

Re: 32bit emulation of wireless ioctls

[Jean Tourrilhes]

On Mon, Feb 03, 2003 at 11:46:19PM +0100, Andi Kleen wrote:
> 
> > 	Anyway, I believe that 64 bit platforms will need to become
> > mainstream before the issue of wireless on 64 bit is pressing, and by
> > that time most distro will have made the jump.
> 
> Hmm, not so sure. I guess people will sooner than later plug wireless
> cards into 64bit boxes, especially with x86-64 which will hopefully
> be quite "mainstream".

	But I content that when it is that much mainstream, you will
have 64 bit distros.

> > > That is currently done (-EINVAL), but the emulation layer logs an 
> > > warning.
> > 
> > 	It's just a shame that it's not more distinctive, because the
> > error message wouldn't lead me to think "doh, I need a recompile".
> 
> Do you have a better suggestion?

	I checked the errno list, and there was not one obvious
candidate. Potentially we could abuse ENOEXEC, but I must admit my
knowledge of errnos is too superficial.

> Anyways: for me it is just slightly annoying to not have 32bit 
> emulation for something, but for other ports like sparc64/ppc64/mips64 
> it can be show stopper because they only have 32bit userland.

	<Puzzled of why you would *not* want a 64 bit userland>

> Expect trouble when DaveM wants to plug a wireless card into one of 
> his sparc64 boxes ;-)

	I want to see that ;-)
	I've always been telling David and Stephane here that they
should loan me an Itanium box to make sure IrDA and Wireless LAN work
properly, for the day we will release a PDA with an Itanium processor.

> -Andi

	Have fun...

	Jean

Re: 32bit emulation of wireless ioctls

[Andi Kleen]

On Mon, Feb 03, 2003 at 03:17:40PM -0800, Jean Tourrilhes wrote:
> > Anyways: for me it is just slightly annoying to not have 32bit 
> > emulation for something, but for other ports like sparc64/ppc64/mips64 
> > it can be show stopper because they only have 32bit userland.
> 
> 	<Puzzled of why you would *not* want a 64 bit userland>

Of course I want to have a 64bit userland. In fact I have one.

Just we offer the users the choice to boot 32bit distributions with
64bit kernels too, in case they only need a single application
that needs 64bit or similar. I'm also prepared to rip out or ignore
very obscure parts of the 32bit emulation (in fact I did that already),
but if it's used commonly or even called in bootup it should be supported.

Short term I will just settle on getting that message away so that
RedHat users won't bother me anymore. Can you suggest a good way to 
handle SIOCGIWNAME? Should I just make it return -EINVAL?

> > Expect trouble when DaveM wants to plug a wireless card into one of 
> > his sparc64 boxes ;-)
> 
> 	I want to see that ;-)
> 	I've always been telling David and Stephane here that they
> should loan me an Itanium box to make sure IrDA and Wireless LAN work
> properly, for the day we will release a PDA with an Itanium processor.

I understand why you don't see much point to run 32bit on Itanium
because of the performance.  But that's not a problem on all 64bit ports...

-Andi

Re: 32bit emulation of wireless ioctls

[David Woodhouse]

On Mon, 2003-02-03 at 23:17, Jean Tourrilhes wrote:
> 	<Puzzled of why you would *not* want a 64 bit userland>

Because 64-bit can be just a waste of space for no real gain, and more
to the point because some of the early SPARC64 chips are so broken that
if you let users run 64-bit code they can kill the box, so it's strictly
32-bit userland only on those.

-- 
dwmw2

Re: 32bit emulation of wireless ioctls

[David Mosberger]

>>>>> On Mon, 3 Feb 2003 15:17:40 -0800, Jean Tourrilhes <jt@bougret.hpl.hp.com> said:

  >> Expect trouble when DaveM wants to plug a wireless card into one
  >> of his sparc64 boxes ;-)

  Jean> 	I want to see that ;-) I've always been telling David
  Jean> and Stephane here that they should loan me an Itanium box to
  Jean> make sure IrDA and Wireless LAN work properly, for the day we
  Jean> will release a PDA with an Itanium processor.

Name collision alert: DaveM != davidm.  The former refers to Dave Miller.

As far Wireless LAN on Itanium: I do that at home and works fine
(haven't played with IrDA though).  Clearly giving you access to an
Itanium machine is _not_ a problem...

	--david

Re: 32bit emulation of wireless ioctls

[Jean Tourrilhes]

On Tue, Feb 04, 2003 at 12:51:50AM +0100, Andi Kleen wrote:
> 
> Short term I will just settle on getting that message away so that
> RedHat users won't bother me anymore. Can you suggest a good way to 
> handle SIOCGIWNAME? Should I just make it return -EINVAL?

	Just return any error, all errors will be processed the same
(and displayed to the user). Either make it convenient for you, or
make it meaningful to the user.

> -Andi

	Jean

Re: 32bit emulation of wireless ioctls

[Anton Blanchard]

> 	<Puzzled of why you would *not* want a 64 bit userland>

Because I regularly move my userland between my 32bit G4 laptop and 64bit
p690 :) On most architectures, 64bit just adds unnecessary bloat.

Anton

Re: two x86_64 fixes for 2.4.21-pre3

[Ton Hospel]

In article <15921.37163.139583.74988@harpo.it.uu.se>,
	Mikael Pettersson <mikpe@csd.uu.se> writes:
>  #define safe_halt()		__asm__ __volatile__("sti; hlt": : :"memory")
>  
> +#define __save_and_cli(x)	do { __save_flags(x); __cli(); } while(0);
> +#define __save_and_sti(x)	do { __save_flags(x); __sti(); } while(0);
> +

The extra ; after the while(0) look wrong.

>  #define restore_flags(x) __global_restore_flags(x)
> +#define save_and_cli(x) do { save_flags(x); cli(); } while(0);
> +#define save_and_sti(x) do { save_flags(x); sti(); } while(0);

Same here

Re: two x86_64 fixes for 2.4.21-pre3

[Mikael Pettersson]

Ton Hospel writes:
 > In article <15921.37163.139583.74988@harpo.it.uu.se>,
 > 	Mikael Pettersson <mikpe@csd.uu.se> writes:
 > >  #define safe_halt()		__asm__ __volatile__("sti; hlt": : :"memory")
 > >  
 > > +#define __save_and_cli(x)	do { __save_flags(x); __cli(); } while(0);
 > > +#define __save_and_sti(x)	do { __save_flags(x); __sti(); } while(0);
 > > +
 > 
 > The extra ; after the while(0) look wrong.
 > 
 > >  #define restore_flags(x) __global_restore_flags(x)
 > > +#define save_and_cli(x) do { save_flags(x); cli(); } while(0);
 > > +#define save_and_sti(x) do { save_flags(x); sti(); } while(0);
 > 
 > Same here

Good catch. Those #defines were copied from include/asm-i386/system.h which
contains the same extraneous semicolons. The patch below cleans this up.

/Mikael

--- linux-2.4.21-pre4/include/asm-i386/system.h.~1~	2003-01-31 15:20:56.000000000 +0100
+++ linux-2.4.21-pre4/include/asm-i386/system.h	2003-02-04 14:04:48.000000000 +0100
@@ -322,8 +322,8 @@
 /* used in the idle loop; sti takes one instruction cycle to complete */
 #define safe_halt()		__asm__ __volatile__("sti; hlt": : :"memory")
 
-#define __save_and_cli(x)	do { __save_flags(x); __cli(); } while(0);
-#define __save_and_sti(x)	do { __save_flags(x); __sti(); } while(0);
+#define __save_and_cli(x)	do { __save_flags(x); __cli(); } while(0)
+#define __save_and_sti(x)	do { __save_flags(x); __sti(); } while(0)
 
 /* For spinlocks etc */
 #if 0
@@ -348,8 +348,8 @@
 #define sti() __global_sti()
 #define save_flags(x) ((x)=__global_save_flags())
 #define restore_flags(x) __global_restore_flags(x)
-#define save_and_cli(x) do { save_flags(x); cli(); } while(0);
-#define save_and_sti(x) do { save_flags(x); sti(); } while(0);
+#define save_and_cli(x) do { save_flags(x); cli(); } while(0)
+#define save_and_sti(x) do { save_flags(x); sti(); } while(0)
 
 #else
 
--- linux-2.4.21-pre4/include/asm-x86_64/system.h.~1~	2003-01-31 15:22:57.000000000 +0100
+++ linux-2.4.21-pre4/include/asm-x86_64/system.h	2003-02-04 14:05:07.000000000 +0100
@@ -246,8 +246,8 @@
 /* used in the idle loop; sti takes one instruction cycle to complete */
 #define safe_halt()		__asm__ __volatile__("sti; hlt": : :"memory")
 
-#define __save_and_cli(x)      do { __save_flags(x); __cli(); } while(0);
-#define __save_and_sti(x)      do { __save_flags(x); __sti(); } while(0);
+#define __save_and_cli(x)      do { __save_flags(x); __cli(); } while(0)
+#define __save_and_sti(x)      do { __save_flags(x); __sti(); } while(0)
 
 /* For spinlocks etc */
 #define local_irq_save(x) 	do { warn_if_not_ulong(x); __asm__ __volatile__("# local_irq_save \n\t pushfq ; popq %0 ; cli":"=g" (x): /* no input */ :"memory"); } while (0)
@@ -266,8 +266,8 @@
 #define sti() __global_sti()
 #define save_flags(x) ((x)=__global_save_flags())
 #define restore_flags(x) __global_restore_flags(x)
-#define save_and_cli(x) do { save_flags(x); cli(); } while(0);
-#define save_and_sti(x) do { save_flags(x); sti(); } while(0);
+#define save_and_cli(x) do { save_flags(x); cli(); } while(0)
+#define save_and_sti(x) do { save_flags(x); sti(); } while(0)
 
 #else
 

Re: two x86_64 fixes for 2.4.21-pre3

[Pavel Machek]

Hi!

> > 	The source of Wireless Tools should be 64 bit clean (was
> > working on Alpha), and I don't think it's worth adding a whole pile of
> > cruft in the kernel when it's used by a few system utilities that you
> > can simply recompile. Personally, I expect every distribution to ship
> > the base system compiled natively.
> > 	With regards to this specific problem, just return an
> > error. The Wireless Tools should gracefully handle it and report to
> 
> That is currently done (-EINVAL), but the emulation layer logs an 
> warning.

Perhaps we need new error code -EEMULATION with message "not supported
within this emulation"?
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: two x86_64 fixes for 2.4.21-pre3

[Alan Cox]

On Fri, 2003-02-07 at 10:58, Pavel Machek wrote:
> > That is currently done (-EINVAL), but the emulation layer logs an 
> > warning.
> 
> Perhaps we need new error code -EEMULATION with message "not supported
> within this emulation"?

-ENOSYS is the normal return for an unknown syscall. -ENOTTY for an
invalid ioctl (-EINVAL I think is wrong ?)

Alan

Re: two x86_64 fixes for 2.4.21-pre3

[Erik Mouw]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Fri, Feb 07, 2003 at 02:32:20PM +0000, Alan Cox wrote:
> -ENOSYS is the normal return for an unknown syscall. -ENOTTY for an
> invalid ioctl (-EINVAL I think is wrong ?)

About a year ago -ENOTTY was explained like this:

  IOW, "not a tty" used to mean "WTF are you using ioctls here?"

          - Al Viro explaining ENOTTY on linux-kernel

(Hey, the kernelnewbies.org fortunes file is useful, right? ;)


Erik

-- 
J.A.K. (Erik) Mouw
Email: J.A.K.Mouw@its.tudelft.nl  mouw@nl.linux.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]