Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[John Doe]

On 20/10/2015 16:27, Boris Ostrovsky wrote:
> On 10/20/2015 09:43 AM, Jan Beulich wrote:
> On 20.10.15 at 15:22,  wrote:
>>> The reason I think its this commit is that RAX, RDX and RCX look very
>>> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
>>> and RAX value is 0x1f, which has two new bits that this commit defined.
>> That would be the two MPX related bits, yet us (luckily) white listing
>> leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
>> this feature to PV(H) guests.
> 
> Oh, so something like
> 
> cpuid=['0x7:ebx=x0xx']
> 
> (bit 14 as zero) for John to try then.
> 
> 
> -boris
> 
>> Sadly the story is different for HVM
>> guests (where the leaf handling uses black listing), but the register
>> dump here clearly points to a PV guest (or Dom0).
>>
>> Jan
>>
> 
Jan the dump is taken from serial connection to Dom0, it does crash
during boot.

I just tried with xen 4.6.0 and it booted properly without xsave=0.
Running gdb against /proc/kcore, with a x/10x 0x81d58fad i just
get null bytes, with both xen4.4.3 (xsave=0) and 4.6.0.
Tomorrow i will send you the gdb output and i will try to run it during
the boot process.

J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Jan Beulich]

>>> On 20.10.15 at 16:27,  wrote:
> On 10/20/2015 09:43 AM, Jan Beulich wrote:
> On 20.10.15 at 15:22,  wrote:
>>> The reason I think its this commit is that RAX, RDX and RCX look very
>>> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
>>> and RAX value is 0x1f, which has two new bits that this commit defined.
>> That would be the two MPX related bits, yet us (luckily) white listing
>> leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
>> this feature to PV(H) guests.
> 
> Oh, so something like
> 
> cpuid=['0x7:ebx=x0xx']
> 
> (bit 14 as zero) for John to try then.

He might try it, but as per what I've said this shouldn't make a
difference for PV(H) guests.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Boris Ostrovsky]

On 10/20/2015 09:43 AM, Jan Beulich wrote:

On 20.10.15 at 15:22,  wrote:

The reason I think its this commit is that RAX, RDX and RCX look very
much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
and RAX value is 0x1f, which has two new bits that this commit defined.

That would be the two MPX related bits, yet us (luckily) white listing
leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
this feature to PV(H) guests.


Oh, so something like

cpuid=['0x7:ebx=x0xx']

(bit 14 as zero) for John to try then.


-boris


Sadly the story is different for HVM
guests (where the leaf handling uses black listing), but the register
dump here clearly points to a PV guest (or Dom0).

Jan



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Jan Beulich]

>>> On 20.10.15 at 15:22,  wrote:
> The reason I think its this commit is that RAX, RDX and RCX look very 
> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) 
> and RAX value is 0x1f, which has two new bits that this commit defined.

That would be the two MPX related bits, yet us (luckily) white listing
leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
this feature to PV(H) guests. Sadly the story is different for HVM
guests (where the leaf handling uses black listing), but the register
dump here clearly points to a PV guest (or Dom0).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Boris Ostrovsky]

On 10/20/2015 08:11 AM, John Doe wrote:

On 20/10/2015 11:51, Jan Beulich wrote:

On 19.10.15 at 18:25,  wrote:

On 10/19/2015 06:16 AM, John Doe wrote:

[0.00] general protection fault:  [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted

4.1.9-6.pvops.qubes.x86_64 #1

[0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By

O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015

[0.00] task: 81c154c0 ti: 81c0 task.ti:

81c0

[0.00] RIP: e030:[]  []

xstate_enable_boot_cpu+0xde/0x288

[0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
[0.00] RAX: 001f RBX: 0008 RCX:



[0.00] RDX:  RSI: 001f RDI:

00042660


It would be good to see what's at 81d58fad. My guess would be
that it's xsetbv.

If it is then you probably want to make sure you are running hypervisor
that has commit e8121c54 ("x86/xsave: enable support for new ISA
extensions"). Looks like the first version that has it is 4.5 and you
seem to be running 4.4.2.

Copying Jan to see if there are plans to backport this (probably not
since it's a new feature).


Hmm, if there are features getting exposed that lead to crashes like
this, then while we wouldn't normally backport enhancements, we
may need to consider adding a one-off patch to hide respective
features to that stable branch. But first we of course need to
understand what is going on here.



The reason I think its this commit is that RAX, RDX and RCX look very 
much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) 
and RAX value is 0x1f, which has two new bits that this commit defined.


With this being a new processor (Skylake) it would be logical to have 
these bits provided by CPUID.




Jan



I will try with 4.6.0 asap, unfortunately the 4.4.2 image i have is not
built with debug enabled and i'm unable to run gdb at boot, i'm building
a new one right now.


You should be able to use 'gdb /proc/kcore' and look at the instruction 
at (and around) 0x81d58fad.



If you need anything else please be very step-specific since i'm not
very practical at this.


You can also try adding
cpuid=['0xd,0:eax=0111']
to your config file and see if it helps.


-boris



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[John Doe]

On 20/10/2015 11:51, Jan Beulich wrote:
 On 19.10.15 at 18:25,  wrote:
>> On 10/19/2015 06:16 AM, John Doe wrote:
> [0.00] general protection fault:  [#1] SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
>> 4.1.9-6.pvops.qubes.x86_64 #1
> [0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By 
>> O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015
> [0.00] task: 81c154c0 ti: 81c0 task.ti: 
>> 81c0
> [0.00] RIP: e030:[]  [] 
>> xstate_enable_boot_cpu+0xde/0x288
> [0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
> [0.00] RAX: 001f RBX: 0008 RCX: 
>> 
> [0.00] RDX:  RSI: 001f RDI: 
>> 00042660
>>
>>
>> It would be good to see what's at 81d58fad. My guess would be 
>> that it's xsetbv.
>>
>> If it is then you probably want to make sure you are running hypervisor 
>> that has commit e8121c54 ("x86/xsave: enable support for new ISA 
>> extensions"). Looks like the first version that has it is 4.5 and you 
>> seem to be running 4.4.2.
>>
>> Copying Jan to see if there are plans to backport this (probably not 
>> since it's a new feature).
> 
> Hmm, if there are features getting exposed that lead to crashes like
> this, then while we wouldn't normally backport enhancements, we
> may need to consider adding a one-off patch to hide respective
> features to that stable branch. But first we of course need to
> understand what is going on here.
> 
> Jan
> 

I will try with 4.6.0 asap, unfortunately the 4.4.2 image i have is not
built with debug enabled and i'm unable to run gdb at boot, i'm building
a new one right now.
If you need anything else please be very step-specific since i'm not
very practical at this.

Thank you,
John.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Jan Beulich]

>>> On 19.10.15 at 18:25,  wrote:
> On 10/19/2015 06:16 AM, John Doe wrote:
 [0.00] general protection fault:  [#1] SMP
 [0.00] Modules linked in:
 [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> 4.1.9-6.pvops.qubes.x86_64 #1
 [0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By 
> O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015
 [0.00] task: 81c154c0 ti: 81c0 task.ti: 
> 81c0
 [0.00] RIP: e030:[]  [] 
> xstate_enable_boot_cpu+0xde/0x288
 [0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
 [0.00] RAX: 001f RBX: 0008 RCX: 
> 
 [0.00] RDX:  RSI: 001f RDI: 
> 00042660
> 
> 
> It would be good to see what's at 81d58fad. My guess would be 
> that it's xsetbv.
> 
> If it is then you probably want to make sure you are running hypervisor 
> that has commit e8121c54 ("x86/xsave: enable support for new ISA 
> extensions"). Looks like the first version that has it is 4.5 and you 
> seem to be running 4.4.2.
> 
> Copying Jan to see if there are plans to backport this (probably not 
> since it's a new feature).

Hmm, if there are features getting exposed that lead to crashes like
this, then while we wouldn't normally backport enhancements, we
may need to consider adding a one-off patch to hide respective
features to that stable branch. But first we of course need to
understand what is going on here.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Jan Beulich]

>>> On 19.10.15 at 18:25,  wrote:
> On 10/19/2015 06:16 AM, John Doe wrote:
 [0.00] general protection fault:  [#1] SMP
 [0.00] Modules linked in:
 [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> 4.1.9-6.pvops.qubes.x86_64 #1
 [0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By 
> O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015
 [0.00] task: 81c154c0 ti: 81c0 task.ti: 
> 81c0
 [0.00] RIP: e030:[]  [] 
> xstate_enable_boot_cpu+0xde/0x288
 [0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
 [0.00] RAX: 001f RBX: 0008 RCX: 
> 
 [0.00] RDX:  RSI: 001f RDI: 
> 00042660
> 
> 
> It would be good to see what's at 81d58fad. My guess would be 
> that it's xsetbv.
> 
> If it is then you probably want to make sure you are running hypervisor 
> that has commit e8121c54 ("x86/xsave: enable support for new ISA 
> extensions"). Looks like the first version that has it is 4.5 and you 
> seem to be running 4.4.2.
> 
> Copying Jan to see if there are plans to backport this (probably not 
> since it's a new feature).

Hmm, if there are features getting exposed that lead to crashes like
this, then while we wouldn't normally backport enhancements, we
may need to consider adding a one-off patch to hide respective
features to that stable branch. But first we of course need to
understand what is going on here.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[John Doe]

On 20/10/2015 11:51, Jan Beulich wrote:
 On 19.10.15 at 18:25,  wrote:
>> On 10/19/2015 06:16 AM, John Doe wrote:
> [0.00] general protection fault:  [#1] SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
>> 4.1.9-6.pvops.qubes.x86_64 #1
> [0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By 
>> O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015
> [0.00] task: 81c154c0 ti: 81c0 task.ti: 
>> 81c0
> [0.00] RIP: e030:[]  [] 
>> xstate_enable_boot_cpu+0xde/0x288
> [0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
> [0.00] RAX: 001f RBX: 0008 RCX: 
>> 
> [0.00] RDX:  RSI: 001f RDI: 
>> 00042660
>>
>>
>> It would be good to see what's at 81d58fad. My guess would be 
>> that it's xsetbv.
>>
>> If it is then you probably want to make sure you are running hypervisor 
>> that has commit e8121c54 ("x86/xsave: enable support for new ISA 
>> extensions"). Looks like the first version that has it is 4.5 and you 
>> seem to be running 4.4.2.
>>
>> Copying Jan to see if there are plans to backport this (probably not 
>> since it's a new feature).
> 
> Hmm, if there are features getting exposed that lead to crashes like
> this, then while we wouldn't normally backport enhancements, we
> may need to consider adding a one-off patch to hide respective
> features to that stable branch. But first we of course need to
> understand what is going on here.
> 
> Jan
> 

I will try with 4.6.0 asap, unfortunately the 4.4.2 image i have is not
built with debug enabled and i'm unable to run gdb at boot, i'm building
a new one right now.
If you need anything else please be very step-specific since i'm not
very practical at this.

Thank you,
John.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Jan Beulich]

>>> On 20.10.15 at 16:27,  wrote:
> On 10/20/2015 09:43 AM, Jan Beulich wrote:
> On 20.10.15 at 15:22,  wrote:
>>> The reason I think its this commit is that RAX, RDX and RCX look very
>>> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
>>> and RAX value is 0x1f, which has two new bits that this commit defined.
>> That would be the two MPX related bits, yet us (luckily) white listing
>> leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
>> this feature to PV(H) guests.
> 
> Oh, so something like
> 
> cpuid=['0x7:ebx=x0xx']
> 
> (bit 14 as zero) for John to try then.

He might try it, but as per what I've said this shouldn't make a
difference for PV(H) guests.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Boris Ostrovsky]

On 10/20/2015 09:43 AM, Jan Beulich wrote:

On 20.10.15 at 15:22,  wrote:

The reason I think its this commit is that RAX, RDX and RCX look very
much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
and RAX value is 0x1f, which has two new bits that this commit defined.

That would be the two MPX related bits, yet us (luckily) white listing
leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
this feature to PV(H) guests.


Oh, so something like

cpuid=['0x7:ebx=x0xx']

(bit 14 as zero) for John to try then.


-boris


Sadly the story is different for HVM
guests (where the leaf handling uses black listing), but the register
dump here clearly points to a PV guest (or Dom0).

Jan



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[John Doe]

On 20/10/2015 16:27, Boris Ostrovsky wrote:
> On 10/20/2015 09:43 AM, Jan Beulich wrote:
> On 20.10.15 at 15:22,  wrote:
>>> The reason I think its this commit is that RAX, RDX and RCX look very
>>> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
>>> and RAX value is 0x1f, which has two new bits that this commit defined.
>> That would be the two MPX related bits, yet us (luckily) white listing
>> leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
>> this feature to PV(H) guests.
> 
> Oh, so something like
> 
> cpuid=['0x7:ebx=x0xx']
> 
> (bit 14 as zero) for John to try then.
> 
> 
> -boris
> 
>> Sadly the story is different for HVM
>> guests (where the leaf handling uses black listing), but the register
>> dump here clearly points to a PV guest (or Dom0).
>>
>> Jan
>>
> 
Jan the dump is taken from serial connection to Dom0, it does crash
during boot.

I just tried with xen 4.6.0 and it booted properly without xsave=0.
Running gdb against /proc/kcore, with a x/10x 0x81d58fad i just
get null bytes, with both xen4.4.3 (xsave=0) and 4.6.0.
Tomorrow i will send you the gdb output and i will try to run it during
the boot process.

J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Boris Ostrovsky]

On 10/20/2015 08:11 AM, John Doe wrote:

On 20/10/2015 11:51, Jan Beulich wrote:

On 19.10.15 at 18:25,  wrote:

On 10/19/2015 06:16 AM, John Doe wrote:

[0.00] general protection fault:  [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted

4.1.9-6.pvops.qubes.x86_64 #1

[0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By

O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015

[0.00] task: 81c154c0 ti: 81c0 task.ti:

81c0

[0.00] RIP: e030:[]  []

xstate_enable_boot_cpu+0xde/0x288

[0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
[0.00] RAX: 001f RBX: 0008 RCX:



[0.00] RDX:  RSI: 001f RDI:

00042660


It would be good to see what's at 81d58fad. My guess would be
that it's xsetbv.

If it is then you probably want to make sure you are running hypervisor
that has commit e8121c54 ("x86/xsave: enable support for new ISA
extensions"). Looks like the first version that has it is 4.5 and you
seem to be running 4.4.2.

Copying Jan to see if there are plans to backport this (probably not
since it's a new feature).


Hmm, if there are features getting exposed that lead to crashes like
this, then while we wouldn't normally backport enhancements, we
may need to consider adding a one-off patch to hide respective
features to that stable branch. But first we of course need to
understand what is going on here.



The reason I think its this commit is that RAX, RDX and RCX look very 
much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) 
and RAX value is 0x1f, which has two new bits that this commit defined.


With this being a new processor (Skylake) it would be logical to have 
these bits provided by CPUID.




Jan



I will try with 4.6.0 asap, unfortunately the 4.4.2 image i have is not
built with debug enabled and i'm unable to run gdb at boot, i'm building
a new one right now.


You should be able to use 'gdb /proc/kcore' and look at the instruction 
at (and around) 0x81d58fad.



If you need anything else please be very step-specific since i'm not
very practical at this.


You can also try adding
cpuid=['0xd,0:eax=0111']
to your config file and see if it helps.


-boris



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Jan Beulich]

>>> On 20.10.15 at 15:22,  wrote:
> The reason I think its this commit is that RAX, RDX and RCX look very 
> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) 
> and RAX value is 0x1f, which has two new bits that this commit defined.

That would be the two MPX related bits, yet us (luckily) white listing
leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose
this feature to PV(H) guests. Sadly the story is different for HVM
guests (where the leaf handling uses black listing), but the register
dump here clearly points to a PV guest (or Dom0).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Boris Ostrovsky]

On 10/19/2015 06:16 AM, John Doe wrote:

[0.00] general protection fault:  [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.1.9-6.pvops.qubes.x86_64 #1
[0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015
[0.00] task: 81c154c0 ti: 81c0 task.ti: 
81c0
[0.00] RIP: e030:[]  [] 
xstate_enable_boot_cpu+0xde/0x288
[0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
[0.00] RAX: 001f RBX: 0008 RCX: 
[0.00] RDX:  RSI: 001f RDI: 00042660



It would be good to see what's at 81d58fad. My guess would be 
that it's xsetbv.


If it is then you probably want to make sure you are running hypervisor 
that has commit e8121c54 ("x86/xsave: enable support for new ISA 
extensions"). Looks like the first version that has it is 4.5 and you 
seem to be running 4.4.2.


Copying Jan to see if there are plans to backport this (probably not 
since it's a new feature).


-boris



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: kernel panic xsave_init

[John Doe]

On 19/10/2015 09:56, Ingo Molnar wrote:
> 
> Please Cc: the Xen maintainers as this appears to be Xen specific. Also, 
> please 
> Cc: linux-kernel@vger.kernel.org.
> 
> Thanks,
> 
>   Ingo
> 
> * John Doe  wrote:
> 
>> Hello,
>> I get a kernel panic on QubesOS 3.0 during boot with kernels newer than
>> 3.12.40-2, i tried several versions until the latest 4.3.0-rc5. It does
>> boot properly with xsave=0 parameter.
>> I attached the full console log with the stack trace.
>>
>> My machine runs a new i7-6700k skylake CPU on z170 chipset.
>>
>> I hope it can help.
>>
>> John.
>>
>>
>>
> 
>> about to get started...
>> [0.00] PAT configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC  
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpu
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 4.1.9-6.pvops.qubes.x86_64 (user@release) (gcc 
>> version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Sat Oct 3 02:28:05 
>> UTC 2015
>> [0.00] Command line: placeholder root=/dev/mapper/qubes_dom0-root ro 
>> console=tty0 console=ttyS0,115200n8 rd.lvm.lv=qubes_dom0/root 
>> rd.luks.uuid=luks-nope
>> [0.00] Released 0 page(s)
>> [0.00] e820: BIOS-provided physical RAM map:
>> [0.00] Xen: [mem 0x-0x0009bfff] usable
>> [0.00] Xen: [mem 0x0009c800-0x000f] reserved
>> [0.00] Xen: [mem 0x0010-0x59f9afff] usable
>> [0.00] Xen: [mem 0x59f9b000-0x59f9bfff] ACPI NVS
>> [0.00] Xen: [mem 0x59f9c000-0x59fe5fff] reserved
>> [0.00] Xen: [mem 0x59fe6000-0x5a038fff] usable
>> [0.00] Xen: [mem 0x5a039000-0x5a75afff] reserved
>> [0.00] Xen: [mem 0x5a75b000-0x66b92fff] usable
>> [0.00] Xen: [mem 0x66b93000-0x677aafff] reserved
>> [0.00] Xen: [mem 0x677ab000-0x67f99fff] ACPI NVS
>> [0.00] Xen: [mem 0x67f9a000-0x67ffefff] ACPI data
>> [0.00] Xen: [mem 0x67fff000-0x67ff] usable
>> [0.00] Xen: [mem 0x6800-0x680f] reserved
>> [0.00] Xen: [mem 0xe000-0xefff] reserved
>> [0.00] Xen: [mem 0xfe00-0xfe010fff] reserved
>> [0.00] Xen: [mem 0xfec0-0xfec00fff] reserved
>> [0.00] Xen: [mem 0xfed9-0xfed91fff] reserved
>> [0.00] Xen: [mem 0xfee0-0xfeef] reserved
>> [0.00] Xen: [mem 0xff00-0x] reserved
>> [0.00] Xen: [mem 0x0001-0x000891ff] usable
>> [0.00] bootconsole [xenboot0] enabled
>> [0.00] NX (Execute Disable) protection: active
>> [0.00] SMBIOS 2.8 present.
>> [0.00] Hypervisor detected: Xen
>> [0.00] e820: last_pfn = 0x892000 max_arch_pfn = 0x4
>> [0.00] e820: last_pfn = 0x68000 max_arch_pfn = 0x4
>> [0.00] init_memory_mapping: [mem 0x-0x000f]
>> [0.00] init_memory_mapping: [mem 0x7d520-0x7d53f]
>> [0.00] init_memory_mapping: [mem 0x7c000-0x7d51f]
>> [0.00] init_memory_mapping: [mem 0x7a000-0x7bfff]
>> [0.00] init_memory_mapping: [mem 0x0010-0x59f9afff]
>> [0.00] init_memory_mapping: [mem 0x59fe6000-0x5a038fff]
>> [0.00] init_memory_mapping: [mem 0x5a75b000-0x66b92fff]
>> [0.00] init_memory_mapping: [mem 0x67fff000-0x67ff]
>> [0.00] init_memory_mapping: [mem 0x1-0x79fff]
>> [0.00] init_memory_mapping: [mem 0x7d540-0x891ff]
>> [0.00] RAMDISK: [mem 0x0800-0x0a815fff]
>> [0.00] ACPI: Early table checksum verification disabled
>> [0.00] ACPI: RSDP 0x000F05B0 24 (v02 ALASKA)
>> [0.00] ACPI: XSDT 0x67A1F098 B4 (v01 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: FACP 0x67A41B30 00010C (v05 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI BIOS Warning (bug): Incorrect checksum in table [FACP] - 
>> 0x15, should be 0x49 (20150410/tbprint-211)
>> [0.00] ACPI: DSDT 0x67A1F1E8 022943 (v02 ALASKA A M I
>> 01072009 INTL 20120913)
>> [0.00] ACPI: FACS 0x67F99F80 40
>> [0.00] ACPI: APIC 0x67A41C40 BC (v03 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: FPDT 0x67A41D00 44 (v01 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: FIDT 0x67A41D48 9C (v01 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: MCFG 0x67A41DE8 3C (v01 ALASKA A M I
>> 01072009 MSFT 0097)
>> [0.00] ACPI: HPET 0x67A41E28 38 (v01 ALASKA A M I
>> 01072009 

Re: PROBLEM: kernel panic xsave_init

[John Doe]

On 19/10/2015 09:56, Ingo Molnar wrote:
> 
> Please Cc: the Xen maintainers as this appears to be Xen specific. Also, 
> please 
> Cc: linux-kernel@vger.kernel.org.
> 
> Thanks,
> 
>   Ingo
> 
> * John Doe  wrote:
> 
>> Hello,
>> I get a kernel panic on QubesOS 3.0 during boot with kernels newer than
>> 3.12.40-2, i tried several versions until the latest 4.3.0-rc5. It does
>> boot properly with xsave=0 parameter.
>> I attached the full console log with the stack trace.
>>
>> My machine runs a new i7-6700k skylake CPU on z170 chipset.
>>
>> I hope it can help.
>>
>> John.
>>
>>
>>
> 
>> about to get started...
>> [0.00] PAT configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC  
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpu
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 4.1.9-6.pvops.qubes.x86_64 (user@release) (gcc 
>> version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Sat Oct 3 02:28:05 
>> UTC 2015
>> [0.00] Command line: placeholder root=/dev/mapper/qubes_dom0-root ro 
>> console=tty0 console=ttyS0,115200n8 rd.lvm.lv=qubes_dom0/root 
>> rd.luks.uuid=luks-nope
>> [0.00] Released 0 page(s)
>> [0.00] e820: BIOS-provided physical RAM map:
>> [0.00] Xen: [mem 0x-0x0009bfff] usable
>> [0.00] Xen: [mem 0x0009c800-0x000f] reserved
>> [0.00] Xen: [mem 0x0010-0x59f9afff] usable
>> [0.00] Xen: [mem 0x59f9b000-0x59f9bfff] ACPI NVS
>> [0.00] Xen: [mem 0x59f9c000-0x59fe5fff] reserved
>> [0.00] Xen: [mem 0x59fe6000-0x5a038fff] usable
>> [0.00] Xen: [mem 0x5a039000-0x5a75afff] reserved
>> [0.00] Xen: [mem 0x5a75b000-0x66b92fff] usable
>> [0.00] Xen: [mem 0x66b93000-0x677aafff] reserved
>> [0.00] Xen: [mem 0x677ab000-0x67f99fff] ACPI NVS
>> [0.00] Xen: [mem 0x67f9a000-0x67ffefff] ACPI data
>> [0.00] Xen: [mem 0x67fff000-0x67ff] usable
>> [0.00] Xen: [mem 0x6800-0x680f] reserved
>> [0.00] Xen: [mem 0xe000-0xefff] reserved
>> [0.00] Xen: [mem 0xfe00-0xfe010fff] reserved
>> [0.00] Xen: [mem 0xfec0-0xfec00fff] reserved
>> [0.00] Xen: [mem 0xfed9-0xfed91fff] reserved
>> [0.00] Xen: [mem 0xfee0-0xfeef] reserved
>> [0.00] Xen: [mem 0xff00-0x] reserved
>> [0.00] Xen: [mem 0x0001-0x000891ff] usable
>> [0.00] bootconsole [xenboot0] enabled
>> [0.00] NX (Execute Disable) protection: active
>> [0.00] SMBIOS 2.8 present.
>> [0.00] Hypervisor detected: Xen
>> [0.00] e820: last_pfn = 0x892000 max_arch_pfn = 0x4
>> [0.00] e820: last_pfn = 0x68000 max_arch_pfn = 0x4
>> [0.00] init_memory_mapping: [mem 0x-0x000f]
>> [0.00] init_memory_mapping: [mem 0x7d520-0x7d53f]
>> [0.00] init_memory_mapping: [mem 0x7c000-0x7d51f]
>> [0.00] init_memory_mapping: [mem 0x7a000-0x7bfff]
>> [0.00] init_memory_mapping: [mem 0x0010-0x59f9afff]
>> [0.00] init_memory_mapping: [mem 0x59fe6000-0x5a038fff]
>> [0.00] init_memory_mapping: [mem 0x5a75b000-0x66b92fff]
>> [0.00] init_memory_mapping: [mem 0x67fff000-0x67ff]
>> [0.00] init_memory_mapping: [mem 0x1-0x79fff]
>> [0.00] init_memory_mapping: [mem 0x7d540-0x891ff]
>> [0.00] RAMDISK: [mem 0x0800-0x0a815fff]
>> [0.00] ACPI: Early table checksum verification disabled
>> [0.00] ACPI: RSDP 0x000F05B0 24 (v02 ALASKA)
>> [0.00] ACPI: XSDT 0x67A1F098 B4 (v01 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: FACP 0x67A41B30 00010C (v05 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI BIOS Warning (bug): Incorrect checksum in table [FACP] - 
>> 0x15, should be 0x49 (20150410/tbprint-211)
>> [0.00] ACPI: DSDT 0x67A1F1E8 022943 (v02 ALASKA A M I
>> 01072009 INTL 20120913)
>> [0.00] ACPI: FACS 0x67F99F80 40
>> [0.00] ACPI: APIC 0x67A41C40 BC (v03 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: FPDT 0x67A41D00 44 (v01 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: FIDT 0x67A41D48 9C (v01 ALASKA A M I
>> 01072009 AMI  00010013)
>> [0.00] ACPI: MCFG 0x67A41DE8 3C (v01 ALASKA A M I
>> 01072009 MSFT 0097)
>> [0.00] ACPI: HPET 0x67A41E28 38 (v01 ALASKA A 

Re: [Xen-devel] PROBLEM: kernel panic xsave_init

[Boris Ostrovsky]

On 10/19/2015 06:16 AM, John Doe wrote:

[0.00] general protection fault:  [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.1.9-6.pvops.qubes.x86_64 #1
[0.00] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015
[0.00] task: 81c154c0 ti: 81c0 task.ti: 
81c0
[0.00] RIP: e030:[]  [] 
xstate_enable_boot_cpu+0xde/0x288
[0.00] RSP: e02b:81c03de8  EFLAGS: 00010046
[0.00] RAX: 001f RBX: 0008 RCX: 
[0.00] RDX:  RSI: 001f RDI: 00042660



It would be good to see what's at 81d58fad. My guess would be 
that it's xsetbv.


If it is then you probably want to make sure you are running hypervisor 
that has commit e8121c54 ("x86/xsave: enable support for new ISA 
extensions"). Looks like the first version that has it is 4.5 and you 
seem to be running 4.4.2.


Copying Jan to see if there are plans to backport this (probably not 
since it's a new feature).


-boris



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: kernel panic

[Scott Petler]

Ok, I'll do that
Thanks

Sent from my iPhone

On Oct 14, 2007, at 2:32 PM, Trond Myklebust  
<[EMAIL PROTECTED]> wrote:




On Sun, 2007-10-14 at 14:00 -0700, Scott Petler wrote:

Doug,

I thought that might do it, it does seem to work.  I edited the  
driver

line in my xorg.conf
from nvidia to nv and then,
 F1
login as root
/etc/init.d/gdm stop
/etc/init.d/gdm start

It came back up with the same flashing crap on the second monitor,  
so I

did it again with
the 2nd monitor turned off altogether, and I'll see how long it  
will run

on the single monitor
without the nvidia driver without crashing (maybe forever...).

Thanks,
Scott


Please don't forget to reboot, though. The kernel will remain tainted
until you've rebooted without loading the nvidia module.

Cheers
 Trond


-
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: PROBLEM: kernel panic

[Trond Myklebust]

On Sun, 2007-10-14 at 14:00 -0700, Scott Petler wrote:
> Doug,
> 
> I thought that might do it, it does seem to work.  I edited the driver 
> line in my xorg.conf
> from nvidia to nv and then,
>  F1
> login as root
> /etc/init.d/gdm stop
> /etc/init.d/gdm start
> 
> It came back up with the same flashing crap on the second monitor, so I 
> did it again with
> the 2nd monitor turned off altogether, and I'll see how long it will run 
> on the single monitor
> without the nvidia driver without crashing (maybe forever...).
> 
> Thanks, 
> Scott

Please don't forget to reboot, though. The kernel will remain tainted
until you've rebooted without loading the nvidia module.

Cheers
  Trond

-
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: PROBLEM: kernel panic

[Scott Petler]

Doug,

I thought that might do it, it does seem to work.  I edited the driver 
line in my xorg.conf

from nvidia to nv and then,
 F1
login as root
/etc/init.d/gdm stop
/etc/init.d/gdm start

It came back up with the same flashing crap on the second monitor, so I 
did it again with
the 2nd monitor turned off altogether, and I'll see how long it will run 
on the single monitor

without the nvidia driver without crashing (maybe forever...).

Thanks,
Scott

Doug Whitesell (LKML) wrote:

On Oct 14, 2007, at 1:44 PM, Scott Petler wrote:


Trond,

I'm not exactly sure how to go back to not using the nvidia driver 
and select the xorg one.  I do know that I wasn't able to use both 
monitors with the xorg driver, but I'm willing to try that to isolate 
the problem.


If memory serves, you change your xorg.conf's "Device" section's 
"Driver" entry to read:

"nv"
instead of
"nvidia",

although I would consult the xorg documentation/your distribution's 
documentation (and back up your working xorg.conf) for specific 
details. (Your boot sequence may also automatically load the nvidia 
module, again, consult your distribution's documentation for details.)


Cheers/hope this helps,
dcw



-
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: PROBLEM: kernel panic

[Doug Whitesell (LKML)]

On Oct 14, 2007, at 1:44 PM, Scott Petler wrote:


Trond,

I'm not exactly sure how to go back to not using the nvidia driver  
and select the xorg one.  I do know that I wasn't able to use both  
monitors with the xorg driver, but I'm willing to try that to  
isolate the problem.


If memory serves, you change your xorg.conf's "Device" section's  
"Driver" entry to read:

"nv"
instead of
"nvidia",

although I would consult the xorg documentation/your distribution's  
documentation (and back up your working xorg.conf) for specific  
details. (Your boot sequence may also automatically load the nvidia  
module, again, consult your distribution's documentation for details.)


Cheers/hope this helps,
dcw
-
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: PROBLEM: kernel panic

[Scott Petler]

Trond,

I'm not exactly sure how to go back to not using the nvidia driver and 
select the xorg one.  I do know that I wasn't able to use both monitors 
with the xorg driver, but I'm willing to try that to isolate the problem.


Scott

Output from /proc/mounts:
rootfs / rootfs rw 0 0
none /sys sysfs rw 0 0
none /proc proc rw 0 0
udev /dev tmpfs rw 0 0
/dev/sda2 / ext3 rw,data=ordered 0 0
/dev/sda2 /dev/.static/dev ext3 rw,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec 0 0
twin:/home /home nfs 
rw,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=twin 
0 0
twin:/mp3 /mp3 nfs 
rw,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=twin 
0 0



Trond Myklebust wrote:

On Sat, 2007-10-13 at 15:48 -0700, Scott Petler wrote:
  

Machine lockup with caps lock/num lock flashing or complete reboot/panic.

I get various lockup issues with this kernel, (2.6.23 also similar 
problem).   I had problems getting e1000 lan module to work (it was fine 
in 2.6.21.5).  I disabled it and installed a different lan card that 
seems to work "better".


Dual head machine 1GB RAM, nvidia driver x86-100.14.19



Are you able to repeat this Oops _without_ the nvidia driver?

Also, please provide the output from /proc/mounts

Cheers
  Trond


  

Here is output of ver_linux:
-

Linux zion 2.6.23-rc9 #3 Fri Oct 12 18:27:56 PDT 2007 i686 GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.3-pre2
e2fsprogs  1.40-WIP
Linux C Library3.6
Dynamic linker (ldd)   2.3.6
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
udev   105
Modules Loaded nfs lockd sunrpc nvidia i2c_core af_packet ipv6 
capability commoncap ppdev lp ac battery dm_mod e1000 loop snd_intel8x0 
snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
parport_pc button parport snd 8250_pnp 8250 serial_core soundcore shpchp 
pci_hotplug snd_page_alloc rng_core floppy intel_agp agpgart rtc sg 
evdev sr_mod usbhid sd_mod ata_piix 8139too ata_generic ehci_hcd 
uhci_hcd mii bitrev crc32 libata generic usbcore thermal processor fan 
unix ext3 jbd piix ide_disk ide_cd cdrom ide_scsi scsi_mod ide_core

-

Here is output from syslog as it went down:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Oops: 0002 [#1]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: CPU:0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP:0060:[]Tainted: PVLI

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EFLAGS: 00010206   (2.6.23-rc9 #3)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP is at 0xe1168fde

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: esi: f8f34700   edi:    ebp: 0001   esp: e7cf3e00

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Process firefox-bin (pid: 8397, ti=e7cf2000 task=f258ca90 
task.ti=e

7cf2000)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Stack: f8f18eb7 c01367f6 e7cf3e48 03e8 03e8 
ed3e97c0 f1f6db

9c f1f6db9c

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:e7cf3f54 f8f60ec2 0004257b   
f1f037dc e7cf3f

54 c01563d0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:019cc780 e7cf3eb0 c0155a63 dfff38c0 c014e001 
019cc780 f1f037

dc dfe0ecf4

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Call Trace:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] rpcauth_lookupcred+0x63/0x87 [sunrpc]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] pagevec_lookup+0x1c/0x22

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] nfs_permission+0xab/0x183 [nfs]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] __d_lookup+0x8b/0xbf

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] dput+0x15/0xcb

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] nfs_permission+0x0/0x183 [nfs]

Re: PROBLEM: kernel panic

[Trond Myklebust]

On Sat, 2007-10-13 at 15:48 -0700, Scott Petler wrote:
> Machine lockup with caps lock/num lock flashing or complete reboot/panic.
> 
> I get various lockup issues with this kernel, (2.6.23 also similar 
> problem).   I had problems getting e1000 lan module to work (it was fine 
> in 2.6.21.5).  I disabled it and installed a different lan card that 
> seems to work "better".
> 
> Dual head machine 1GB RAM, nvidia driver x86-100.14.19

Are you able to repeat this Oops _without_ the nvidia driver?

Also, please provide the output from /proc/mounts

Cheers
  Trond


> Here is output of ver_linux:
> -
> 
> Linux zion 2.6.23-rc9 #3 Fri Oct 12 18:27:56 PDT 2007 i686 GNU/Linux
> 
> Gnu C  4.1.2
> Gnu make   3.81
> binutils   2.17
> util-linux 2.12r
> mount  2.12r
> module-init-tools  3.3-pre2
> e2fsprogs  1.40-WIP
> Linux C Library3.6
> Dynamic linker (ldd)   2.3.6
> Procps 3.2.7
> Net-tools  1.60
> Console-tools  0.2.3
> Sh-utils   5.97
> udev   105
> Modules Loaded nfs lockd sunrpc nvidia i2c_core af_packet ipv6 
> capability commoncap ppdev lp ac battery dm_mod e1000 loop snd_intel8x0 
> snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
> parport_pc button parport snd 8250_pnp 8250 serial_core soundcore shpchp 
> pci_hotplug snd_page_alloc rng_core floppy intel_agp agpgart rtc sg 
> evdev sr_mod usbhid sd_mod ata_piix 8139too ata_generic ehci_hcd 
> uhci_hcd mii bitrev crc32 libata generic usbcore thermal processor fan 
> unix ext3 jbd piix ide_disk ide_cd cdrom ide_scsi scsi_mod ide_core
> -
> 
> Here is output from syslog as it went down:
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: Oops: 0002 [#1]
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: CPU:0
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: EIP:0060:[]Tainted: PVLI
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: EFLAGS: 00010206   (2.6.23-rc9 #3)
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: EIP is at 0xe1168fde
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: esi: f8f34700   edi:    ebp: 0001   esp: e7cf3e00
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: Process firefox-bin (pid: 8397, ti=e7cf2000 task=f258ca90 
> task.ti=e
> 7cf2000)
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: Stack: f8f18eb7 c01367f6 e7cf3e48 03e8 03e8 
> ed3e97c0 f1f6db
> 9c f1f6db9c
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:e7cf3f54 f8f60ec2 0004257b   
> f1f037dc e7cf3f
> 54 c01563d0
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:019cc780 e7cf3eb0 c0155a63 dfff38c0 c014e001 
> 019cc780 f1f037
> dc dfe0ecf4
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel: Call Trace:
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] rpcauth_lookupcred+0x63/0x87 [sunrpc]
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] pagevec_lookup+0x1c/0x22
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] nfs_permission+0xab/0x183 [nfs]
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] __d_lookup+0x8b/0xbf
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] dput+0x15/0xcb
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] nfs_permission+0x0/0x183 [nfs]
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] __link_path_walk+0x11c/0xa79
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] setup_sigcontext+0x104/0x187
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] link_path_walk+0x42/0xaf
> Read from remote host 192.168.1.175: Connection reset by peer
> Connection to 192.168.1.175 closed.
> 
> Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
> zion kernel:  [] permission+0x9e/0xdb
> 
> 
> 

Re: PROBLEM: kernel panic

[Trond Myklebust]

On Sat, 2007-10-13 at 15:48 -0700, Scott Petler wrote:
 Machine lockup with caps lock/num lock flashing or complete reboot/panic.
 
 I get various lockup issues with this kernel, (2.6.23 also similar 
 problem).   I had problems getting e1000 lan module to work (it was fine 
 in 2.6.21.5).  I disabled it and installed a different lan card that 
 seems to work better.
 
 Dual head machine 1GB RAM, nvidia driver x86-100.14.19

Are you able to repeat this Oops _without_ the nvidia driver?

Also, please provide the output from /proc/mounts

Cheers
  Trond


 Here is output of ver_linux:
 -
 
 Linux zion 2.6.23-rc9 #3 Fri Oct 12 18:27:56 PDT 2007 i686 GNU/Linux
 
 Gnu C  4.1.2
 Gnu make   3.81
 binutils   2.17
 util-linux 2.12r
 mount  2.12r
 module-init-tools  3.3-pre2
 e2fsprogs  1.40-WIP
 Linux C Library3.6
 Dynamic linker (ldd)   2.3.6
 Procps 3.2.7
 Net-tools  1.60
 Console-tools  0.2.3
 Sh-utils   5.97
 udev   105
 Modules Loaded nfs lockd sunrpc nvidia i2c_core af_packet ipv6 
 capability commoncap ppdev lp ac battery dm_mod e1000 loop snd_intel8x0 
 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
 parport_pc button parport snd 8250_pnp 8250 serial_core soundcore shpchp 
 pci_hotplug snd_page_alloc rng_core floppy intel_agp agpgart rtc sg 
 evdev sr_mod usbhid sd_mod ata_piix 8139too ata_generic ehci_hcd 
 uhci_hcd mii bitrev crc32 libata generic usbcore thermal processor fan 
 unix ext3 jbd piix ide_disk ide_cd cdrom ide_scsi scsi_mod ide_core
 -
 
 Here is output from syslog as it went down:
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: Oops: 0002 [#1]
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: CPU:0
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: EIP:0060:[e1168fde]Tainted: PVLI
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: EFLAGS: 00010206   (2.6.23-rc9 #3)
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: EIP is at 0xe1168fde
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: esi: f8f34700   edi:    ebp: 0001   esp: e7cf3e00
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: Process firefox-bin (pid: 8397, ti=e7cf2000 task=f258ca90 
 task.ti=e
 7cf2000)
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: Stack: f8f18eb7 c01367f6 e7cf3e48 03e8 03e8 
 ed3e97c0 f1f6db
 9c f1f6db9c
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:e7cf3f54 f8f60ec2 0004257b   
 f1f037dc e7cf3f
 54 c01563d0
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:019cc780 e7cf3eb0 c0155a63 dfff38c0 c014e001 
 019cc780 f1f037
 dc dfe0ecf4
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel: Call Trace:
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [f8f18eb7] rpcauth_lookupcred+0x63/0x87 [sunrpc]
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [c01367f6] pagevec_lookup+0x1c/0x22
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [f8f60ec2] nfs_permission+0xab/0x183 [nfs]
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [c01563d0] __d_lookup+0x8b/0xbf
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [c0155a63] dput+0x15/0xcb
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [f8f60e17] nfs_permission+0x0/0x183 [nfs]
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [c014f648] __link_path_walk+0x11c/0xa79
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [c0102ff8] setup_sigcontext+0x104/0x187
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [c014ffe7] link_path_walk+0x42/0xaf
 Read from remote host 192.168.1.175: Connection reset by peer
 Connection to 192.168.1.175 closed.
 
 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
 zion kernel:  [c014de5a] permission+0x9e/0xdb
 
 
 /proc/cpuinfo
 
 processor   : 

Re: PROBLEM: kernel panic

[Scott Petler]

Trond,

I'm not exactly sure how to go back to not using the nvidia driver and 
select the xorg one.  I do know that I wasn't able to use both monitors 
with the xorg driver, but I'm willing to try that to isolate the problem.


Scott

Output from /proc/mounts:
rootfs / rootfs rw 0 0
none /sys sysfs rw 0 0
none /proc proc rw 0 0
udev /dev tmpfs rw 0 0
/dev/sda2 / ext3 rw,data=ordered 0 0
/dev/sda2 /dev/.static/dev ext3 rw,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec 0 0
twin:/home /home nfs 
rw,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=twin 
0 0
twin:/mp3 /mp3 nfs 
rw,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=twin 
0 0



Trond Myklebust wrote:

On Sat, 2007-10-13 at 15:48 -0700, Scott Petler wrote:
  

Machine lockup with caps lock/num lock flashing or complete reboot/panic.

I get various lockup issues with this kernel, (2.6.23 also similar 
problem).   I had problems getting e1000 lan module to work (it was fine 
in 2.6.21.5).  I disabled it and installed a different lan card that 
seems to work better.


Dual head machine 1GB RAM, nvidia driver x86-100.14.19



Are you able to repeat this Oops _without_ the nvidia driver?

Also, please provide the output from /proc/mounts

Cheers
  Trond


  

Here is output of ver_linux:
-

Linux zion 2.6.23-rc9 #3 Fri Oct 12 18:27:56 PDT 2007 i686 GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.3-pre2
e2fsprogs  1.40-WIP
Linux C Library3.6
Dynamic linker (ldd)   2.3.6
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
udev   105
Modules Loaded nfs lockd sunrpc nvidia i2c_core af_packet ipv6 
capability commoncap ppdev lp ac battery dm_mod e1000 loop snd_intel8x0 
snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
parport_pc button parport snd 8250_pnp 8250 serial_core soundcore shpchp 
pci_hotplug snd_page_alloc rng_core floppy intel_agp agpgart rtc sg 
evdev sr_mod usbhid sd_mod ata_piix 8139too ata_generic ehci_hcd 
uhci_hcd mii bitrev crc32 libata generic usbcore thermal processor fan 
unix ext3 jbd piix ide_disk ide_cd cdrom ide_scsi scsi_mod ide_core

-

Here is output from syslog as it went down:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Oops: 0002 [#1]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: CPU:0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP:0060:[e1168fde]Tainted: PVLI

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EFLAGS: 00010206   (2.6.23-rc9 #3)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP is at 0xe1168fde

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: esi: f8f34700   edi:    ebp: 0001   esp: e7cf3e00

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Process firefox-bin (pid: 8397, ti=e7cf2000 task=f258ca90 
task.ti=e

7cf2000)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Stack: f8f18eb7 c01367f6 e7cf3e48 03e8 03e8 
ed3e97c0 f1f6db

9c f1f6db9c

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:e7cf3f54 f8f60ec2 0004257b   
f1f037dc e7cf3f

54 c01563d0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:019cc780 e7cf3eb0 c0155a63 dfff38c0 c014e001 
019cc780 f1f037

dc dfe0ecf4

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Call Trace:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [f8f18eb7] rpcauth_lookupcred+0x63/0x87 [sunrpc]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c01367f6] pagevec_lookup+0x1c/0x22

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [f8f60ec2] nfs_permission+0xab/0x183 [nfs]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c01563d0] __d_lookup+0x8b/0xbf

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c0155a63] dput+0x15/0xcb

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion 

Re: PROBLEM: kernel panic

[Doug Whitesell (LKML)]

On Oct 14, 2007, at 1:44 PM, Scott Petler wrote:


Trond,

I'm not exactly sure how to go back to not using the nvidia driver  
and select the xorg one.  I do know that I wasn't able to use both  
monitors with the xorg driver, but I'm willing to try that to  
isolate the problem.


If memory serves, you change your xorg.conf's Device section's  
Driver entry to read:

nv
instead of
nvidia,

although I would consult the xorg documentation/your distribution's  
documentation (and back up your working xorg.conf) for specific  
details. (Your boot sequence may also automatically load the nvidia  
module, again, consult your distribution's documentation for details.)


Cheers/hope this helps,
dcw
-
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: PROBLEM: kernel panic

[Scott Petler]

Doug,

I thought that might do it, it does seem to work.  I edited the driver 
line in my xorg.conf

from nvidia to nv and then,
altctrl F1
login as root
/etc/init.d/gdm stop
/etc/init.d/gdm start

It came back up with the same flashing crap on the second monitor, so I 
did it again with
the 2nd monitor turned off altogether, and I'll see how long it will run 
on the single monitor

without the nvidia driver without crashing (maybe forever...).

Thanks,
Scott

Doug Whitesell (LKML) wrote:

On Oct 14, 2007, at 1:44 PM, Scott Petler wrote:


Trond,

I'm not exactly sure how to go back to not using the nvidia driver 
and select the xorg one.  I do know that I wasn't able to use both 
monitors with the xorg driver, but I'm willing to try that to isolate 
the problem.


If memory serves, you change your xorg.conf's Device section's 
Driver entry to read:

nv
instead of
nvidia,

although I would consult the xorg documentation/your distribution's 
documentation (and back up your working xorg.conf) for specific 
details. (Your boot sequence may also automatically load the nvidia 
module, again, consult your distribution's documentation for details.)


Cheers/hope this helps,
dcw



-
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: PROBLEM: kernel panic

[Trond Myklebust]

On Sun, 2007-10-14 at 14:00 -0700, Scott Petler wrote:
 Doug,
 
 I thought that might do it, it does seem to work.  I edited the driver 
 line in my xorg.conf
 from nvidia to nv and then,
 altctrl F1
 login as root
 /etc/init.d/gdm stop
 /etc/init.d/gdm start
 
 It came back up with the same flashing crap on the second monitor, so I 
 did it again with
 the 2nd monitor turned off altogether, and I'll see how long it will run 
 on the single monitor
 without the nvidia driver without crashing (maybe forever...).
 
 Thanks, 
 Scott

Please don't forget to reboot, though. The kernel will remain tainted
until you've rebooted without loading the nvidia module.

Cheers
  Trond

-
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: PROBLEM: kernel panic

[Scott Petler]

Ok, I'll do that
Thanks

Sent from my iPhone

On Oct 14, 2007, at 2:32 PM, Trond Myklebust  
[EMAIL PROTECTED] wrote:




On Sun, 2007-10-14 at 14:00 -0700, Scott Petler wrote:

Doug,

I thought that might do it, it does seem to work.  I edited the  
driver

line in my xorg.conf
from nvidia to nv and then,
altctrl F1
login as root
/etc/init.d/gdm stop
/etc/init.d/gdm start

It came back up with the same flashing crap on the second monitor,  
so I

did it again with
the 2nd monitor turned off altogether, and I'll see how long it  
will run

on the single monitor
without the nvidia driver without crashing (maybe forever...).

Thanks,
Scott


Please don't forget to reboot, though. The kernel will remain tainted
until you've rebooted without loading the nvidia module.

Cheers
 Trond


-
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/

PROBLEM: kernel panic

[Scott Petler]

Machine lockup with caps lock/num lock flashing or complete reboot/panic.

I get various lockup issues with this kernel, (2.6.23 also similar 
problem).   I had problems getting e1000 lan module to work (it was fine 
in 2.6.21.5).  I disabled it and installed a different lan card that 
seems to work "better".


Dual head machine 1GB RAM, nvidia driver x86-100.14.19

Here is output of ver_linux:
-

Linux zion 2.6.23-rc9 #3 Fri Oct 12 18:27:56 PDT 2007 i686 GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.3-pre2
e2fsprogs  1.40-WIP
Linux C Library3.6
Dynamic linker (ldd)   2.3.6
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
udev   105
Modules Loaded nfs lockd sunrpc nvidia i2c_core af_packet ipv6 
capability commoncap ppdev lp ac battery dm_mod e1000 loop snd_intel8x0 
snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
parport_pc button parport snd 8250_pnp 8250 serial_core soundcore shpchp 
pci_hotplug snd_page_alloc rng_core floppy intel_agp agpgart rtc sg 
evdev sr_mod usbhid sd_mod ata_piix 8139too ata_generic ehci_hcd 
uhci_hcd mii bitrev crc32 libata generic usbcore thermal processor fan 
unix ext3 jbd piix ide_disk ide_cd cdrom ide_scsi scsi_mod ide_core

-

Here is output from syslog as it went down:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Oops: 0002 [#1]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: CPU:0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP:0060:[]Tainted: PVLI

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EFLAGS: 00010206   (2.6.23-rc9 #3)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP is at 0xe1168fde

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: esi: f8f34700   edi:    ebp: 0001   esp: e7cf3e00

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Process firefox-bin (pid: 8397, ti=e7cf2000 task=f258ca90 
task.ti=e

7cf2000)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Stack: f8f18eb7 c01367f6 e7cf3e48 03e8 03e8 
ed3e97c0 f1f6db

9c f1f6db9c

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:e7cf3f54 f8f60ec2 0004257b   
f1f037dc e7cf3f

54 c01563d0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:019cc780 e7cf3eb0 c0155a63 dfff38c0 c014e001 
019cc780 f1f037

dc dfe0ecf4

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Call Trace:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] rpcauth_lookupcred+0x63/0x87 [sunrpc]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] pagevec_lookup+0x1c/0x22

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] nfs_permission+0xab/0x183 [nfs]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] __d_lookup+0x8b/0xbf

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] dput+0x15/0xcb

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] nfs_permission+0x0/0x183 [nfs]
Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] __link_path_walk+0x11c/0xa79

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] setup_sigcontext+0x104/0x187

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] link_path_walk+0x42/0xaf
Read from remote host 192.168.1.175: Connection reset by peer
Connection to 192.168.1.175 closed.

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [] permission+0x9e/0xdb


/proc/cpuinfo

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 2
model name  : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping: 7
cpu MHz : 2411.749
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags  

PROBLEM: kernel panic

[Scott Petler]

Machine lockup with caps lock/num lock flashing or complete reboot/panic.

I get various lockup issues with this kernel, (2.6.23 also similar 
problem).   I had problems getting e1000 lan module to work (it was fine 
in 2.6.21.5).  I disabled it and installed a different lan card that 
seems to work better.


Dual head machine 1GB RAM, nvidia driver x86-100.14.19

Here is output of ver_linux:
-

Linux zion 2.6.23-rc9 #3 Fri Oct 12 18:27:56 PDT 2007 i686 GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.3-pre2
e2fsprogs  1.40-WIP
Linux C Library3.6
Dynamic linker (ldd)   2.3.6
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
udev   105
Modules Loaded nfs lockd sunrpc nvidia i2c_core af_packet ipv6 
capability commoncap ppdev lp ac battery dm_mod e1000 loop snd_intel8x0 
snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
parport_pc button parport snd 8250_pnp 8250 serial_core soundcore shpchp 
pci_hotplug snd_page_alloc rng_core floppy intel_agp agpgart rtc sg 
evdev sr_mod usbhid sd_mod ata_piix 8139too ata_generic ehci_hcd 
uhci_hcd mii bitrev crc32 libata generic usbcore thermal processor fan 
unix ext3 jbd piix ide_disk ide_cd cdrom ide_scsi scsi_mod ide_core

-

Here is output from syslog as it went down:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Oops: 0002 [#1]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: CPU:0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP:0060:[e1168fde]Tainted: PVLI

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EFLAGS: 00010206   (2.6.23-rc9 #3)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: EIP is at 0xe1168fde

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: esi: f8f34700   edi:    ebp: 0001   esp: e7cf3e00

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Process firefox-bin (pid: 8397, ti=e7cf2000 task=f258ca90 
task.ti=e

7cf2000)

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Stack: f8f18eb7 c01367f6 e7cf3e48 03e8 03e8 
ed3e97c0 f1f6db

9c f1f6db9c

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:e7cf3f54 f8f60ec2 0004257b   
f1f037dc e7cf3f

54 c01563d0

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:019cc780 e7cf3eb0 c0155a63 dfff38c0 c014e001 
019cc780 f1f037

dc dfe0ecf4

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel: Call Trace:

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [f8f18eb7] rpcauth_lookupcred+0x63/0x87 [sunrpc]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c01367f6] pagevec_lookup+0x1c/0x22

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [f8f60ec2] nfs_permission+0xab/0x183 [nfs]

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c01563d0] __d_lookup+0x8b/0xbf

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c0155a63] dput+0x15/0xcb

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [f8f60e17] nfs_permission+0x0/0x183 [nfs]
Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c014f648] __link_path_walk+0x11c/0xa79

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c0102ff8] setup_sigcontext+0x104/0x187

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c014ffe7] link_path_walk+0x42/0xaf
Read from remote host 192.168.1.175: Connection reset by peer
Connection to 192.168.1.175 closed.

Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ...
zion kernel:  [c014de5a] permission+0x9e/0xdb


/proc/cpuinfo

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 2
model name  : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping: 7
cpu MHz : 2411.749
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu

PROBLEM: Kernel panic when RAID drive fails

[Willo van der Merwe]

Summary Info:
Kernel halts with a kernel panic when a member of a RAID1 failed.

Detail Info:
I hope it's due to one of the drives failing, but I'm not sure. I've had 
endless issues with this machine. Any help would be appreciated.


Jun 27 05:22:27 sabertooth kernel: ata1: handling error/timeout
Jun 27 05:22:27 sabertooth kernel: ata1: port reset, p_is 0 is 0 pis 0 
cmd 4c017 tf 7f ss 0 se 0
Jun 27 05:22:27 sabertooth kernel: ata1: status=0x50 { DriveReady 
SeekComplete }
Jun 27 05:22:27 sabertooth kernel: Info fld=0x8c36, Current sda: sense 
key No Sense
Jun 27 05:22:27 sabertooth kernel: Assertion failure in dx_probe() at 
fs/ext3/namei.c:381: "dx_get_limit(entries) == dx_root_limit(dir, 
root->info.info_length)"

Jun 27 05:22:27 sabertooth kernel: [ cut here ]
Jun 27 05:22:27 sabertooth kernel: kernel BUG at fs/ext3/namei.c:381!
Jun 27 05:22:27 sabertooth kernel: invalid operand:  [#1]
Jun 27 05:22:27 sabertooth kernel: SMP
Jun 27 05:22:27 sabertooth kernel: Modules linked in: rfcomm l2cap 
bluetooth loop md5 ipv6 autofs4 dm_mirror dm_mod button battery ac 
uhci_hcd ehci_hcd e1000

ext3 jbd raid1 ahci libata sd_mod scsi_mod
Jun 27 05:22:27 sabertooth kernel: CPU:1
Jun 27 05:22:27 sabertooth kernel: EIP:0060:[]Not 
tainted VLI

Jun 27 05:22:27 sabertooth kernel: EFLAGS: 00010216   (2.6.9-42.ELsmp)
Jun 27 05:22:27 sabertooth kernel: EIP is at dx_probe+0x186/0x2b5 [ext3]
Jun 27 05:22:27 sabertooth kernel: eax: 0081   ebx: e4c9a998   ecx: 
e2472cf4   edx: f88ad744
Jun 27 05:22:27 sabertooth kernel: esi: dceac018   edi: e2472d58   ebp: 
   esp: e2472cf0

Jun 27 05:22:27 sabertooth kernel: ds: 007b   es: 007b   ss: 0068
Jun 27 05:22:27 sabertooth kernel: Process mysqld (pid: 16821, 
threadinfo=e2472000 task=f11386b0)
Jun 27 05:22:27 sabertooth kernel: Stack: f88ad744 f88ac880 f88ad734 
017d f88ad6f0 e2472d2c c011cd26 620fa5e2
Jun 27 05:22:27 sabertooth kernel:e3f5c694 e4c9a998 d5636474 
d5636474 e4c9a998 f77dcafc f88a32d6 e2472d58
Jun 27 05:22:27 sabertooth kernel:e2472dd4 c1a88f84 e4c9a998 
d56364e8 0015 c01a9ea3  f7f59a00

Jun 27 05:22:27 sabertooth kernel: Call Trace:
Jun 27 05:22:27 sabertooth kernel:  [] 
recalc_task_prio+0x128/0x133
Jun 27 05:22:27 sabertooth kernel:  [] 
ext3_dx_find_entry+0x6a/0x1d4 [ext3]
Jun 27 05:22:27 sabertooth kernel:  [] 
avc_has_perm_noaudit+0x8d/0xda
Jun 27 05:22:27 sabertooth kernel:  [] 
ext3_find_entry+0x8f/0x363 [ext3]

Jun 27 05:22:27 sabertooth kernel:  [] finish_wait+0x2c/0x50
Jun 27 05:22:27 sabertooth kernel:  [] inode_has_perm+0x4c/0x54
Jun 27 05:22:27 sabertooth kernel:  [] __cond_resched+0x14/0x39
Jun 27 05:22:27 sabertooth kernel:  [] ext3_lookup+0x1f/0x87 
[ext3]

Jun 27 05:22:27 sabertooth kernel:  [] real_lookup+0x6e/0xd2
Jun 27 05:22:27 sabertooth kernel:  [] do_lookup+0x56/0x8f
Jun 27 05:22:27 sabertooth kernel:  [] 
__link_path_walk+0x808/0xbb5

Jun 27 05:22:27 sabertooth kernel:  [] link_path_walk+0x43/0xbe
Jun 27 05:22:27 sabertooth kernel:  [] 
default_wake_function+0x0/0xc

Jun 27 05:22:27 sabertooth kernel:  [] __cond_resched+0x14/0x39
Jun 27 05:22:27 sabertooth kernel:  [] 
direct_strncpy_from_user+0x3e/0x5d

Jun 27 05:22:27 sabertooth kernel:  [] path_lookup+0x14b/0x17f
Jun 27 05:22:27 sabertooth kernel:  [] open_namei+0x99/0x579
Jun 27 05:22:27 sabertooth kernel:  [] filp_open+0x45/0x70
Jun 27 05:22:27 sabertooth kernel:  [] 
default_wake_function+0x0/0xc

Jun 27 05:22:27 sabertooth kernel:  [] __cond_resched+0x14/0x39
Jun 27 05:22:27 sabertooth kernel:  [] 
direct_strncpy_from_user+0x3e/0x5d

Jun 27 05:22:27 sabertooth kernel:  [] sys_open+0x31/0x7d
Jun 27 05:22:27 sabertooth kernel:  [] syscall_call+0x7/0xb
Jun 27 05:22:27 sabertooth kernel:  [] packet_rcv+0x242/0x307
Jun 27 05:22:27 sabertooth kernel: Code: 0c 29 d0 83 e8 18 c1 e8 03 39 
c1 74 29 68 f0 d6 8a f8 68 7d 01 00 00 68 34 d7 8a f8 68 80 c8 8a f8 68 
44 d7 8a f8 e8
d8 ff 87 c7 <0f> 0b 7d 01 34 d7 8a f8 83 c4 14 0f b7 5e 02 85 db 74 07 
0f b7

Jun 27 05:22:27 sabertooth kernel:  <0>Fatal exception: panic in 5 seconds
Jun 27 05:22:29 sabertooth kernel: EXT3-fs error (device md0) in 
start_transaction: Journal has aborted


-
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/

PROBLEM: Kernel panic when RAID drive fails

[Willo van der Merwe]

Summary Info:
Kernel halts with a kernel panic when a member of a RAID1 failed.

Detail Info:
I hope it's due to one of the drives failing, but I'm not sure. I've had 
endless issues with this machine. Any help would be appreciated.


Jun 27 05:22:27 sabertooth kernel: ata1: handling error/timeout
Jun 27 05:22:27 sabertooth kernel: ata1: port reset, p_is 0 is 0 pis 0 
cmd 4c017 tf 7f ss 0 se 0
Jun 27 05:22:27 sabertooth kernel: ata1: status=0x50 { DriveReady 
SeekComplete }
Jun 27 05:22:27 sabertooth kernel: Info fld=0x8c36, Current sda: sense 
key No Sense
Jun 27 05:22:27 sabertooth kernel: Assertion failure in dx_probe() at 
fs/ext3/namei.c:381: dx_get_limit(entries) == dx_root_limit(dir, 
root-info.info_length)

Jun 27 05:22:27 sabertooth kernel: [ cut here ]
Jun 27 05:22:27 sabertooth kernel: kernel BUG at fs/ext3/namei.c:381!
Jun 27 05:22:27 sabertooth kernel: invalid operand:  [#1]
Jun 27 05:22:27 sabertooth kernel: SMP
Jun 27 05:22:27 sabertooth kernel: Modules linked in: rfcomm l2cap 
bluetooth loop md5 ipv6 autofs4 dm_mirror dm_mod button battery ac 
uhci_hcd ehci_hcd e1000

ext3 jbd raid1 ahci libata sd_mod scsi_mod
Jun 27 05:22:27 sabertooth kernel: CPU:1
Jun 27 05:22:27 sabertooth kernel: EIP:0060:[f88a28c6]Not 
tainted VLI

Jun 27 05:22:27 sabertooth kernel: EFLAGS: 00010216   (2.6.9-42.ELsmp)
Jun 27 05:22:27 sabertooth kernel: EIP is at dx_probe+0x186/0x2b5 [ext3]
Jun 27 05:22:27 sabertooth kernel: eax: 0081   ebx: e4c9a998   ecx: 
e2472cf4   edx: f88ad744
Jun 27 05:22:27 sabertooth kernel: esi: dceac018   edi: e2472d58   ebp: 
   esp: e2472cf0

Jun 27 05:22:27 sabertooth kernel: ds: 007b   es: 007b   ss: 0068
Jun 27 05:22:27 sabertooth kernel: Process mysqld (pid: 16821, 
threadinfo=e2472000 task=f11386b0)
Jun 27 05:22:27 sabertooth kernel: Stack: f88ad744 f88ac880 f88ad734 
017d f88ad6f0 e2472d2c c011cd26 620fa5e2
Jun 27 05:22:27 sabertooth kernel:e3f5c694 e4c9a998 d5636474 
d5636474 e4c9a998 f77dcafc f88a32d6 e2472d58
Jun 27 05:22:27 sabertooth kernel:e2472dd4 c1a88f84 e4c9a998 
d56364e8 0015 c01a9ea3  f7f59a00

Jun 27 05:22:27 sabertooth kernel: Call Trace:
Jun 27 05:22:27 sabertooth kernel:  [c011cd26] 
recalc_task_prio+0x128/0x133
Jun 27 05:22:27 sabertooth kernel:  [f88a32d6] 
ext3_dx_find_entry+0x6a/0x1d4 [ext3]
Jun 27 05:22:27 sabertooth kernel:  [c01a9ea3] 
avc_has_perm_noaudit+0x8d/0xda
Jun 27 05:22:27 sabertooth kernel:  [f88a2f98] 
ext3_find_entry+0x8f/0x363 [ext3]

Jun 27 05:22:27 sabertooth kernel:  [c01204d1] finish_wait+0x2c/0x50
Jun 27 05:22:27 sabertooth kernel:  [c01aaff1] inode_has_perm+0x4c/0x54
Jun 27 05:22:27 sabertooth kernel:  [c02d2cb2] __cond_resched+0x14/0x39
Jun 27 05:22:27 sabertooth kernel:  [f88a345f] ext3_lookup+0x1f/0x87 
[ext3]

Jun 27 05:22:27 sabertooth kernel:  [c0166591] real_lookup+0x6e/0xd2
Jun 27 05:22:27 sabertooth kernel:  [c01667ae] do_lookup+0x56/0x8f
Jun 27 05:22:27 sabertooth kernel:  [c0166fef] 
__link_path_walk+0x808/0xbb5

Jun 27 05:22:27 sabertooth kernel:  [c01673df] link_path_walk+0x43/0xbe
Jun 27 05:22:27 sabertooth kernel:  [c011e794] 
default_wake_function+0x0/0xc

Jun 27 05:22:27 sabertooth kernel:  [c02d2cb2] __cond_resched+0x14/0x39
Jun 27 05:22:27 sabertooth kernel:  [c01c31ca] 
direct_strncpy_from_user+0x3e/0x5d

Jun 27 05:22:27 sabertooth kernel:  [c0167774] path_lookup+0x14b/0x17f
Jun 27 05:22:27 sabertooth kernel:  [c0167e4b] open_namei+0x99/0x579
Jun 27 05:22:27 sabertooth kernel:  [c015a3de] filp_open+0x45/0x70
Jun 27 05:22:27 sabertooth kernel:  [c011e794] 
default_wake_function+0x0/0xc

Jun 27 05:22:27 sabertooth kernel:  [c02d2cb2] __cond_resched+0x14/0x39
Jun 27 05:22:27 sabertooth kernel:  [c01c31ca] 
direct_strncpy_from_user+0x3e/0x5d

Jun 27 05:22:27 sabertooth kernel:  [c015a73a] sys_open+0x31/0x7d
Jun 27 05:22:27 sabertooth kernel:  [c02d4703] syscall_call+0x7/0xb
Jun 27 05:22:27 sabertooth kernel:  [c02d007b] packet_rcv+0x242/0x307
Jun 27 05:22:27 sabertooth kernel: Code: 0c 29 d0 83 e8 18 c1 e8 03 39 
c1 74 29 68 f0 d6 8a f8 68 7d 01 00 00 68 34 d7 8a f8 68 80 c8 8a f8 68 
44 d7 8a f8 e8
d8 ff 87 c7 0f 0b 7d 01 34 d7 8a f8 83 c4 14 0f b7 5e 02 85 db 74 07 
0f b7

Jun 27 05:22:27 sabertooth kernel:  0Fatal exception: panic in 5 seconds
Jun 27 05:22:29 sabertooth kernel: EXT3-fs error (device md0) in 
start_transaction: Journal has aborted


-
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: PROBLEM: kernel panic while copying files (with the OOPSincluded)

[Jean-Francois Patenaude]

I put the Oops on my web site (see Section 5 for links).  BTW, tell me
if I did not do the ksymoops ok !

Jf.




--

[1.] One line summary of the problem:

kernel panic while copying files


[2.] Full description of the problem/report:

When I copy a 450 MB file from one partition (/usr) to another (/tmp) I
get a kernel panic.  It happens everytime I copy that file.  The amount
of data copied before the kernel panic is not always the same.   These
two partitions use ext2fs.


[3.] Keywords (i.e., modules, networking, kernel):

xx


[4.] Kernel version (from /proc/version):

The problem happens with kernel 2.4.0-test{1,5,8,9}
and it doesn't happen with kernel 2.2.{14,17}

I would like to use newer kernels since I want to add XFS support (SGI's
filesystem).  Although I must specify that my problems are happening
even with kernel that have not had the XFS patch applied.


[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)

http://volks.suid.com/csrc228.capture
http://volks.suid.com/csrc228.capture-ksymed


[6.] A small shell script or example program which triggers the
 problem (if possible)

cp /usr/blah1 /tmp


[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)

THIS IS THE OUTPUT WHEN I BOOT THE "WORKING KERNEL" (2.2.17)

[root@csrc228 linux]# sh scripts/ver_linux 
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux csrc228 2.2.17 #1 Wed Nov 1 10:03:58 EST 2000 i686 unknown
Kernel modules 2.3.10-pre1
Gnu C  egcs-2.91.66
Binutils   2.9.5.0.22
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10f
Net-tools  1.54
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded 
[root@csrc228 linux]# 


[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 499.889
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr xmm
bogomips: 996.15


[7.3.] Module information (from /proc/modules):

no modules loaded


[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(auto)
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
2000-207f : sym53c8xx
2400-247f : sym53c8xx
4000-401f : Intel Speedo3 Ethernet
4020-403f : Intel Speedo3 Ethernet


[7.5.] PCI information ('lspci -vvv' as root)

00:0b.0 PCI Hot-plug controller: Compaq Computer Corporation: Unknown
device a0f7 (rev 04)
Subsystem: Compaq Computer Corporation: Unknown device a2f8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- Reset- FastB2B-

04:02.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

04:0b.0 PCI Hot-plug controller: Compaq Computer Corporation: Unknown
device a0f7 (rev 04)
Subsystem: Compaq Computer Corporation: Unknown device a2f8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- http://www.tux.org/lkml/

Re: PROBLEM: kernel panic while copying files (with the OOPSincluded)

[Jean-Francois Patenaude]

I put the Oops on my web site (see Section 5 for links).  BTW, tell me
if I did not do the ksymoops ok !

Jf.




--

[1.] One line summary of the problem:

kernel panic while copying files


[2.] Full description of the problem/report:

When I copy a 450 MB file from one partition (/usr) to another (/tmp) I
get a kernel panic.  It happens everytime I copy that file.  The amount
of data copied before the kernel panic is not always the same.   These
two partitions use ext2fs.


[3.] Keywords (i.e., modules, networking, kernel):

xx


[4.] Kernel version (from /proc/version):

The problem happens with kernel 2.4.0-test{1,5,8,9}
and it doesn't happen with kernel 2.2.{14,17}

I would like to use newer kernels since I want to add XFS support (SGI's
filesystem).  Although I must specify that my problems are happening
even with kernel that have not had the XFS patch applied.


[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)

http://volks.suid.com/csrc228.capture
http://volks.suid.com/csrc228.capture-ksymed


[6.] A small shell script or example program which triggers the
 problem (if possible)

cp /usr/blah1 /tmp


[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)

THIS IS THE OUTPUT WHEN I BOOT THE "WORKING KERNEL" (2.2.17)

[root@csrc228 linux]# sh scripts/ver_linux 
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux csrc228 2.2.17 #1 Wed Nov 1 10:03:58 EST 2000 i686 unknown
Kernel modules 2.3.10-pre1
Gnu C  egcs-2.91.66
Binutils   2.9.5.0.22
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10f
Net-tools  1.54
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded 
[root@csrc228 linux]# 


[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 499.889
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr xmm
bogomips: 996.15


[7.3.] Module information (from /proc/modules):

no modules loaded


[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(auto)
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
2000-207f : sym53c8xx
2400-247f : sym53c8xx
4000-401f : Intel Speedo3 Ethernet
4020-403f : Intel Speedo3 Ethernet


[7.5.] PCI information ('lspci -vvv' as root)

00:0b.0 PCI Hot-plug controller: Compaq Computer Corporation: Unknown
device a0f7 (rev 04)
Subsystem: Compaq Computer Corporation: Unknown device a2f8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 5
Region 0: Memory at c6af (32-bit, non-prefetchable)

00:0c.0 System peripheral: Compaq Computer Corporation: Unknown device
a0f0
Subsystem: Compaq Computer Corporation: Unknown device b0f3
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at 1800
Region 1: Memory at c6ae (32-bit, non-prefetchable)

00:0d.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR)
53c875 (rev 14)
Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI
Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 17 min, 64 max, 255 set, cache line size 08
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 2000
Region 1: Memory at c6ad (32-bit, non-prefetchable)
Region 2: Memory at c6ac (32-bit, non-prefetchable)

00:0d.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR)
53c875 (rev 14)
Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI
Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=med

Re: PROBLEM: kernel panic while copying files

[Jean-Francois Patenaude]

Ok, I'll get back with the oops information ASAP !




Tigran Aivazian wrote:
> 
> Jean-Francois,
> 
> You are reporting a panic but missing the most important ingredient:
> 
> On Wed, 1 Nov 2000, Jean-Francois Patenaude wrote:
> > [5.] Output of Oops.. message (if applicable) with symbolic information
> >  resolved (see Documentation/oops-tracing.txt)
> >
> > xx
> >
> 
> If "xx" means "kiss-kiss" then you can "kiss good bye" to any hope of
> resolving this panic until you send the oops message passed through
> ksymoops. If this is really a panic and not an oops then you need to
> capture it through a serial console and then pass through ksymoops on the
> next boot.
> 
> Regards,
> Tigran

-- 
/\/\/\/\/\/\/\/
Jean-Francois Patenaude
MGR EXPERT. CTRE CLIENTS SERV. / DIR. CTRE EXP. SERVICE CLIENTS
700 DE LA GAUCHETIERE OUEST  RC-MEZ  MONTREAL (QUEBEC)  H3B 4L1
Tel: (514) 870-3190   Fax: (514) 391-8660   Pag: (514) 330-4479
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/  [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: kernel panic while copying files

[Tigran Aivazian]

Jean-Francois,

You are reporting a panic but missing the most important ingredient:

On Wed, 1 Nov 2000, Jean-Francois Patenaude wrote:
> [5.] Output of Oops.. message (if applicable) with symbolic information 
>  resolved (see Documentation/oops-tracing.txt)
> 
> xx
> 

If "xx" means "kiss-kiss" then you can "kiss good bye" to any hope of
resolving this panic until you send the oops message passed through
ksymoops. If this is really a panic and not an oops then you need to
capture it through a serial console and then pass through ksymoops on the
next boot.

Regards,
Tigran


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PROBLEM: kernel panic while copying files

[Jean-Francois Patenaude]

[1.] One line summary of the problem:

kernel panic while copying files


[2.] Full description of the problem/report:

When I copy a 450 MB file from one partition (/usr) to another (/tmp) I
get a kernel panic.  It happens everytime I copy that file.  The amount
of data copied before the kernel panic is not always the same.   These
two partitions use ext2fs.


[3.] Keywords (i.e., modules, networking, kernel):

xx


[4.] Kernel version (from /proc/version):

The problem happens with kernel 2.4.0-test{1,5,8,9}
and it doesn't happen with kernel 2.2.{14,17}

I would like to use newer kernels since I want to add XFS support (SGI's
filesystem).  Although I must specify that my problems are happening
even with kernel that have not had the XFS patch applied.


[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)

xx


[6.] A small shell script or example program which triggers the
 problem (if possible)

cp /usr/blah1 /tmp


[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)

THIS IS THE OUTPUT WHEN I BOOT THE "WORKING KERNEL" (2.2.17)

[root@csrc228 linux]# sh scripts/ver_linux 
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux csrc228 2.2.17 #1 Wed Nov 1 10:03:58 EST 2000 i686 unknown
Kernel modules 2.3.10-pre1
Gnu C  egcs-2.91.66
Binutils   2.9.5.0.22
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10f
Net-tools  1.54
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded 
[root@csrc228 linux]# 


[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 499.889
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr xmm
bogomips: 996.15


[7.3.] Module information (from /proc/modules):

no modules loaded


[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(auto)
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
2000-207f : sym53c8xx
2400-247f : sym53c8xx
4000-401f : Intel Speedo3 Ethernet
4020-403f : Intel Speedo3 Ethernet


[7.5.] PCI information ('lspci -vvv' as root)

00:0b.0 PCI Hot-plug controller: Compaq Computer Corporation: Unknown
device a0f7 (rev 04)
Subsystem: Compaq Computer Corporation: Unknown device a2f8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- Reset- FastB2B-

04:02.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

04:0b.0 PCI Hot-plug controller: Compaq Computer Corporation: Unknown
device a0f7 (rev 04)
Subsystem: Compaq Computer Corporation: Unknown device a2f8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- http://www.tux.org/lkml/

PROBLEM: kernel panic while copying files

[Jean-Francois Patenaude]

[1.] One line summary of the problem:

kernel panic while copying files


[2.] Full description of the problem/report:

When I copy a 450 MB file from one partition (/usr) to another (/tmp) I
get a kernel panic.  It happens everytime I copy that file.  The amount
of data copied before the kernel panic is not always the same.   These
two partitions use ext2fs.


[3.] Keywords (i.e., modules, networking, kernel):

xx


[4.] Kernel version (from /proc/version):

The problem happens with kernel 2.4.0-test{1,5,8,9}
and it doesn't happen with kernel 2.2.{14,17}

I would like to use newer kernels since I want to add XFS support (SGI's
filesystem).  Although I must specify that my problems are happening
even with kernel that have not had the XFS patch applied.


[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)

xx


[6.] A small shell script or example program which triggers the
 problem (if possible)

cp /usr/blah1 /tmp


[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)

THIS IS THE OUTPUT WHEN I BOOT THE "WORKING KERNEL" (2.2.17)

[root@csrc228 linux]# sh scripts/ver_linux 
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux csrc228 2.2.17 #1 Wed Nov 1 10:03:58 EST 2000 i686 unknown
Kernel modules 2.3.10-pre1
Gnu C  egcs-2.91.66
Binutils   2.9.5.0.22
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10f
Net-tools  1.54
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded 
[root@csrc228 linux]# 


[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 499.889
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr xmm
bogomips: 996.15


[7.3.] Module information (from /proc/modules):

no modules loaded


[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(auto)
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
2000-207f : sym53c8xx
2400-247f : sym53c8xx
4000-401f : Intel Speedo3 Ethernet
4020-403f : Intel Speedo3 Ethernet


[7.5.] PCI information ('lspci -vvv' as root)

00:0b.0 PCI Hot-plug controller: Compaq Computer Corporation: Unknown
device a0f7 (rev 04)
Subsystem: Compaq Computer Corporation: Unknown device a2f8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 5
Region 0: Memory at c6af (32-bit, non-prefetchable)

00:0c.0 System peripheral: Compaq Computer Corporation: Unknown device
a0f0
Subsystem: Compaq Computer Corporation: Unknown device b0f3
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at 1800
Region 1: Memory at c6ae (32-bit, non-prefetchable)

00:0d.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR)
53c875 (rev 14)
Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI
Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 17 min, 64 max, 255 set, cache line size 08
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 2000
Region 1: Memory at c6ad (32-bit, non-prefetchable)
Region 2: Memory at c6ac (32-bit, non-prefetchable)

00:0d.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR)
53c875 (rev 14)
Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI
Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 17 min, 64 max, 255 set, cache line size 08
Interrupt: pin B routed to IRQ 10
Region 0: I/O ports at 2400
Region

Re: PROBLEM: kernel panic while copying files

[Tigran Aivazian]

Jean-Francois,

You are reporting a panic but missing the most important ingredient:

On Wed, 1 Nov 2000, Jean-Francois Patenaude wrote:
 [5.] Output of Oops.. message (if applicable) with symbolic information 
  resolved (see Documentation/oops-tracing.txt)
 
 xx
 

If "xx" means "kiss-kiss" then you can "kiss good bye" to any hope of
resolving this panic until you send the oops message passed through
ksymoops. If this is really a panic and not an oops then you need to
capture it through a serial console and then pass through ksymoops on the
next boot.

Regards,
Tigran


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: kernel panic while copying files

[Jean-Francois Patenaude]

Ok, I'll get back with the oops information ASAP !




Tigran Aivazian wrote:
 
 Jean-Francois,
 
 You are reporting a panic but missing the most important ingredient:
 
 On Wed, 1 Nov 2000, Jean-Francois Patenaude wrote:
  [5.] Output of Oops.. message (if applicable) with symbolic information
   resolved (see Documentation/oops-tracing.txt)
 
  xx
 
 
 If "xx" means "kiss-kiss" then you can "kiss good bye" to any hope of
 resolving this panic until you send the oops message passed through
 ksymoops. If this is really a panic and not an oops then you need to
 capture it through a serial console and then pass through ksymoops on the
 next boot.
 
 Regards,
 Tigran

-- 
/\/\/\/\/\/\/\/
Jean-Francois Patenaude
MGR EXPERT. CTRE CLIENTS SERV. / DIR. CTRE EXP. SERVICE CLIENTS
700 DE LA GAUCHETIERE OUEST  RC-MEZ  MONTREAL (QUEBEC)  H3B 4L1
Tel: (514) 870-3190   Fax: (514) 391-8660   Pag: (514) 330-4479
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/  [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/