Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Wed, 13 Dec 2006 02:50:01 -0500 Chuck Ebbert <[EMAIL PROTECTED]> wrote: > In-Reply-To: <[EMAIL PROTECTED]> > > On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote: > > > do you think it may be a bug in the kernel? the stuff with wine that > > gets thrown in the kernel messages? > > Let's just say the behavior has changed. It now returns > -EINVAL instead of -ENOTTY when the msdos IOCTLs fail. For an unknown ioctl the correct return is -ENOTTY. For an invalid ioctl (known but wrong parameters) it may be -EINVAL. > Anyway, here is a much simpler patch that restores the previous > behavior (but leaves the message.) However if you aren't having > any problems now other than the messages maybe there's no real > problem after all? As far as I can see from a quick review the code should return -ENOTTY in this situation not -EINVAL, for all unhandled ioctls. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-13 at 02:50 -0500, Chuck Ebbert wrote: > In-Reply-To: <[EMAIL PROTECTED]> > > On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote: > > > do you think it may be a bug in the kernel? the stuff with wine that > > gets thrown in the kernel messages? > > Let's just say the behavior has changed. It now returns > -EINVAL instead of -ENOTTY when the msdos IOCTLs fail. > > > im 100% positive wine does NOT have > > access to any fat32, cause i entirely removed the only disk having such > > a filesystem, and it still likes to give this > > That's when this happens: running certain programs that try > msdos-type IOCTLs on native Linux filesystems. ohhh :) well wine may do that :) > > > however the last few > > times i havent observed the app going nuts > > If there aren't any other problems you can just turn off the logging. > > Did you change something else? i did upgrade from rc5 to final > > Anyway, here is a much simpler patch that restores the previous > behavior (but leaves the message.) However if you aren't having > any problems now other than the messages maybe there's no real > problem after all? well the hardlock problem still occurs, however that, (as i believe has veen the semi-conclusion in this thread) arent related? > > --- 2.6.19.1-64smp.orig/fs/compat.c > +++ 2.6.19.1-64smp/fs/compat.c > @@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne > > if (++count <= 50) > compat_ioctl_error(filp, fd, cmd, arg); > - error = -EINVAL; > + > + if (cmd == 0x82187201) > + error = -ENOTTY; > + else > + error = -EINVAL; > } > > goto out_fput; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-13 at 02:50 -0500, Chuck Ebbert wrote: In-Reply-To: [EMAIL PROTECTED] On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote: do you think it may be a bug in the kernel? the stuff with wine that gets thrown in the kernel messages? Let's just say the behavior has changed. It now returns -EINVAL instead of -ENOTTY when the msdos IOCTLs fail. im 100% positive wine does NOT have access to any fat32, cause i entirely removed the only disk having such a filesystem, and it still likes to give this That's when this happens: running certain programs that try msdos-type IOCTLs on native Linux filesystems. ohhh :) well wine may do that :) however the last few times i havent observed the app going nuts If there aren't any other problems you can just turn off the logging. Did you change something else? i did upgrade from rc5 to final Anyway, here is a much simpler patch that restores the previous behavior (but leaves the message.) However if you aren't having any problems now other than the messages maybe there's no real problem after all? well the hardlock problem still occurs, however that, (as i believe has veen the semi-conclusion in this thread) arent related? --- 2.6.19.1-64smp.orig/fs/compat.c +++ 2.6.19.1-64smp/fs/compat.c @@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne if (++count = 50) compat_ioctl_error(filp, fd, cmd, arg); - error = -EINVAL; + + if (cmd == 0x82187201) + error = -ENOTTY; + else + error = -EINVAL; } goto out_fput; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 13 Dec 2006 02:50:01 -0500 Chuck Ebbert [EMAIL PROTECTED] wrote: In-Reply-To: [EMAIL PROTECTED] On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote: do you think it may be a bug in the kernel? the stuff with wine that gets thrown in the kernel messages? Let's just say the behavior has changed. It now returns -EINVAL instead of -ENOTTY when the msdos IOCTLs fail. For an unknown ioctl the correct return is -ENOTTY. For an invalid ioctl (known but wrong parameters) it may be -EINVAL. Anyway, here is a much simpler patch that restores the previous behavior (but leaves the message.) However if you aren't having any problems now other than the messages maybe there's no real problem after all? As far as I can see from a quick review the code should return -ENOTTY in this situation not -EINVAL, for all unhandled ioctls. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: <[EMAIL PROTECTED]> On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote: > do you think it may be a bug in the kernel? the stuff with wine that > gets thrown in the kernel messages? Let's just say the behavior has changed. It now returns -EINVAL instead of -ENOTTY when the msdos IOCTLs fail. > im 100% positive wine does NOT have > access to any fat32, cause i entirely removed the only disk having such > a filesystem, and it still likes to give this That's when this happens: running certain programs that try msdos-type IOCTLs on native Linux filesystems. > however the last few > times i havent observed the app going nuts If there aren't any other problems you can just turn off the logging. Did you change something else? Anyway, here is a much simpler patch that restores the previous behavior (but leaves the message.) However if you aren't having any problems now other than the messages maybe there's no real problem after all? --- 2.6.19.1-64smp.orig/fs/compat.c +++ 2.6.19.1-64smp/fs/compat.c @@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne if (++count <= 50) compat_ioctl_error(filp, fd, cmd, arg); - error = -EINVAL; + + if (cmd == 0x82187201) + error = -ENOTTY; + else + error = -EINVAL; } goto out_fput; -- MBTI: IXTP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Mon, 2006-12-11 at 03:27 -0500, Chuck Ebbert wrote: > In-Reply-To: <[EMAIL PROTECTED]> > > On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote: > > > > Kasper, what problems (other that the annoying message) are you having? > > if it had only been the messages i wouldnt have complained. > > the thing is, when i get these messages, the app provoking them acts > > very strange, and in some cases, my system simply hardlocks. > > You can try the patch I sent you to see if it fixes the Wine app. > (David thought I was proposing it for the mainline kernel but I just > wanted to see whether it made a difference.) do you think it may be a bug in the kernel? the stuff with wine that gets thrown in the kernel messages? cause if it is, i ofcourse wish to help by testing. one more thing, im 100% positive wine does NOT have access to any fat32, cause i entirely removed the only disk having such a filesystem, and it still likes to give this, however the last few times i havent observed the app going nuts :) > > As for the lockups, there are possibly other bugs lurking in 2.6.19. yes, when the using-much-ram-perhaps-even-swap thing was mentioned i came to think, cause i do happen to use alarmingly much swap. i noticed a ~5 second lockup (where it actually returned to normal again) when i reached ~50mb free ram, and this was outside the chroot. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Mon, 2006-12-11 at 03:27 -0500, Chuck Ebbert wrote: In-Reply-To: [EMAIL PROTECTED] On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote: Kasper, what problems (other that the annoying message) are you having? if it had only been the messages i wouldnt have complained. the thing is, when i get these messages, the app provoking them acts very strange, and in some cases, my system simply hardlocks. You can try the patch I sent you to see if it fixes the Wine app. (David thought I was proposing it for the mainline kernel but I just wanted to see whether it made a difference.) do you think it may be a bug in the kernel? the stuff with wine that gets thrown in the kernel messages? cause if it is, i ofcourse wish to help by testing. one more thing, im 100% positive wine does NOT have access to any fat32, cause i entirely removed the only disk having such a filesystem, and it still likes to give this, however the last few times i havent observed the app going nuts :) As for the lockups, there are possibly other bugs lurking in 2.6.19. yes, when the using-much-ram-perhaps-even-swap thing was mentioned i came to think, cause i do happen to use alarmingly much swap. i noticed a ~5 second lockup (where it actually returned to normal again) when i reached ~50mb free ram, and this was outside the chroot. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: [EMAIL PROTECTED] On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote: do you think it may be a bug in the kernel? the stuff with wine that gets thrown in the kernel messages? Let's just say the behavior has changed. It now returns -EINVAL instead of -ENOTTY when the msdos IOCTLs fail. im 100% positive wine does NOT have access to any fat32, cause i entirely removed the only disk having such a filesystem, and it still likes to give this That's when this happens: running certain programs that try msdos-type IOCTLs on native Linux filesystems. however the last few times i havent observed the app going nuts If there aren't any other problems you can just turn off the logging. Did you change something else? Anyway, here is a much simpler patch that restores the previous behavior (but leaves the message.) However if you aren't having any problems now other than the messages maybe there's no real problem after all? --- 2.6.19.1-64smp.orig/fs/compat.c +++ 2.6.19.1-64smp/fs/compat.c @@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne if (++count = 50) compat_ioctl_error(filp, fd, cmd, arg); - error = -EINVAL; + + if (cmd == 0x82187201) + error = -ENOTTY; + else + error = -EINVAL; } goto out_fput; -- MBTI: IXTP - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: <[EMAIL PROTECTED]> On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote: > > Kasper, what problems (other that the annoying message) are you having? > if it had only been the messages i wouldnt have complained. > the thing is, when i get these messages, the app provoking them acts > very strange, and in some cases, my system simply hardlocks. You can try the patch I sent you to see if it fixes the Wine app. (David thought I was proposing it for the mainline kernel but I just wanted to see whether it made a difference.) As for the lockups, there are possibly other bugs lurking in 2.6.19. -- Chuck "Even supernovas have their duller moments." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: [EMAIL PROTECTED] On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote: Kasper, what problems (other that the annoying message) are you having? if it had only been the messages i wouldnt have complained. the thing is, when i get these messages, the app provoking them acts very strange, and in some cases, my system simply hardlocks. You can try the patch I sent you to see if it fixes the Wine app. (David thought I was proposing it for the mainline kernel but I just wanted to see whether it made a difference.) As for the lockups, there are possibly other bugs lurking in 2.6.19. -- Chuck Even supernovas have their duller moments. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 22:29 +0100, Andi Kleen wrote: > > and i am very very sure its because of this, i can run with the kernel > > (atleast with rc5 i had that long) for 10 days, and then chroot in, run > > the 32bit apps, and within hours of using, hardlock. > > Early AMD K8 platforms had a hardware bug that could have caused > such hardlocks when running 32bit code under 64bit (independent of anything > the kernel does). If you have such a board/CPU try a BIOS update. well, 2.6.18 were 100% stable, none of these issues. however you have caught my attention, cause i have one of the first amd64's, a 3200+ 1mb cache, socket 754. and an asus board. ill try find a floppy and upgrade the bios if there are updates available. > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
> and i am very very sure its because of this, i can run with the kernel > (atleast with rc5 i had that long) for 10 days, and then chroot in, run > the 32bit apps, and within hours of using, hardlock. Early AMD K8 platforms had a hardware bug that could have caused such hardlocks when running 32bit code under 64bit (independent of anything the kernel does). If you have such a board/CPU try a BIOS update. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 16:48 +, David Howells wrote: > Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > > What do you mean by "hardlock"? Do you mean the application has to be > > > killed, > > > or do you mean the kernel is stuck and the machine has to be rebooted? > > i mean the kernel itself, two of the times it has happened to me, magic > > sysrq havent even been able to reboot for me, i had to hit the button on > > my tower. > > That's got to be some other problem. There's no way this ioctl error message > change should cause the kernel to die - applications, yes; but not the kernel. Okay, do you have an idea what it can be then? it have to be something in relation to 32bit emulation, cause it happens only when using 32bit apps. > > David > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > What do you mean by "hardlock"? Do you mean the application has to be > > killed, > > or do you mean the kernel is stuck and the machine has to be rebooted? > i mean the kernel itself, two of the times it has happened to me, magic > sysrq havent even been able to reboot for me, i had to hit the button on > my tower. That's got to be some other problem. There's no way this ioctl error message change should cause the kernel to die - applications, yes; but not the kernel. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 13:08 +, David Howells wrote: > Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > and i am very very sure its because of this, i can run with the kernel > > (atleast with rc5 i had that long) for 10 days, and then chroot in, run > > the 32bit apps, and within hours of using, hardlock. > > What do you mean by "hardlock"? Do you mean the application has to be killed, > or do you mean the kernel is stuck and the machine has to be rebooted? i mean the kernel itself, two of the times it has happened to me, magic sysrq havent even been able to reboot for me, i had to hit the button on my tower. when i the very first time encountered this, it was with regedit, the app went nuts, and then it frooze, i had to kill -9 it, and then an hour later i noticed the kernel messages. > > David > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
Kasper Sandberg <[EMAIL PROTECTED]> wrote: > and i am very very sure its because of this, i can run with the kernel > (atleast with rc5 i had that long) for 10 days, and then chroot in, run > the 32bit apps, and within hours of using, hardlock. What do you mean by "hardlock"? Do you mean the application has to be killed, or do you mean the kernel is stuck and the machine has to be rebooted? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 21:31 -0500, Chuck Ebbert wrote: > In-Reply-To: <[EMAIL PROTECTED]> > > On Tue, 05 Dec 2006 22:11:11 +, David Howells wrote: > > > > I only have 32-bit userspace. When I run your program against > > > a directory on a JFS filesystem (msdos ioctls not supported) > > > I get this on vanilla 2.6.19: > > > > Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit > > kernel, but with a completely 32-bit userspace? > > It's FC5 i386 so there's no way any 64-bit userspace code is in there. > (I have a cross-compiler only for building kernels.) Having a pure > 32-bit userspace lets me switch between i386 and x86_64 kernels > without having to maintain two separate Linux installs. > > > A question for you: Why is userspace assuming that it'll get ENOTTY rather > > than EINVAL? > > I'm not sure it is, but that's what it used to get. > > Kasper, what problems (other that the annoying message) are you having? if it had only been the messages i wouldnt have complained. the thing is, when i get these messages, the app provoking them acts very strange, and in some cases, my system simply hardlocks. and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. wine seems to be worst at provoking hardlock, however i encountered one i am sure was caused by java(the 32bit one inside chroot). as i said in my post yesterday, my chroot doesent have access to my vfat partitions, so i dont believe thats it. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 21:31 -0500, Chuck Ebbert wrote: In-Reply-To: [EMAIL PROTECTED] On Tue, 05 Dec 2006 22:11:11 +, David Howells wrote: I only have 32-bit userspace. When I run your program against a directory on a JFS filesystem (msdos ioctls not supported) I get this on vanilla 2.6.19: Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit kernel, but with a completely 32-bit userspace? It's FC5 i386 so there's no way any 64-bit userspace code is in there. (I have a cross-compiler only for building kernels.) Having a pure 32-bit userspace lets me switch between i386 and x86_64 kernels without having to maintain two separate Linux installs. A question for you: Why is userspace assuming that it'll get ENOTTY rather than EINVAL? I'm not sure it is, but that's what it used to get. Kasper, what problems (other that the annoying message) are you having? if it had only been the messages i wouldnt have complained. the thing is, when i get these messages, the app provoking them acts very strange, and in some cases, my system simply hardlocks. and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. wine seems to be worst at provoking hardlock, however i encountered one i am sure was caused by java(the 32bit one inside chroot). as i said in my post yesterday, my chroot doesent have access to my vfat partitions, so i dont believe thats it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
Kasper Sandberg [EMAIL PROTECTED] wrote: and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. What do you mean by hardlock? Do you mean the application has to be killed, or do you mean the kernel is stuck and the machine has to be rebooted? David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 13:08 +, David Howells wrote: Kasper Sandberg [EMAIL PROTECTED] wrote: and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. What do you mean by hardlock? Do you mean the application has to be killed, or do you mean the kernel is stuck and the machine has to be rebooted? i mean the kernel itself, two of the times it has happened to me, magic sysrq havent even been able to reboot for me, i had to hit the button on my tower. when i the very first time encountered this, it was with regedit, the app went nuts, and then it frooze, i had to kill -9 it, and then an hour later i noticed the kernel messages. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
Kasper Sandberg [EMAIL PROTECTED] wrote: What do you mean by hardlock? Do you mean the application has to be killed, or do you mean the kernel is stuck and the machine has to be rebooted? i mean the kernel itself, two of the times it has happened to me, magic sysrq havent even been able to reboot for me, i had to hit the button on my tower. That's got to be some other problem. There's no way this ioctl error message change should cause the kernel to die - applications, yes; but not the kernel. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 16:48 +, David Howells wrote: Kasper Sandberg [EMAIL PROTECTED] wrote: What do you mean by hardlock? Do you mean the application has to be killed, or do you mean the kernel is stuck and the machine has to be rebooted? i mean the kernel itself, two of the times it has happened to me, magic sysrq havent even been able to reboot for me, i had to hit the button on my tower. That's got to be some other problem. There's no way this ioctl error message change should cause the kernel to die - applications, yes; but not the kernel. Okay, do you have an idea what it can be then? it have to be something in relation to 32bit emulation, cause it happens only when using 32bit apps. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. Early AMD K8 platforms had a hardware bug that could have caused such hardlocks when running 32bit code under 64bit (independent of anything the kernel does). If you have such a board/CPU try a BIOS update. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 22:29 +0100, Andi Kleen wrote: and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. Early AMD K8 platforms had a hardware bug that could have caused such hardlocks when running 32bit code under 64bit (independent of anything the kernel does). If you have such a board/CPU try a BIOS update. well, 2.6.18 were 100% stable, none of these issues. however you have caught my attention, cause i have one of the first amd64's, a 3200+ 1mb cache, socket 754. and an asus board. ill try find a floppy and upgrade the bios if there are updates available. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: <[EMAIL PROTECTED]> On Tue, 05 Dec 2006 22:11:11 +, David Howells wrote: > > I only have 32-bit userspace. When I run your program against > > a directory on a JFS filesystem (msdos ioctls not supported) > > I get this on vanilla 2.6.19: > > Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit > kernel, but with a completely 32-bit userspace? It's FC5 i386 so there's no way any 64-bit userspace code is in there. (I have a cross-compiler only for building kernels.) Having a pure 32-bit userspace lets me switch between i386 and x86_64 kernels without having to maintain two separate Linux installs. > A question for you: Why is userspace assuming that it'll get ENOTTY rather > than EINVAL? I'm not sure it is, but that's what it used to get. Kasper, what problems (other that the annoying message) are you having? -- Chuck "Even supernovas have their duller moments." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 14:19 +, David Howells wrote:
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > Here is a patch to reverse that. Kasper, can you test it?
> > (Your filesystem is on a FAT/VFAT volume, I assume.)
I do have a fat32 filesystem mounted using the vfat driver (the msdos
one arent compiled in), however the chroot in no way has access to this,
and i dont see how ANY 32bit apps can have attempted to access it, ill
go so far as say im certain they havent.
>
> Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
okay, i will not.
>
> Can you compile and run the attached program as both 32-bit and 64-bit?
Yes, i will conduct tests, however it will have to wait till atleast
tomorow (cant garantuee anything though, i have lots of work to do).
>
> On my x86_64 test box, I did:
>
> [EMAIL PROTECTED] ~]# mkfs.vfat /dev/sda5
> [EMAIL PROTECTED] ~]# mount /dev/sda5 /mnt
> [EMAIL PROTECTED] ~]# mkdir /mnt/a
> [EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 32-bit
> 268 : 82187201, 82187202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> Calling VFAT_IOCTL_READDIR_BOTH
> [EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 64-bit
> 280 : 82307201, 82307202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> ioctl: Inappropriate ioctl for device
> Calling VFAT_IOCTL_READDIR_BOTH
>
> Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
> function). Tracing the 64-bit version shows that the right numbers are being
> given to the syscall, though strace decodes them as the same symbol if not in
> raw mode:
>
> [EMAIL PROTECTED] ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
> 280 : 82307201, 82307202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> ioctl(0x3, 0x82187201, 0x7fff9cec36c0) = -1 (errno 25)
> ioctl: Inappropriate ioctl for device
> Calling VFAT_IOCTL_READDIR_BOTH
> ioctl(0x3, 0x82307201, 0x7fff9cec3490) = 0x1
> Process 3410 detached
>
> Applying the attached patch to the kernel produces the following elements in
> the log for the 32-bit compilation:
>
> ==> fat_compat_dir_ioctl(82187201,ffa803b8)
> ==> fat_dir_ioctl(82307201,810036a97ca8)
> <== fat_dir_ioctl() = 1
> <== fat_compat_dir_ioctl() = 1
> ==> fat_compat_dir_ioctl(82187201,ffa801a0)
> ==> fat_dir_ioctl(82307201,810036a97ca8)
> <== fat_dir_ioctl() = 1
> <== fat_compat_dir_ioctl() = 1
>
> and this for the 64-bit compilation:
>
> ==> fat_dir_ioctl(82187201,7fff031f69f0)
> call fat_generic_ioctl()
> <== fat_dir_ioctl() = -25
> ==> fat_dir_ioctl(82307201,7fff031f67c0)
> <== fat_dir_ioctl() = 1
>
> Which is entirely what I'd expect.
>
> However, it's possible that the 64-bit kernel interface used to allow the
> 32-bit calls. If that's the case could you be running a 64-bit program
> somewhere in your 32-bit chroot?
I am basically positive that i am not running 64bit stuff within my
32bit chroot, however i will check to make absolutely sure.
>
> | i have only tested with >=rc5, thw folling, as an example, appears in
> | dmesg:
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
>
> How do you get that? I don't see anything like that. I've tried:
all i did was run wine's regedit inside my 32bit chroot.
>
> echo 1 >/proc/sys/kernel/compat-log
>
> But that doesn't seem to do anything.
>
> David
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
Chuck Ebbert <[EMAIL PROTECTED]> wrote: > I only have 32-bit userspace. When I run your program against > a directory on a JFS filesystem (msdos ioctls not supported) > I get this on vanilla 2.6.19: Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit kernel, but with a completely 32-bit userspace? > I only have 32-bit userspace. When I run your program against > a directory on a JFS filesystem (msdos ioctls not supported) > I get this on vanilla 2.6.19: Wait! You're using JFS, not VFAT? Oh... I see. Okay: It's not the MSDOS/VFAT patch that's wrong. Please don't revert that. It's the compat ioctl code that's "wrong". So compat_sys_ioctl() used to return ENOTTY (ENOIOCTLCMD internally) because the MSDOS ioctl was listed as one that could be translated but it didn't apply to JFS. But now, since all the block-based filesystem ioctls have been removed from that list, you now get EINVAL, not ENOTTY. > So apparently this is a feature? Unfortunately, I think it has to be. We could add a master list of ioctls to be issued with particular errors if the driver doesn't support them, but is it worth it? A question for you: Why is userspace assuming that it'll get ENOTTY rather than EINVAL? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 05 Dec 2006 14:19:53 +, David Howells wrote:
> > Here is a patch to reverse that. Kasper, can you test it?
> > (Your filesystem is on a FAT/VFAT volume, I assume.)
>
> Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
>
> Can you compile and run the attached program as both 32-bit and 64-bit?
I only have 32-bit userspace. When I run your program against
a directory on a JFS filesystem (msdos ioctls not supported)
I get this on vanilla 2.6.19:
$ ./vfat_ioctl32.ex .
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Invalid argument
Calling VFAT_IOCTL_READDIR_BOTH
ioctl: Invalid argument
After reverting the msdos compat ioctls patch it changes to:
$ ./vfat_ioctl32.ex .
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
ioctl: Inappropriate ioctl for device
> | i have only tested with >=rc5, thw folling, as an example, appears in
> | dmesg:
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
>
> How do you get that?
I get those messages when the ioctl call returns 'invalid argument.'
In fs/compat.s::compat_sys_ioctl() you can see it changing the
return value after it prints the message:
static int count;
if (++count <= 50)
compat_ioctl_error(filp, fd, cmd, arg);
error = -EINVAL;
So apparently this is a feature?
--
Chuck
"Even supernovas have their duller moments."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> Here is a patch to reverse that. Kasper, can you test it?
> (Your filesystem is on a FAT/VFAT volume, I assume.)
Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
Can you compile and run the attached program as both 32-bit and 64-bit?
On my x86_64 test box, I did:
[EMAIL PROTECTED] ~]# mkfs.vfat /dev/sda5
[EMAIL PROTECTED] ~]# mount /dev/sda5 /mnt
[EMAIL PROTECTED] ~]# mkdir /mnt/a
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 32-bit
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
Calling VFAT_IOCTL_READDIR_BOTH
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 64-bit
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
function). Tracing the 64-bit version shows that the right numbers are being
given to the syscall, though strace decodes them as the same symbol if not in
raw mode:
[EMAIL PROTECTED] ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl(0x3, 0x82187201, 0x7fff9cec36c0) = -1 (errno 25)
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
ioctl(0x3, 0x82307201, 0x7fff9cec3490) = 0x1
Process 3410 detached
Applying the attached patch to the kernel produces the following elements in
the log for the 32-bit compilation:
==> fat_compat_dir_ioctl(82187201,ffa803b8)
==> fat_dir_ioctl(82307201,810036a97ca8)
<== fat_dir_ioctl() = 1
<== fat_compat_dir_ioctl() = 1
==> fat_compat_dir_ioctl(82187201,ffa801a0)
==> fat_dir_ioctl(82307201,810036a97ca8)
<== fat_dir_ioctl() = 1
<== fat_compat_dir_ioctl() = 1
and this for the 64-bit compilation:
==> fat_dir_ioctl(82187201,7fff031f69f0)
call fat_generic_ioctl()
<== fat_dir_ioctl() = -25
==> fat_dir_ioctl(82307201,7fff031f67c0)
<== fat_dir_ioctl() = 1
Which is entirely what I'd expect.
However, it's possible that the 64-bit kernel interface used to allow the
32-bit calls. If that's the case could you be running a 64-bit program
somewhere in your 32-bit chroot?
| i have only tested with >=rc5, thw folling, as an example, appears in
| dmesg:
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
How do you get that? I don't see anything like that. I've tried:
echo 1 >/proc/sys/kernel/compat-log
But that doesn't seem to do anything.
David
#include
#include
#include
#include
#include
#define _IOC_NRBITS 8
#define _IOC_TYPEBITS 8
#define _IOC_SIZEBITS 14
#define _IOC_DIRBITS 2
#define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
#define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1)
#define _IOC_SIZEMASK ((1 << _IOC_SIZEBITS)-1)
#define _IOC_DIRMASK ((1 << _IOC_DIRBITS)-1)
#define _IOC_NRSHIFT 0
#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS)
#define _IOC_NONE 0U
#define _IOC_WRITE 1U
#define _IOC_READ 2U
#define _IOC(dir,type,nr,size) \
(((dir) << _IOC_DIRSHIFT) | \
((type) << _IOC_TYPESHIFT) | \
((nr) << _IOC_NRSHIFT) | \
((size) << _IOC_SIZESHIFT))
extern unsigned int __invalid_size_argument_for_IOC;
#define _IOC_TYPECHECK(t) \
((sizeof(t) == sizeof(t[1]) && \
sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
sizeof(t) : __invalid_size_argument_for_IOC)
#define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0)
#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOWR(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOR_BAD(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))
#define _IOW_BAD(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
#define _IOWR_BAD(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))
#define VFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct compat_dirent[2])
#define VFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct compat_dirent[2])
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2])
#define VFAT_IOCTL_READDIR_SHORT _IOR('r', 2, struct dirent [2])
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef long __kernel_off_t;
typedef s32
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
Andrew Morton <[EMAIL PROTECTED]> wrote: > Possibly one could work out what's going on by reverse-engineering x86_64 > ioctl command 0x82187201, but unfortunately I don't have time to do that. strace can do that. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: <[EMAIL PROTECTED]>
On Mon, 4 Dec 2006 19:20:18 -0800, Andrew Morton wrote:
> On Tue, 05 Dec 2006 03:36:09 +0100
> Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > i know i said i suspected this was another bug, but i have revised my
> > suspecisions, and i do believe its in relation to x86 chroot on x86_64
> > install, as it has happened with more stuff now, inside the chroot, and
> > only inside the chroot, while the same apps dont do it outside chroot.
> >
> > 2.6.19 release is affected too
> > > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > > arg(00221000) on /home/redeeman
> > > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> Possibly some ioctl got removed. I don't know why it would only occur
> within a chrooted environment.
>
> Possibly one could work out what's going on by reverse-engineering x86_64
> ioctl command 0x82187201, but unfortunately I don't have time to do that.
That is VFAT_IOCTL_READDIR_BOTH32
This patch:
[PATCH] BLOCK: Move the msdos device ioctl
compat stuff to the msdos driver [try #6]
may have caused this.
Here is a patch to reverse that. Kasper, can you test it?
(Your filesystem is on a FAT/VFAT volume, I assume.)
[Revert] [PATCH] BLOCK: Move the msdos device ioctl compat stuff to the msdos
driver [try #6]
Reverts:
Move the msdos device ioctl compat stuff from fs/compat_ioctl.c to the msdos
driver so that the msdos header file doesn't need to be included.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
committer: Jens Axboe <[EMAIL PROTECTED]> 1159642350 +0200
fs/compat_ioctl.c | 49 +++
fs/fat/dir.c | 56 --
2 files changed, 49 insertions(+), 56 deletions(-)
--- 2.6.19.0.2-32.orig/fs/compat_ioctl.c
+++ 2.6.19.0.2-32/fs/compat_ioctl.c
@@ -107,6 +107,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1945,6 +1946,51 @@ static int mtd_rw_oob(unsigned int fd, u
return err;
}
+#defineVFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct
compat_dirent[2])
+#defineVFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct
compat_dirent[2])
+
+static long
+put_dirent32 (struct dirent *d, struct compat_dirent __user *d32)
+{
+if (!access_ok(VERIFY_WRITE, d32, sizeof(struct compat_dirent)))
+return -EFAULT;
+
+__put_user(d->d_ino, >d_ino);
+__put_user(d->d_off, >d_off);
+__put_user(d->d_reclen, >d_reclen);
+if (__copy_to_user(d32->d_name, d->d_name, d->d_reclen))
+ return -EFAULT;
+
+return 0;
+}
+
+static int vfat_ioctl32(unsigned fd, unsigned cmd, unsigned long arg)
+{
+ struct compat_dirent __user *p = compat_ptr(arg);
+ int ret;
+ mm_segment_t oldfs = get_fs();
+ struct dirent d[2];
+
+ switch(cmd)
+ {
+ case VFAT_IOCTL_READDIR_BOTH32:
+ cmd = VFAT_IOCTL_READDIR_BOTH;
+ break;
+ case VFAT_IOCTL_READDIR_SHORT32:
+ cmd = VFAT_IOCTL_READDIR_SHORT;
+ break;
+ }
+
+ set_fs(KERNEL_DS);
+ ret = sys_ioctl(fd,cmd,(unsigned long));
+ set_fs(oldfs);
+ if (ret >= 0) {
+ ret |= put_dirent32([0], p);
+ ret |= put_dirent32([1], p + 1);
+ }
+ return ret;
+}
+
#ifdef CONFIG_BLOCK
struct raw32_config_request
{
@@ -2513,6 +2559,9 @@ HANDLE_IOCTL(SONET_GETFRSENSE, do_atm_io
HANDLE_IOCTL(BLKBSZGET_32, do_blkbszget)
HANDLE_IOCTL(BLKBSZSET_32, do_blkbszset)
HANDLE_IOCTL(BLKGETSIZE64_32, do_blkgetsize64)
+/* vfat */
+HANDLE_IOCTL(VFAT_IOCTL_READDIR_BOTH32, vfat_ioctl32)
+HANDLE_IOCTL(VFAT_IOCTL_READDIR_SHORT32, vfat_ioctl32)
/* Raw devices */
HANDLE_IOCTL(RAW_SETBIND, raw_ioctl)
HANDLE_IOCTL(RAW_GETBIND, raw_ioctl)
--- 2.6.19.0.2-32.orig/fs/fat/dir.c
+++ 2.6.19.0.2-32/fs/fat/dir.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include
static inline loff_t fat_make_i_pos(struct super_block *sb,
@@ -742,65 +741,10 @@ static int fat_dir_ioctl(struct inode *
return ret;
}
-#ifdef CONFIG_COMPAT
-#defineVFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct
compat_dirent[2])
-#defineVFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct
compat_dirent[2])
-
-static long fat_compat_put_dirent32(struct dirent *d,
- struct compat_dirent __user *d32)
-{
-if (!access_ok(VERIFY_WRITE, d32, sizeof(struct compat_dirent)))
-return -EFAULT;
-
-__put_user(d->d_ino, >d_ino);
-__put_user(d->d_off, >d_off);
-__put_user(d->d_reclen, >d_reclen);
-if (__copy_to_user(d32->d_name, d->d_name, d->d_reclen))
-
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 14:19 +, David Howells wrote:
Chuck Ebbert [EMAIL PROTECTED] wrote:
Here is a patch to reverse that. Kasper, can you test it?
(Your filesystem is on a FAT/VFAT volume, I assume.)
I do have a fat32 filesystem mounted using the vfat driver (the msdos
one arent compiled in), however the chroot in no way has access to this,
and i dont see how ANY 32bit apps can have attempted to access it, ill
go so far as say im certain they havent.
Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
okay, i will not.
Can you compile and run the attached program as both 32-bit and 64-bit?
Yes, i will conduct tests, however it will have to wait till atleast
tomorow (cant garantuee anything though, i have lots of work to do).
On my x86_64 test box, I did:
[EMAIL PROTECTED] ~]# mkfs.vfat /dev/sda5
[EMAIL PROTECTED] ~]# mount /dev/sda5 /mnt
[EMAIL PROTECTED] ~]# mkdir /mnt/a
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 32-bit
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
Calling VFAT_IOCTL_READDIR_BOTH
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 64-bit
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
function). Tracing the 64-bit version shows that the right numbers are being
given to the syscall, though strace decodes them as the same symbol if not in
raw mode:
[EMAIL PROTECTED] ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl(0x3, 0x82187201, 0x7fff9cec36c0) = -1 (errno 25)
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
ioctl(0x3, 0x82307201, 0x7fff9cec3490) = 0x1
Process 3410 detached
Applying the attached patch to the kernel produces the following elements in
the log for the 32-bit compilation:
== fat_compat_dir_ioctl(82187201,ffa803b8)
== fat_dir_ioctl(82307201,810036a97ca8)
== fat_dir_ioctl() = 1
== fat_compat_dir_ioctl() = 1
== fat_compat_dir_ioctl(82187201,ffa801a0)
== fat_dir_ioctl(82307201,810036a97ca8)
== fat_dir_ioctl() = 1
== fat_compat_dir_ioctl() = 1
and this for the 64-bit compilation:
== fat_dir_ioctl(82187201,7fff031f69f0)
call fat_generic_ioctl()
== fat_dir_ioctl() = -25
== fat_dir_ioctl(82307201,7fff031f67c0)
== fat_dir_ioctl() = 1
Which is entirely what I'd expect.
However, it's possible that the 64-bit kernel interface used to allow the
32-bit calls. If that's the case could you be running a 64-bit program
somewhere in your 32-bit chroot?
I am basically positive that i am not running 64bit stuff within my
32bit chroot, however i will check to make absolutely sure.
| i have only tested with =rc5, thw folling, as an example, appears in
| dmesg:
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
How do you get that? I don't see anything like that. I've tried:
all i did was run wine's regedit inside my 32bit chroot.
echo 1 /proc/sys/kernel/compat-log
But that doesn't seem to do anything.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: [EMAIL PROTECTED] On Tue, 05 Dec 2006 22:11:11 +, David Howells wrote: I only have 32-bit userspace. When I run your program against a directory on a JFS filesystem (msdos ioctls not supported) I get this on vanilla 2.6.19: Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit kernel, but with a completely 32-bit userspace? It's FC5 i386 so there's no way any 64-bit userspace code is in there. (I have a cross-compiler only for building kernels.) Having a pure 32-bit userspace lets me switch between i386 and x86_64 kernels without having to maintain two separate Linux installs. A question for you: Why is userspace assuming that it'll get ENOTTY rather than EINVAL? I'm not sure it is, but that's what it used to get. Kasper, what problems (other that the annoying message) are you having? -- Chuck Even supernovas have their duller moments. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: [EMAIL PROTECTED]
On Mon, 4 Dec 2006 19:20:18 -0800, Andrew Morton wrote:
On Tue, 05 Dec 2006 03:36:09 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
2.6.19 release is affected too
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Possibly some ioctl got removed. I don't know why it would only occur
within a chrooted environment.
Possibly one could work out what's going on by reverse-engineering x86_64
ioctl command 0x82187201, but unfortunately I don't have time to do that.
That is VFAT_IOCTL_READDIR_BOTH32
This patch:
[PATCH] BLOCK: Move the msdos device ioctl
compat stuff to the msdos driver [try #6]
may have caused this.
Here is a patch to reverse that. Kasper, can you test it?
(Your filesystem is on a FAT/VFAT volume, I assume.)
[Revert] [PATCH] BLOCK: Move the msdos device ioctl compat stuff to the msdos
driver [try #6]
Reverts:
Move the msdos device ioctl compat stuff from fs/compat_ioctl.c to the msdos
driver so that the msdos header file doesn't need to be included.
Signed-Off-By: David Howells [EMAIL PROTECTED]
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
committer: Jens Axboe [EMAIL PROTECTED] 1159642350 +0200
fs/compat_ioctl.c | 49 +++
fs/fat/dir.c | 56 --
2 files changed, 49 insertions(+), 56 deletions(-)
--- 2.6.19.0.2-32.orig/fs/compat_ioctl.c
+++ 2.6.19.0.2-32/fs/compat_ioctl.c
@@ -107,6 +107,7 @@
#include linux/nbd.h
#include linux/random.h
#include linux/filter.h
+#include linux/msdos_fs.h
#include linux/pktcdvd.h
#include linux/hiddev.h
@@ -1945,6 +1946,51 @@ static int mtd_rw_oob(unsigned int fd, u
return err;
}
+#defineVFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct
compat_dirent[2])
+#defineVFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct
compat_dirent[2])
+
+static long
+put_dirent32 (struct dirent *d, struct compat_dirent __user *d32)
+{
+if (!access_ok(VERIFY_WRITE, d32, sizeof(struct compat_dirent)))
+return -EFAULT;
+
+__put_user(d-d_ino, d32-d_ino);
+__put_user(d-d_off, d32-d_off);
+__put_user(d-d_reclen, d32-d_reclen);
+if (__copy_to_user(d32-d_name, d-d_name, d-d_reclen))
+ return -EFAULT;
+
+return 0;
+}
+
+static int vfat_ioctl32(unsigned fd, unsigned cmd, unsigned long arg)
+{
+ struct compat_dirent __user *p = compat_ptr(arg);
+ int ret;
+ mm_segment_t oldfs = get_fs();
+ struct dirent d[2];
+
+ switch(cmd)
+ {
+ case VFAT_IOCTL_READDIR_BOTH32:
+ cmd = VFAT_IOCTL_READDIR_BOTH;
+ break;
+ case VFAT_IOCTL_READDIR_SHORT32:
+ cmd = VFAT_IOCTL_READDIR_SHORT;
+ break;
+ }
+
+ set_fs(KERNEL_DS);
+ ret = sys_ioctl(fd,cmd,(unsigned long)d);
+ set_fs(oldfs);
+ if (ret = 0) {
+ ret |= put_dirent32(d[0], p);
+ ret |= put_dirent32(d[1], p + 1);
+ }
+ return ret;
+}
+
#ifdef CONFIG_BLOCK
struct raw32_config_request
{
@@ -2513,6 +2559,9 @@ HANDLE_IOCTL(SONET_GETFRSENSE, do_atm_io
HANDLE_IOCTL(BLKBSZGET_32, do_blkbszget)
HANDLE_IOCTL(BLKBSZSET_32, do_blkbszset)
HANDLE_IOCTL(BLKGETSIZE64_32, do_blkgetsize64)
+/* vfat */
+HANDLE_IOCTL(VFAT_IOCTL_READDIR_BOTH32, vfat_ioctl32)
+HANDLE_IOCTL(VFAT_IOCTL_READDIR_SHORT32, vfat_ioctl32)
/* Raw devices */
HANDLE_IOCTL(RAW_SETBIND, raw_ioctl)
HANDLE_IOCTL(RAW_GETBIND, raw_ioctl)
--- 2.6.19.0.2-32.orig/fs/fat/dir.c
+++ 2.6.19.0.2-32/fs/fat/dir.c
@@ -20,7 +20,6 @@
#include linux/dirent.h
#include linux/smp_lock.h
#include linux/buffer_head.h
-#include linux/compat.h
#include asm/uaccess.h
static inline loff_t fat_make_i_pos(struct super_block *sb,
@@ -742,65 +741,10 @@ static int fat_dir_ioctl(struct inode *
return ret;
}
-#ifdef CONFIG_COMPAT
-#defineVFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct
compat_dirent[2])
-#defineVFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct
compat_dirent[2])
-
-static long fat_compat_put_dirent32(struct dirent *d,
- struct compat_dirent __user *d32)
-{
-if (!access_ok(VERIFY_WRITE, d32, sizeof(struct compat_dirent)))
-return -EFAULT;
-
-__put_user(d-d_ino, d32-d_ino);
-__put_user(d-d_off, d32-d_off);
-
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
Andrew Morton [EMAIL PROTECTED] wrote: Possibly one could work out what's going on by reverse-engineering x86_64 ioctl command 0x82187201, but unfortunately I don't have time to do that. strace can do that. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
Chuck Ebbert [EMAIL PROTECTED] wrote:
Here is a patch to reverse that. Kasper, can you test it?
(Your filesystem is on a FAT/VFAT volume, I assume.)
Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
Can you compile and run the attached program as both 32-bit and 64-bit?
On my x86_64 test box, I did:
[EMAIL PROTECTED] ~]# mkfs.vfat /dev/sda5
[EMAIL PROTECTED] ~]# mount /dev/sda5 /mnt
[EMAIL PROTECTED] ~]# mkdir /mnt/a
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 32-bit
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
Calling VFAT_IOCTL_READDIR_BOTH
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 64-bit
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
function). Tracing the 64-bit version shows that the right numbers are being
given to the syscall, though strace decodes them as the same symbol if not in
raw mode:
[EMAIL PROTECTED] ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl(0x3, 0x82187201, 0x7fff9cec36c0) = -1 (errno 25)
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
ioctl(0x3, 0x82307201, 0x7fff9cec3490) = 0x1
Process 3410 detached
Applying the attached patch to the kernel produces the following elements in
the log for the 32-bit compilation:
== fat_compat_dir_ioctl(82187201,ffa803b8)
== fat_dir_ioctl(82307201,810036a97ca8)
== fat_dir_ioctl() = 1
== fat_compat_dir_ioctl() = 1
== fat_compat_dir_ioctl(82187201,ffa801a0)
== fat_dir_ioctl(82307201,810036a97ca8)
== fat_dir_ioctl() = 1
== fat_compat_dir_ioctl() = 1
and this for the 64-bit compilation:
== fat_dir_ioctl(82187201,7fff031f69f0)
call fat_generic_ioctl()
== fat_dir_ioctl() = -25
== fat_dir_ioctl(82307201,7fff031f67c0)
== fat_dir_ioctl() = 1
Which is entirely what I'd expect.
However, it's possible that the 64-bit kernel interface used to allow the
32-bit calls. If that's the case could you be running a 64-bit program
somewhere in your 32-bit chroot?
| i have only tested with =rc5, thw folling, as an example, appears in
| dmesg:
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
How do you get that? I don't see anything like that. I've tried:
echo 1 /proc/sys/kernel/compat-log
But that doesn't seem to do anything.
David
#include stdlib.h
#include stdio.h
#include fcntl.h
#include unistd.h
#include sys/ioctl.h
#define _IOC_NRBITS 8
#define _IOC_TYPEBITS 8
#define _IOC_SIZEBITS 14
#define _IOC_DIRBITS 2
#define _IOC_NRMASK ((1 _IOC_NRBITS)-1)
#define _IOC_TYPEMASK ((1 _IOC_TYPEBITS)-1)
#define _IOC_SIZEMASK ((1 _IOC_SIZEBITS)-1)
#define _IOC_DIRMASK ((1 _IOC_DIRBITS)-1)
#define _IOC_NRSHIFT 0
#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS)
#define _IOC_NONE 0U
#define _IOC_WRITE 1U
#define _IOC_READ 2U
#define _IOC(dir,type,nr,size) \
(((dir) _IOC_DIRSHIFT) | \
((type) _IOC_TYPESHIFT) | \
((nr)_IOC_NRSHIFT) | \
((size) _IOC_SIZESHIFT))
extern unsigned int __invalid_size_argument_for_IOC;
#define _IOC_TYPECHECK(t) \
((sizeof(t) == sizeof(t[1]) \
sizeof(t) (1 _IOC_SIZEBITS)) ? \
sizeof(t) : __invalid_size_argument_for_IOC)
#define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0)
#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOWR(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOR_BAD(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))
#define _IOW_BAD(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
#define _IOWR_BAD(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))
#define VFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct compat_dirent[2])
#define VFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct compat_dirent[2])
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2])
#define VFAT_IOCTL_READDIR_SHORT _IOR('r', 2, struct dirent [2])
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef long __kernel_off_t;
typedef s32
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: [EMAIL PROTECTED]
On Tue, 05 Dec 2006 14:19:53 +, David Howells wrote:
Here is a patch to reverse that. Kasper, can you test it?
(Your filesystem is on a FAT/VFAT volume, I assume.)
Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
Can you compile and run the attached program as both 32-bit and 64-bit?
I only have 32-bit userspace. When I run your program against
a directory on a JFS filesystem (msdos ioctls not supported)
I get this on vanilla 2.6.19:
$ ./vfat_ioctl32.ex .
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Invalid argument
Calling VFAT_IOCTL_READDIR_BOTH
ioctl: Invalid argument
After reverting the msdos compat ioctls patch it changes to:
$ ./vfat_ioctl32.ex .
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
ioctl: Inappropriate ioctl for device
| i have only tested with =rc5, thw folling, as an example, appears in
| dmesg:
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
How do you get that?
I get those messages when the ioctl call returns 'invalid argument.'
In fs/compat.s::compat_sys_ioctl() you can see it changing the
return value after it prints the message:
static int count;
if (++count = 50)
compat_ioctl_error(filp, fd, cmd, arg);
error = -EINVAL;
So apparently this is a feature?
--
Chuck
Even supernovas have their duller moments.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
Chuck Ebbert [EMAIL PROTECTED] wrote: I only have 32-bit userspace. When I run your program against a directory on a JFS filesystem (msdos ioctls not supported) I get this on vanilla 2.6.19: Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit kernel, but with a completely 32-bit userspace? I only have 32-bit userspace. When I run your program against a directory on a JFS filesystem (msdos ioctls not supported) I get this on vanilla 2.6.19: Wait! You're using JFS, not VFAT? Oh... I see. Okay: It's not the MSDOS/VFAT patch that's wrong. Please don't revert that. It's the compat ioctl code that's wrong. So compat_sys_ioctl() used to return ENOTTY (ENOIOCTLCMD internally) because the MSDOS ioctl was listed as one that could be translated but it didn't apply to JFS. But now, since all the block-based filesystem ioctls have been removed from that list, you now get EINVAL, not ENOTTY. So apparently this is a feature? Unfortunately, I think it has to be. We could add a master list of ioctls to be issued with particular errors if the driver doesn't support them, but is it worth it? A question for you: Why is userspace assuming that it'll get ENOTTY rather than EINVAL? David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 05 Dec 2006 03:36:09 +0100
Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> i know i said i suspected this was another bug, but i have revised my
> suspecisions, and i do believe its in relation to x86 chroot on x86_64
> install, as it has happened with more stuff now, inside the chroot, and
> only inside the chroot, while the same apps dont do it outside chroot.
>
> 2.6.19 release is affected too
Please don't top-post.
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> >
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > >
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> >
> > Try
> >
> > echo 0 > /proc/sys/kernel/compat-log
> >
> > I don't _think_ we did anything to change the logging in there. Which
> > kernel
> > version were you using previously (the one which didn't do this)?
Possibly some ioctl got removed. I don't know why it would only occur
within a chrooted environment.
Possibly one could work out what's going on by reverse-engineering x86_64
ioctl command 0x82187201, but unfortunately I don't have time to do that.
Also unfortunately there appears to be an assumption that unless I
personally can immediately and straightforwardly identify a bug-owner, I
personally own the bug. The best I can suggest is that you raise a report
at bugzilla.kernel.org so this issue gets ignored in a more organised
fashion.
Sorry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 03:36 +0100, Kasper Sandberg wrote:
> i know i said i suspected this was another bug, but i have revised my
> suspecisions, and i do believe its in relation to x86 chroot on x86_64
> install, as it has happened with more stuff now, inside the chroot, and
> only inside the chroot, while the same apps dont do it outside chroot.
and by that (so that theres no confusion), i mean that with the x86_64
binaries of the same application dont crash it, but the x86 binaries in
the chroot does :)
>
> 2.6.19 release is affected too
>
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> >
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > >
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> >
> > Try
> >
> > echo 0 > /proc/sys/kernel/compat-log
> >
> > I don't _think_ we did anything to change the logging in there. Which
> > kernel
> > version were you using previously (the one which didn't do this)?
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
2.6.19 release is affected too
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> >
> > i have only tested with >=rc5, thw folling, as an example, appears in
> > dmesg:
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
>
> Try
>
> echo 0 > /proc/sys/kernel/compat-log
>
> I don't _think_ we did anything to change the logging in there. Which kernel
> version were you using previously (the one which didn't do this)?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
2.6.19 release is affected too
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which kernel
version were you using previously (the one which didn't do this)?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 03:36 +0100, Kasper Sandberg wrote:
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
and by that (so that theres no confusion), i mean that with the x86_64
binaries of the same application dont crash it, but the x86 binaries in
the chroot does :)
2.6.19 release is affected too
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which
kernel
version were you using previously (the one which didn't do this)?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Tue, 05 Dec 2006 03:36:09 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
2.6.19 release is affected too
Please don't top-post.
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which
kernel
version were you using previously (the one which didn't do this)?
Possibly some ioctl got removed. I don't know why it would only occur
within a chrooted environment.
Possibly one could work out what's going on by reverse-engineering x86_64
ioctl command 0x82187201, but unfortunately I don't have time to do that.
Also unfortunately there appears to be an assumption that unless I
personally can immediately and straightforwardly identify a bug-owner, I
personally own the bug. The best I can suggest is that you raise a report
at bugzilla.kernel.org so this issue gets ignored in a more organised
fashion.
Sorry.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Sun, 2006-11-26 at 19:52 +, Alistair John Strachan wrote:
> On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
> > On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > > On Wed, 22 Nov 2006 15:29:02 +0100
> > >
> > > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> > > > it appears some sort of bug has gotten into .19, in regards to x86
> > > > emulation on x86_64.
> > > >
> > > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > > dmesg:
> > > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > > arg(00221000) on /home/redeeman
> > > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> > >
> > > Try
> > >
> > > echo 0 > /proc/sys/kernel/compat-log
> > >
> > > I don't _think_ we did anything to change the logging in there. Which
> > > kernel version were you using previously (the one which didn't do this)?
> >
> > it just struck me, that this may be the same bug Jesper Juhl has
> > discovered (atleast the hardlock part), as i read that thread, it strike
> > me that whenever i have hardlocks from this, its when i in wine runs
> > stuff that uses basically all my ram, and MAY even touch my swap.
>
> I see this same ioctl32 warning on a few apps running inside Wine, but I've
> not had any hard locks. On the contrary, everything works fine.
thats why i have come to suspect it may not be the ioctl thing that
causes the hardlocks, as i read that other thread
>
> I guess it would be nice to know which ioctl it is that doesn't have a compat
> wrapper on x86-64, 82187201 is a bit cryptic.
yes, it did not say these things on .18 :)
how do i get more verbose information on what exactly it is?
>
> HTH.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> >
> > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > >
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> >
> > Try
> >
> > echo 0 > /proc/sys/kernel/compat-log
> >
> > I don't _think_ we did anything to change the logging in there. Which
> > kernel version were you using previously (the one which didn't do this)?
>
> it just struck me, that this may be the same bug Jesper Juhl has
> discovered (atleast the hardlock part), as i read that thread, it strike
> me that whenever i have hardlocks from this, its when i in wine runs
> stuff that uses basically all my ram, and MAY even touch my swap.
I see this same ioctl32 warning on a few apps running inside Wine, but I've
not had any hard locks. On the contrary, everything works fine.
I guess it would be nice to know which ioctl it is that doesn't have a compat
wrapper on x86-64, 82187201 is a bit cryptic.
HTH.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> >
> > i have only tested with >=rc5, thw folling, as an example, appears in
> > dmesg:
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
>
> Try
>
> echo 0 > /proc/sys/kernel/compat-log
>
> I don't _think_ we did anything to change the logging in there. Which kernel
> version were you using previously (the one which didn't do this)?
>
it just struck me, that this may be the same bug Jesper Juhl has
discovered (atleast the hardlock part), as i read that thread, it strike
me that whenever i have hardlocks from this, its when i in wine runs
stuff that uses basically all my ram, and MAY even touch my swap.
just an idea.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> >
> > i have only tested with >=rc5, thw folling, as an example, appears in
> > dmesg:
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
>
> Try
>
> echo 0 > /proc/sys/kernel/compat-log
>
this appears to make the logging stop, however, it still acts somewhat
weird, and i am somewhat certain its because of this. this appears to be
able to cause hardlocks.
> I don't _think_ we did anything to change the logging in there. Which kernel
> version were you using previously (the one which didn't do this)?
.18
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
this appears to make the logging stop, however, it still acts somewhat
weird, and i am somewhat certain its because of this. this appears to be
able to cause hardlocks.
I don't _think_ we did anything to change the logging in there. Which kernel
version were you using previously (the one which didn't do this)?
.18
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which kernel
version were you using previously (the one which didn't do this)?
it just struck me, that this may be the same bug Jesper Juhl has
discovered (atleast the hardlock part), as i read that thread, it strike
me that whenever i have hardlocks from this, its when i in wine runs
stuff that uses basically all my ram, and MAY even touch my swap.
just an idea.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which
kernel version were you using previously (the one which didn't do this)?
it just struck me, that this may be the same bug Jesper Juhl has
discovered (atleast the hardlock part), as i read that thread, it strike
me that whenever i have hardlocks from this, its when i in wine runs
stuff that uses basically all my ram, and MAY even touch my swap.
I see this same ioctl32 warning on a few apps running inside Wine, but I've
not had any hard locks. On the contrary, everything works fine.
I guess it would be nice to know which ioctl it is that doesn't have a compat
wrapper on x86-64, 82187201 is a bit cryptic.
HTH.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Sun, 2006-11-26 at 19:52 +, Alistair John Strachan wrote:
On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which
kernel version were you using previously (the one which didn't do this)?
it just struck me, that this may be the same bug Jesper Juhl has
discovered (atleast the hardlock part), as i read that thread, it strike
me that whenever i have hardlocks from this, its when i in wine runs
stuff that uses basically all my ram, and MAY even touch my swap.
I see this same ioctl32 warning on a few apps running inside Wine, but I've
not had any hard locks. On the contrary, everything works fine.
thats why i have come to suspect it may not be the ioctl thing that
causes the hardlocks, as i read that other thread
I guess it would be nice to know which ioctl it is that doesn't have a compat
wrapper on x86-64, 82187201 is a bit cryptic.
yes, it did not say these things on .18 :)
how do i get more verbose information on what exactly it is?
HTH.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
