Am Sonntag, den 02.08.2009, 12:19 -0500 schrieb Dan McGee:

On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:

$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on .......

Hmm, these are very old dmesg-outputs, we already have builded beta1 on sigurg meanwhile...

Dan McGee wrote:

On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:

$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/archiso/install-iso/archlinux-2009.08-alpha-ftp-i686.img ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ff810c40) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1

ioctl32 messages from kernel are triggered when you are running a x86-64 kernel, and when call an ioclt() from 32 bit user-space app with an unsupported command (in other words when no conversion between 32 bit to 64 bit ioctl). But only 50 of this messages are showed by the kernel, next call just return -EINVAL -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Dieter Plaetinck wrote:

On Sun, 02 Aug 2009 14:35:32 -0300 Gerardo Exequiel Pozzi wrote:

...

Dan McGee wrote:

...

On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:

$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/archiso/install-iso/archlinux-2009.08-alpha-ftp-i686.img ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ff810c40) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1

ioctl32 messages from kernel are triggered when you are running a x86-64 kernel, and when call an ioclt() from 32 bit user-space app with an unsupported command (in other words when no conversion between 32 bit to 64 bit ioctl). But only 50 of this messages are showed by the kernel, next call just return -EINVAL

So, what does this mean? we call commands that don't exist, isn't that pretty bad? How does this affect iso building?

Dieter

Is a good question, but the answer is maybe difficult respond. First, the ioctl is not executed at all. Second the program that call to ioctl() with and unsupported cmd, in this enviroment, is probably that manages the return status from the call to avoid problems, then in case that is critical, the programs is sure that will be aborted instead of continue running. In this cite case 00001261 is 0 _IO (macro) (bits 31-30) 0x12 (driver) (15-8) 0x60 (function) (7-0) = 97 in decimal $ grep -r "_IO(" . | grep 0x12 | grep 97 ./include/linux/fs.h:#define BLKFLSBUF _IO(0x12,97) /* flush buffer cache */ So no problem. (i guess) and for 80041272 0x8 = 10 = _IOR 0x12 (driver) 0x72 (function) ./include/linux/fs.h:#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes (u64 *arg) */ Probably the program will try another ioctl to get size if one fail, an abort if can do it (i guess) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Am Sonntag, den 02.08.2009, 18:41 -0300 schrieb Gerardo Exequiel Pozzi:

...

Probably the program will try another ioctl to get size if one fail, an abort if can do it (i guess)

I'm sure the reaon for this dmesg messages were: a) Some error we possible have done during setup of the chroots (but the stat of /var/log/dmesg.log speak against this). b) More likely is the function command_usb () in mkarchiso, where and how we create the usb images (ext2 FS, partitioning the image file etc.) This in a linux32 chroot give probably the ioctl call errors in x86_64 kernel ring. Nothing to be worried about IMHO.... Gerhard