From: Johannes Berg <johannes@sipsolutions.net> Date: 2007-10-24 13:15:20
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
johannes
On Wednesday 24 October 2007, Johannes Berg wrote:
Show Details
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
It's probably my fault, since I changed the compat ioctl handling for
block devices. Geert already reported the same, but I haven't had
a chance to reproduce it on my system to look into what went wrong.
Probably a trivial bug I introduced in block/compat_ioctl.c
Arnd <><
From: Johannes Berg <johannes@sipsolutions.net> Date: 2007-10-25 13:37:43
On Wed, 2007-10-24 at 16:27 +0200, Arnd Bergmann wrote:
On Wednesday 24 October 2007, Johannes Berg wrote:
quoted
Show Details
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
It's probably my fault, since I changed the compat ioctl handling for
block devices. Geert already reported the same, but I haven't had
a chance to reproduce it on my system to look into what went wrong.
Probably a trivial bug I introduced in block/compat_ioctl.c
I have to admit that ioctl numbers scare me :) Any idea what I should be
looking for?
johannes
On Wed, 2007-10-24 at 16:27 +0200, Arnd Bergmann wrote:
quoted
On Wednesday 24 October 2007, Johannes Berg wrote:
quoted
Show Details
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
It's probably my fault, since I changed the compat ioctl handling for
block devices. Geert already reported the same, but I haven't had
a chance to reproduce it on my system to look into what went wrong.
Probably a trivial bug I introduced in block/compat_ioctl.c
I have to admit that ioctl numbers scare me :) Any idea what I should be
looking for?
Fortunately there's nothing to really worry about, as it's purely cosmetic :-)
If you want to look into this, the question is just why these messages are
printed now, while they weren't printed before. I don't think any other
behavior got changed.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
If you want to look into this, the question is just why these messages are
printed now, while they weren't printed before. I don't think any other
behavior got changed.
I'm not so sure about that. The reason that the messages are printed now
is that there is no fallback handler for these ioctl numbers any more,
but they are instead expected to be handled by the compat_blkdev_ioctl()
function, which is only called for block devices.
My first idea was that the ioctl numbers are used on files that are
not block devices, in this case the warning message would be (somewhat)
appropriate.
Whenever we get one of these messages on a real block device, that is
supposed to mean that an ioctl that was actually valid could not be
executed, and compat_blkdev_ioctl() returned -ENOIOCTLCMD.
Arnd <><
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
quoted
If you want to look into this, the question is just why these messages are
printed now, while they weren't printed before. I don't think any other
behavior got changed.
I'm not so sure about that. The reason that the messages are printed now
is that there is no fallback handler for these ioctl numbers any more,
but they are instead expected to be handled by the compat_blkdev_ioctl()
function, which is only called for block devices.
My first idea was that the ioctl numbers are used on files that are
not block devices, in this case the warning message would be (somewhat)
appropriate.
Whenever we get one of these messages on a real block device, that is
supposed to mean that an ioctl that was actually valid could not be
executed, and compat_blkdev_ioctl() returned -ENOIOCTLCMD.
In many cases these ioctls can indeed not be handled.
E.g. when using `hdparm -tT /dev/ps3da', hdparm issues an ioctl to flush the
cache. But this ioctl is not supported, not before and not after 2.6.23.
Before 2.6.23, it didn't print the message, in 2.6.23, it does.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
In many cases these ioctls can indeed not be handled.
E.g. when using `hdparm -tT /dev/ps3da', hdparm issues an ioctl to flush the
cache. But this ioctl is not supported, not before and not after 2.6.23.
Before 2.6.23, it didn't print the message, in 2.6.23, it does.
What I would expect to happen here is:
compat_blkdev_ioctl gets into the BLKFLSBUF case and calls blkdev_ioctl,
which calls blkdev_driver_ioctl, which returns -ENOTTY because
ps3disk_fops does not contain an unlocked_ioctl() or ioctl() method.
compat_sys_ioctl then detects that BLKFLSBUF was already handled by
compat_blkdev_ioctl (it did not return -ENOIOCTLCMD) and propagates
the error code to user space, without printing the message.
Whatever is different from that description must be what goes wrong.
Arnd <><