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?
>
>
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
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
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
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
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.
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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-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
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
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-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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
52 matches
Mail list logo
