I used to run 64bit userspace on 64bit kernel but I recently tried to run a 64bit kernel with as minimal as possible as 64bit userspace (that is rpm+glibc+... in order to mananage 64bit kernel packages). This revealed several missing compat_ioctl. Running 32bit gnome-terminal on a 64 bit kernel results in the following in dmesg: - with gnome-terminal: ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(48111345) on /dev/pts/0 ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(4811134a) on /dev/pts/0 ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(48111351) on /dev/pts/0 - with X: ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on /var/log/Xorg.0.log ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on /var/log/Xorg.0.log - when trying to suspend: ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} arg(ffc190ec) on /dev/snapshot ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000806) on /dev/snapshot Of course we'd better run 64bit userspace on 64bit kernel but 32bit applications are supposed to still work. Some may say some of them are too hardware specific but still it would be best to fix them... Tested with 2.6.31.5 and 2.6.32-rc5.
(For the record, suspending doesn't work with 32 bit userspace)
B1;2005;0c(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 3 Nov 2009, bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=14537 > > Summary: missing compat_ioctl on x86_64 > Product: Platform Specific/Hardware > Version: 2.5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: x86-64 > AssignedTo: platform_x86_64@kernel-bugs.osdl.org > ReportedBy: tvignaud@mandriva.com > Regression: No > > > I used to run 64bit userspace on 64bit kernel but I recently tried to run a > 64bit kernel with as minimal as possible as 64bit userspace (that is > rpm+glibc+... in order to mananage 64bit kernel packages). > > This revealed several missing compat_ioctl. > Running 32bit gnome-terminal on a 64 bit kernel results in the following in > dmesg: > > - with gnome-terminal: > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} > arg(48111345) on /dev/pts/0 > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} > arg(4811134a) on /dev/pts/0 > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} > arg(48111351) on /dev/pts/0 That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL which has no ioctl nr 0xb. Also I have no idea why a sound sequencer ioctl should work on /dev/pts/0 :) > - with X: > ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on > /var/log/Xorg.0.log > ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on > /var/log/Xorg.0.log 'd' is used by pcmcia and DRM. DRM sounds more likely for X, but I have a hard time to understand why a DRM ioctl should work on /var/log/Xorg.0.log :) For both gnome-terminal and X strace should tell you more. > - when trying to suspend: > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} > arg(ffc190ec) on /dev/snapshot > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} > arg(00000806) > on /dev/snapshot snapshot_ioctl seems to lack compat support completely. Raphael ?? > Of course we'd better run 64bit userspace on 64bit kernel but 32bit > applications are supposed to still work. > Some may say some of them are too hardware specific but still it would be > best > to fix them... > > Tested with 2.6.31.5 and 2.6.32-rc5. Thanks, tglx
Reply-To: andi@firstfloor.org Thomas Gleixner <tglx@linutronix.de> writes: >> - with gnome-terminal: >> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} >> arg(48111345) on /dev/pts/0 >> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} >> arg(4811134a) on /dev/pts/0 >> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} >> arg(48111351) on /dev/pts/0 > > That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL > which has no ioctl nr 0xb. Also I have no idea why a sound sequencer > ioctl should work on /dev/pts/0 :) ioctl numbers are not always unique (I haven't checked if this is the case here). But it might be that it's some other ioctl actually. One easy way to check is to install debuginfo and set break points on ioctl in gdb and then look at the sources in the backtrace. -Andi
Reply-To: schwab@redhat.com Andi Kleen <andi@firstfloor.org> writes: > Thomas Gleixner <tglx@linutronix.de> writes: > >>> - with gnome-terminal: >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} >>> arg(48111345) on /dev/pts/0 >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} >>> arg(4811134a) on /dev/pts/0 >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} >>> arg(48111351) on /dev/pts/0 >> >> That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL >> which has no ioctl nr 0xb. Also I have no idea why a sound sequencer >> ioctl should work on /dev/pts/0 :) > > ioctl numbers are not always unique (I haven't checked if this is the > case here). But it might be that it's some other ioctl actually. 'S' is also used for streams ioctls, 0x530b is I_FIND. Andreas.
On Wed, 04 Nov 2009 16:41:34 +0100 Andreas Schwab wrote: > Andi Kleen <andi@firstfloor.org> writes: > > > Thomas Gleixner <tglx@linutronix.de> writes: > > > >>> - with gnome-terminal: > >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) > cmd(0000530b){t:'S';sz:0} > >>> arg(48111345) on /dev/pts/0 > >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) > cmd(0000530b){t:'S';sz:0} > >>> arg(4811134a) on /dev/pts/0 > >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) > cmd(0000530b){t:'S';sz:0} > >>> arg(48111351) on /dev/pts/0 > >> > >> That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL > >> which has no ioctl nr 0xb. Also I have no idea why a sound sequencer > >> ioctl should work on /dev/pts/0 :) > > > > ioctl numbers are not always unique (I haven't checked if this is the > > case here). But it might be that it's some other ioctl actually. > > 'S' is also used for streams ioctls, 0x530b is I_FIND. Is that last 'S' in the kernel source tree? If so, I'll have to find/add it to Documentation/ioctl/ioctl-number.txt, which I sent an update patch for about 2 weeks ago. For 'S', it now lists: 'S' all linux/cdrom.h conflict! 'S' 80-81 scsi/scsi_ioctl.h conflict! 'S' 82-FF scsi/scsi.h conflict! +'S' 00-7F sound/asequencer.h conflict! --- ~Randy
On Wednesday 04 November 2009, Thomas Gleixner wrote: > B1;2005;0c(switched to email. Please respond via emailed reply-to-all, not > via the > bugzilla web interface). > > On Tue, 3 Nov 2009, bugzilla-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=14537 > > > > Summary: missing compat_ioctl on x86_64 > > Product: Platform Specific/Hardware > > Version: 2.5 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: x86-64 > > AssignedTo: platform_x86_64@kernel-bugs.osdl.org > > ReportedBy: tvignaud@mandriva.com > > Regression: No > > > > > > I used to run 64bit userspace on 64bit kernel but I recently tried to run a > > 64bit kernel with as minimal as possible as 64bit userspace (that is > > rpm+glibc+... in order to mananage 64bit kernel packages). > > > > This revealed several missing compat_ioctl. > > Running 32bit gnome-terminal on a 64 bit kernel results in the following in > > dmesg: > > > > - with gnome-terminal: > > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} > > arg(48111345) on /dev/pts/0 > > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} > > arg(4811134a) on /dev/pts/0 > > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} > > arg(48111351) on /dev/pts/0 > > That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL > which has no ioctl nr 0xb. Also I have no idea why a sound sequencer > ioctl should work on /dev/pts/0 :) > > > - with X: > > ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) > on > > /var/log/Xorg.0.log > > ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) > on > > /var/log/Xorg.0.log > > 'd' is used by pcmcia and DRM. DRM sounds more likely for X, but I > have a hard time to understand why a DRM ioctl should work on > /var/log/Xorg.0.log :) > > For both gnome-terminal and X strace should tell you more. > > > - when trying to suspend: > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} > > arg(ffc190ec) on /dev/snapshot > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} > arg(00000806) > > on /dev/snapshot > > snapshot_ioctl seems to lack compat support completely. Raphael ?? It does, but that wouldn't work anyway. s2disk is one of the things that have to be native. Rafael
Reply-To: pavel@ucw.cz Hi! > > > - when trying to suspend: > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} > > > arg(ffc190ec) on /dev/snapshot > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} > arg(00000806) > > > on /dev/snapshot > > > > snapshot_ioctl seems to lack compat support completely. Raphael ?? > > It does, but that wouldn't work anyway. s2disk is one of the things that > have > to be native. Actually... it would be nice to fix that one day, if someone submitted nice patch... :-). Pavel
On Saturday 07 November 2009, Pavel Machek wrote: > Hi! > > > > > - when trying to suspend: > > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} > > > > arg(ffc190ec) on /dev/snapshot > > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} > arg(00000806) > > > > on /dev/snapshot > > > > > > snapshot_ioctl seems to lack compat support completely. Raphael ?? > > > > It does, but that wouldn't work anyway. s2disk is one of the things that > have > > to be native. > > Actually... it would be nice to fix that one day, if someone submitted > nice patch... :-). It must be fixed in s2disk first, but that would probably require us to drop support for older kernels. Which is not unthinkable, but might hurt some users. Thanks, Rafael
Reply-To: pavel@ucw.cz Hi! > > > > > - when trying to suspend: > > > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} > > > > > arg(ffc190ec) on /dev/snapshot > > > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} > arg(00000806) > > > > > on /dev/snapshot > > > > > > > > snapshot_ioctl seems to lack compat support completely. Raphael ?? > > > > > > It does, but that wouldn't work anyway. s2disk is one of the things that > have > > > to be native. > > > > Actually... it would be nice to fix that one day, if someone submitted > > nice patch... :-). > > It must be fixed in s2disk first, but that would probably require us to drop > support for older kernels. Which is not unthinkable, but might hurt some > users. It should be possible to check compat_task() and provide interface userland expects. But yes, improving interface to be same for 32 and 64bit would probably be the way, too. (Or did you have something else in mind?) Pavel
On Saturday 07 November 2009, Rafael J. Wysocki wrote: > > Actually... it would be nice to fix that one day, if someone submitted > > nice patch... :-). > > It must be fixed in s2disk first, but that would probably require us to drop > support for older kernels. Which is not unthinkable, but might hurt some > users. You don't need to drop support for older kernels if s2disk simply tries the new interface first and falls back to the current one if that fails. Arnd <><
On Saturday 07 November 2009, Arnd Bergmann wrote: > On Saturday 07 November 2009, Rafael J. Wysocki wrote: > > > Actually... it would be nice to fix that one day, if someone submitted > > > nice patch... :-). > > > > It must be fixed in s2disk first, but that would probably require us to > drop > > support for older kernels. Which is not unthinkable, but might hurt some > > users. > > You don't need to drop support for older kernels if s2disk simply tries the > new interface first and falls back to the current one if that fails. Compat ioctls support is not possible with the old interface. Thanks, Rafael
On Saturday 07 November 2009, Rafael J. Wysocki wrote: > On Saturday 07 November 2009, Arnd Bergmann wrote: > > On Saturday 07 November 2009, Rafael J. Wysocki wrote: > > > > Actually... it would be nice to fix that one day, if someone submitted > > > > nice patch... :-). > > > > > > It must be fixed in s2disk first, but that would probably require us to > drop > > > support for older kernels. Which is not unthinkable, but might hurt some > > > users. > > > > You don't need to drop support for older kernels if s2disk simply tries the > > new interface first and falls back to the current one if that fails. > > Compat ioctls support is not possible with the old interface. Right, but that doesn't imply dropping support for something that is working right now. The interesting case is people upgrading the user space or the kernel without breaking stuff. Arnd <><
On Sat, 7 Nov 2009, Rafael J. Wysocki wrote: > On Saturday 07 November 2009, Arnd Bergmann wrote: > > On Saturday 07 November 2009, Rafael J. Wysocki wrote: > > > > Actually... it would be nice to fix that one day, if someone submitted > > > > nice patch... :-). > > > > > > It must be fixed in s2disk first, but that would probably require us to > drop > > > support for older kernels. Which is not unthinkable, but might hurt some > > > users. > > > > You don't need to drop support for older kernels if s2disk simply tries the > > new interface first and falls back to the current one if that fails. > > Compat ioctls support is not possible with the old interface. That does not matter. If you create a new interface which is 32/64bit safe and keep the old interface around for compability reasons then a new user space will try the new interface first and if that is not available due to older kernel version it uses the old interface. If old user space talks to a newer kernel it will use the old interface with its current limitations. Over time you can phase out the old interface in the kernel. Thanks, tglx