With reboot-resistent i mean, that this is a problem
which, after the 1st crash, something is changed on the
system so that also on subsequent reboots it crashs
quickly, and this change don't go away. Only if it is
explicitely deleted. This can be, for example, by
changes of temporary files which are corrupted and stay
corrupted and like this after reboot are used, or if there
stay resident parts in the memory (perhaps by the battery
current).
This problem is seldom, but right now it's happening, with
a serie of the reported errors.
This problem continues also on 2.6.39-rc4-git4.
The computer crashs, tipically 1 min. (at 2.6.39-rc1) or
later, 20 -60 min. after the boot. This happens mainly,
if you bunzip2 or copy a big file. I think this have
something to do with the memory administration, perhaps
with paging.
When you reboot after such a 1st crash, then the computer
crashs quickly at the beginning of the boot process, when
it's init ata1.0.0. From this, my most fotos are. It
looks, that the computer try to assign anything to ata1.
What, that's changing often. Sometimes it's the grafic
card, if before the crash I was in grafic mode.
If you then reboot again, even 10 times, then the same
happens. It crashs again at the ata1 stage, or short
after. Even if I use the reboot button, or switch off the
computer completely. Thus, something is changed by the
1st crash, and stays changed even after re-booting or
power-off.
This stops only, if I wait 5 minutes or more (what
suggests that the 1st crash let something memory-resident
what causes the next crashs). Or, if I boot with a
stable kernel (2.6.38.3) which don't crash. Then,
2.6.39-rcX don't crash again at the ata1 stage, but later
just like the 1st time (currently, if I unzip or copy a
big file), however after this, subsequently it crashs
again at the ata1 state, i.e. the same problem repeats.
I have no other tools, the only what I can do is, to make
screen fotos.
Also, I imediately compile all new -git's . Thus, it's
difficult to go back, to reproduce / repeat an error. But
I'll try to make more fotos.
BUT THE KERNEL PEOPLE FINALLY SHOULD INCLUDE, THAT DMESG
AT EACH BOOT GET ANOTHER SUFFIX, OR THE OLD DMESG GET A
COPY dmesg.old, SO THAT AFTER A CRASH ONE CAN READ DMESG
WITHOUT IT WAS OVERWROTEN !!!!!!
In a separate mail, I'll send two more screen shots of
crashs.
W.Landgraf
===============================================================
On Fri, 22 Apr 2011 20:35:25 +0200
Tejun Heo <tj@xxxxxxxxxx> wrote:
Hello, werner.
On Sun, Apr 17, 2011 at 02:38:58AM -0400, werner wrote:
Enclosed pls find a screen foto of another crash with
this
reset-resistent problem.
What do you mean by reset-resistant?
As said, after patching blk and scsi in 2.6.39-rc3-git4
as someone
suggested me to try out, happened crashs short or
longer time after
booting, which caused a rather early crash during
subsequent boots,
which don't go away even after re-set or power-off, and
occurs
again and again with 2.6.39-rcX . This goes away only
if I boot
with 2.6.38.2 or .3 ; in this case, if after this I boot
again with
2.6.39-rc3-git4+patches, then repeats the same, i.e. the
first time
it crashs only after the end of booting, but
subsequently again in
the early stage.
I think this is a khugepaged problem, or that the
computer wrongly
interpretes the video card or anything else as an scsi
or blk
device. At least subjectively, the sticking after
booting is very
similar to the khugepaged problem which I reclaimed
during
2.6.38-rc1 (or was it .37-rc1 ), and which then was
corrected, but
perhaps it wasn't corrected really and now comes back.
Unfortunately, I can't really make much sense of your
report and the
screenshot seems already deep into multiple failures
making it very
difficult to tell what initiated the whole situation.
As Jens
requested before, can you please setup serial or
netconsole and try to
capture the full kernel log from boot to crash?
Thank you.
--
tejun
"werner" <w.landgraf@xxxxx>
---
Professional hosting for everyone - http://www.host.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
