LinuxLists.cc - two x86_64 fixes for 2.4.21-pre3

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

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

2003-01-28 20:42:29

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

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

2003-01-28 21:18:36

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

> 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 (http://www.x86-64.org has instructions)

-Andi

2003-01-29 15:30:16

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

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

2003-01-29 16:19:04

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

> 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

2003-02-03 19:08:24

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

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

2003-02-03 20:04:33

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

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

2003-02-03 20:09:08

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

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

2003-02-03 22:00:59

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

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

2003-02-03 22:37:46

[permalink] [raw]

Subject: 32bit emulation of wireless ioctls

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

2003-02-03 23:33:29

[permalink] [raw]

Subject: Re: 32bit emulation of wireless ioctls

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

2003-02-03 23:42:22

[permalink] [raw]

Subject: Re: 32bit emulation of wireless ioctls

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

2003-02-03 23:49:16

by David Woodhouse

[permalink] [raw]

Subject: Re: 32bit emulation of wireless ioctls

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

2003-02-04 00:03:40

by Anton Blanchard

[permalink] [raw]

Subject: Re: 32bit emulation of wireless ioctls

> <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

2003-02-04 00:10:15

by David Mosberger

[permalink] [raw]

Subject: Re: 32bit emulation of wireless ioctls

>>>>> On Mon, 3 Feb 2003 15:17:40 -0800, Jean Tourrilhes <[email protected]> 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

2003-02-04 00:15:16

[permalink] [raw]

Subject: Re: 32bit emulation of wireless ioctls

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

2003-02-04 03:03:54

by linux-kernel

[permalink] [raw]

Subject: Re: two x86_64 fixes for 2.4.21-pre3

In article <[email protected]>,
Mikael Pettersson <[email protected]> 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

2003-02-04 13:02:14