On January 15, 2008, Ingo Molnar wrote:
>
> * Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> > This is _not_ a regression. This has been occuring for ages here. A
> > backport of this fix to 2.6.23 would be a very good thing - IMHO its
> > something that should go into stable asap.
>
> the
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> This is _not_ a regression. This has been occuring for ages here. A
> backport of this fix to 2.6.23 would be a very good thing - IMHO its
> something that should go into stable asap.
the problem is that this bug was only present in x86.git. I.e.
> Ingo,
>
> This is _not_ a regression. This has been occuring for ages here. A
> backport of this fix to 2.6.23 would be a
> very good thing - IMHO its something that should go into stable asap.
>
> Thanks,
> Ed Tomlinson
>
>
>
++
Ingo,
this probably has to do something with the random
Ingo,
This is _not_ a regression. This has been occuring for ages here. A
backport of this fix to 2.6.23 would be a
very good thing - IMHO its something that should go into stable asap.
Thanks,
Ed Tomlinson
++
Ingo,
this probably has to do something with the random unmotivated
* Ed Tomlinson [EMAIL PROTECTED] wrote:
This is _not_ a regression. This has been occuring for ages here. A
backport of this fix to 2.6.23 would be a very good thing - IMHO its
something that should go into stable asap.
the problem is that this bug was only present in x86.git. I.e.
On January 15, 2008, Ingo Molnar wrote:
* Ed Tomlinson [EMAIL PROTECTED] wrote:
This is _not_ a regression. This has been occuring for ages here. A
backport of this fix to 2.6.23 would be a very good thing - IMHO its
something that should go into stable asap.
the problem is that
On January 14, 2008, Ingo Molnar wrote:
>
> * Matthew <[EMAIL PROTECTED]> wrote:
>
> > > FYI, latest x86.git should have this fix included. So if your box
> > > still hangs there must be some other bug lurking as well.
> >
> >
> > the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108
> >
* Matthew <[EMAIL PROTECTED]> wrote:
> > FYI, latest x86.git should have this fix included. So if your box
> > still hangs there must be some other bug lurking as well.
>
>
> the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108
> http://forums.gentoo.org/viewtopic-p-4719206.html#4719206
>
> FYI, latest x86.git should have this fix included. So if your box still
> hangs there must be some other bug lurking as well.
the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108
http://forums.gentoo.org/viewtopic-p-4719206.html#4719206 (+ following posts)
works like a charm :)
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >> - if yes, does booting with "nmi_watchdog=2 idle=poll" give you a
> >> working NMI watchdog? (working NMI watchdog means the NMI counts
> >> increase for all cores in /proc/interrupts).
>
> > booting with the above gives me an incrementing NMI
* Matthew <[EMAIL PROTECTED]> wrote:
> > I just managed to reproduce the bug in simulation. I believe we should
> > be able to resolve this.
>
> That's great news! Keep up the good work :)
FYI, latest x86.git should have this fix included. So if your box still
hangs there must be some other
* Ed Tomlinson [EMAIL PROTECTED] wrote:
- if yes, does booting with nmi_watchdog=2 idle=poll give you a
working NMI watchdog? (working NMI watchdog means the NMI counts
increase for all cores in /proc/interrupts).
booting with the above gives me an incrementing NMI counter in
* Matthew [EMAIL PROTECTED] wrote:
I just managed to reproduce the bug in simulation. I believe we should
be able to resolve this.
That's great news! Keep up the good work :)
FYI, latest x86.git should have this fix included. So if your box still
hangs there must be some other bug
FYI, latest x86.git should have this fix included. So if your box still
hangs there must be some other bug lurking as well.
the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108
http://forums.gentoo.org/viewtopic-p-4719206.html#4719206 (+ following posts)
works like a charm :)
* Matthew [EMAIL PROTECTED] wrote:
FYI, latest x86.git should have this fix included. So if your box
still hangs there must be some other bug lurking as well.
the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108
http://forums.gentoo.org/viewtopic-p-4719206.html#4719206 (+
On January 14, 2008, Ingo Molnar wrote:
* Matthew [EMAIL PROTECTED] wrote:
FYI, latest x86.git should have this fix included. So if your box
still hangs there must be some other bug lurking as well.
the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108
>> - if yes, does booting with "nmi_watchdog=2 idle=poll" give you a
>> working NMI watchdog? (working NMI watchdog means the NMI counts
>> increase for all cores in /proc/interrupts).
> booting with the above gives me an incrementing NMI counter in
> /proc/interrupts
Ingo,
Is there
On Thu, 2008-01-10 at 13:43 +0100, Matthew wrote:
> it's a little tricky to reproduce it:
> I tried it with root-account: firefox-bin, thunderbird-bin wouldn't trigger
> user-account (with used account-directory of both apps):
> thunderbird-bin triggers it more reliably
> probably it has to do
> I just managed to reproduce the bug in simulation. I believe we should
> be able to resolve this.
That's great news! Keep up the good work :)
I hope that you guys'll be able to do so since it (indirectly) more or
less leads to data corruption (at least with thunderbird-bin &
firefox-bin ->
Matthew wrote:
That's fine, but that was collected with the vmlinux image you sent me,
right?
no, but now it is:
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/latest/
(the other one was taken before I added/selected the demanded features)
what puzzles me is that it doesn't
>
> That's fine, but that was collected with the vmlinux image you sent me,
> right?
>
no, but now it is:
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/latest/
(the other one was taken before I added/selected the demanded features)
what puzzles me is that it doesn't say
Matthew wrote:
Do you have the error dump output to go along with this, too?
no, unfortunately no kernel crash dump on disk ;( (I hope I understood
it right, I'm pretty noobish concerning collection of error data ;) )
I only have the console-output of the hardlock in:
> Do you have the error dump output to go along with this, too?
>
no, unfortunately no kernel crash dump on disk ;( (I hope I understood
it right, I'm pretty noobish concerning collection of error data ;) )
I only have the console-output of the hardlock in:
Matthew wrote:
If you *do* reproduce the problem that way, it would be extremely
helpful if you could enable CONFIG_DEBUG_INFO and provide the vmlinux
(not vmlinuz/bzImage) file that goes with the crash dump screenshot.
I *did* reproduce it that way and enabled the above mentioned option
and
> If you *do* reproduce the problem that way, it would be extremely
> helpful if you could enable CONFIG_DEBUG_INFO and provide the vmlinux
> (not vmlinuz/bzImage) file that goes with the crash dump screenshot.
I *did* reproduce it that way and enabled the above mentioned option
and the
On January 10, 2008, Ingo Molnar wrote:
>
> * Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> > Matthew is not alone with this problem. I have it too. Its not new
> > here. Its been happening as long as I have had gentoo amd64
> > installed. It can be hard to reproduce but eventually, when 32
> > My kernel is _not_ tainted. [...]
>
this time my kernel isn't tainted either (comm: thunderbird-bin Not
tainted;
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/moto_0041.jpg)
but still hardlocks:
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/
> ok,
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> Matthew is not alone with this problem. I have it too. Its not new
> here. Its been happening as long as I have had gentoo amd64
> installed. It can be hard to reproduce but eventually, when 32 bit
> apps are used, my box bricks. There is
* Matthew <[EMAIL PROTECTED]> wrote:
> > > this also happens with rc7-based kernels, btw
> >
> > hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you?
> > Or any patches ontop of it? (x86.git perhaps?)
>
> see first post / mail (there are a few additional patches / trees
>
On January 10, 2008, Ingo Molnar wrote:
>
> * Matthew <[EMAIL PROTECTED]> wrote:
>
> > this also happens with rc7-based kernels, btw
>
> hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or
> any patches ontop of it? (x86.git perhaps?)
Matthew is not alone with this
>
> > this also happens with rc7-based kernels, btw
>
> hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or
> any patches ontop of it? (x86.git perhaps?)
see first post / mail (there are a few additional patches / trees
included: badram, wireless, alsa, tuxonice, madwifi,
* Matthew <[EMAIL PROTECTED]> wrote:
> this also happens with rc7-based kernels, btw
hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or
any patches ontop of it? (x86.git perhaps?)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> really, that module does all sorts of nasty stuff when inserted (and
> then removed), so just to make sure (because you are about to crash your
> box again to take a picture), could you try to boot up without never
> even once loading the nvidia module?
and it still happens ;(
I un-emerged
* Matthew <[EMAIL PROTECTED]> wrote:
> > I have been unable to reproduce your problem here, and I notice you have
> > the proprietary, highly invasive and closed-source Nvidia driver
> > installed in your kernel.
> >
> > Can you try using the "nv" or "vesa" (unaccelerated) Xorg drivers and
> >
> I have been unable to reproduce your problem here, and I notice you have
> the proprietary, highly invasive and closed-source Nvidia driver
> installed in your kernel.
>
> Can you try using the "nv" or "vesa" (unaccelerated) Xorg drivers and
> reproduce the problem that way?
>
> If you *do*
I have been unable to reproduce your problem here, and I notice you have
the proprietary, highly invasive and closed-source Nvidia driver
installed in your kernel.
Can you try using the nv or vesa (unaccelerated) Xorg drivers and
reproduce the problem that way?
If you *do* reproduce the
* Matthew [EMAIL PROTECTED] wrote:
I have been unable to reproduce your problem here, and I notice you have
the proprietary, highly invasive and closed-source Nvidia driver
installed in your kernel.
Can you try using the nv or vesa (unaccelerated) Xorg drivers and
reproduce the
* Matthew [EMAIL PROTECTED] wrote:
this also happens with rc7-based kernels, btw
hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or
any patches ontop of it? (x86.git perhaps?)
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On January 10, 2008, Ingo Molnar wrote:
* Matthew [EMAIL PROTECTED] wrote:
this also happens with rc7-based kernels, btw
hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or
any patches ontop of it? (x86.git perhaps?)
Matthew is not alone with this problem. I have
* Matthew [EMAIL PROTECTED] wrote:
this also happens with rc7-based kernels, btw
hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you?
Or any patches ontop of it? (x86.git perhaps?)
see first post / mail (there are a few additional patches / trees
included: badram,
this also happens with rc7-based kernels, btw
hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or
any patches ontop of it? (x86.git perhaps?)
see first post / mail (there are a few additional patches / trees
included: badram, wireless, alsa, tuxonice, madwifi, reiser4,
* Ed Tomlinson [EMAIL PROTECTED] wrote:
Matthew is not alone with this problem. I have it too. Its not new
here. Its been happening as long as I have had gentoo amd64
installed. It can be hard to reproduce but eventually, when 32 bit
apps are used, my box bricks. There is nothing in
My kernel is _not_ tainted. [...]
this time my kernel isn't tainted either (comm: thunderbird-bin Not
tainted;
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/moto_0041.jpg)
but still hardlocks:
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/
ok, good. A
On January 10, 2008, Ingo Molnar wrote:
* Ed Tomlinson [EMAIL PROTECTED] wrote:
Matthew is not alone with this problem. I have it too. Its not new
here. Its been happening as long as I have had gentoo amd64
installed. It can be hard to reproduce but eventually, when 32 bit
apps
If you *do* reproduce the problem that way, it would be extremely
helpful if you could enable CONFIG_DEBUG_INFO and provide the vmlinux
(not vmlinuz/bzImage) file that goes with the crash dump screenshot.
I *did* reproduce it that way and enabled the above mentioned option
and the
Matthew wrote:
If you *do* reproduce the problem that way, it would be extremely
helpful if you could enable CONFIG_DEBUG_INFO and provide the vmlinux
(not vmlinuz/bzImage) file that goes with the crash dump screenshot.
I *did* reproduce it that way and enabled the above mentioned option
and
Do you have the error dump output to go along with this, too?
no, unfortunately no kernel crash dump on disk ;( (I hope I understood
it right, I'm pretty noobish concerning collection of error data ;) )
I only have the console-output of the hardlock in:
Matthew wrote:
Do you have the error dump output to go along with this, too?
no, unfortunately no kernel crash dump on disk ;( (I hope I understood
it right, I'm pretty noobish concerning collection of error data ;) )
I only have the console-output of the hardlock in:
That's fine, but that was collected with the vmlinux image you sent me,
right?
no, but now it is:
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/latest/
(the other one was taken before I added/selected the demanded features)
what puzzles me is that it doesn't say tainted
Matthew wrote:
That's fine, but that was collected with the vmlinux image you sent me,
right?
no, but now it is:
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/latest/
(the other one was taken before I added/selected the demanded features)
what puzzles me is that it doesn't
I just managed to reproduce the bug in simulation. I believe we should
be able to resolve this.
That's great news! Keep up the good work :)
I hope that you guys'll be able to do so since it (indirectly) more or
less leads to data corruption (at least with thunderbird-bin
firefox-bin - both
On Thu, 2008-01-10 at 13:43 +0100, Matthew wrote:
it's a little tricky to reproduce it:
I tried it with root-account: firefox-bin, thunderbird-bin wouldn't trigger
user-account (with used account-directory of both apps):
thunderbird-bin triggers it more reliably
probably it has to do with
- if yes, does booting with nmi_watchdog=2 idle=poll give you a
working NMI watchdog? (working NMI watchdog means the NMI counts
increase for all cores in /proc/interrupts).
booting with the above gives me an incrementing NMI counter in
/proc/interrupts
Ingo,
Is there anything else
Matthew wrote:
Hi everyone,
sorry for the long delay
- I first had to get home & set up my rig to reproduce this hardlock
(repeatedly hardlocking / shutting down the laptop doesn't do too good
to the new hdd ;) )
and fortunately I was successful :)
sorry for the bad quality of the pics (they
> thanks a ton. ia32_setup_frame+0xe2/0x1e0 crashes with a NULL pointer it
> appears. Could you send me your kernel's .config ?
>
sure:
(I renamed the kernel in Makefile for being able to distinguish it
from the other git-kernels -> bisect-crash)
#
# Automatically generated make config: don't
Hi everyone,
sorry for the long delay
- I first had to get home & set up my rig to reproduce this hardlock
(repeatedly hardlocking / shutting down the laptop doesn't do too good
to the new hdd ;) )
and fortunately I was successful :)
sorry for the bad quality of the pics (they were taken with
thanks a ton. ia32_setup_frame+0xe2/0x1e0 crashes with a NULL pointer it
appears. Could you send me your kernel's .config ?
sure:
(I renamed the kernel in Makefile for being able to distinguish it
from the other git-kernels - bisect-crash)
#
# Automatically generated make config: don't edit
#
Hi everyone,
sorry for the long delay
- I first had to get home set up my rig to reproduce this hardlock
(repeatedly hardlocking / shutting down the laptop doesn't do too good
to the new hdd ;) )
and fortunately I was successful :)
sorry for the bad quality of the pics (they were taken with
Matthew wrote:
Hi everyone,
sorry for the long delay
- I first had to get home set up my rig to reproduce this hardlock
(repeatedly hardlocking / shutting down the laptop doesn't do too good
to the new hdd ;) )
and fortunately I was successful :)
sorry for the bad quality of the pics (they
* Miguel Botón <[EMAIL PROTECTED]> wrote:
> These hardlocks start to appear with commit
> f10c1cfd359660c01446807b6c2bc8ce3aee919a
thanks, that's really useful! I dont see anything obviously wrong with
the commit though, and cannot (yet) reproduce it, so to help us track it
down further,
* Miguel Botón [EMAIL PROTECTED] wrote:
These hardlocks start to appear with commit
f10c1cfd359660c01446807b6c2bc8ce3aee919a
thanks, that's really useful! I dont see anything obviously wrong with
the commit though, and cannot (yet) reproduce it, so to help us track it
down further, could
On Sunday 30 December 2007 00:04:17 Matthew wrote:
> so I was wrong XD
>
> sorry,
>
> the error was found in the meantime:
>
> see: http://forums.gentoo.org/viewtopic-p-4667858.html#4667858
>
> Don't need to do more testing. The culprit is the unification of the
> x86 i387 code.
>
> The culprit is
so I was wrong XD
sorry,
the error was found in the meantime:
see: http://forums.gentoo.org/viewtopic-p-4667858.html#4667858
Don't need to do more testing. The culprit is the unification of the
x86 i387 code.
The culprit is 57c3da2f5bb3fafedc31284117ae43bc593b65ab or
so I was wrong XD
sorry,
the error was found in the meantime:
see: http://forums.gentoo.org/viewtopic-p-4667858.html#4667858
Don't need to do more testing. The culprit is the unification of the
x86 i387 code.
The culprit is 57c3da2f5bb3fafedc31284117ae43bc593b65ab or
On Sunday 30 December 2007 00:04:17 Matthew wrote:
so I was wrong XD
sorry,
the error was found in the meantime:
see: http://forums.gentoo.org/viewtopic-p-4667858.html#4667858
Don't need to do more testing. The culprit is the unification of the
x86 i387 code.
The culprit is
65 matches
Mail list logo
