2.6.39-rc3-git3 problem etc , reset-resistent problem

2.6.39-rc3-git3 problem etc , reset-resistent problem

[werner]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]



Pls see the enclosed screen foto.

After the crashs of 2.6.39-rcX , which I already 
reclaimed, and after -rc3-git4 and the patch suggested me 
to try out, the computer in vesa grafic mode crashs 
quickly, in fbdev only after longer time.     After this 
crash, on re-booting, happens early during  the boot 
process a next kind of  crash.   This don't go away on 
reset nor on power off, i.e. booting 
2.6.39-rc3-git4-patchs  again, it repeats.    Only after 
rebooting with 2.6.38.2 or another working kernel, one can 
booting again with 2.6.39-rc3-git4-patchs -- until after 
its next crash, when the same happens again.

Some of these secondary crashs show a message:   ata1: 
 nv: stopping hardreset on occupied port,    and after 
this the system attempts wrongly to understand the nv 
grafic card as a hard disc, and claims about read errors, 
until it crash.

Some of these secondary crashs, instead, look like the 
enclosed foto, also understanding something wrongly as an 
ata1 device.


I hope someone can find and correct that error.


W.Landgraf
---
Professional hosting for everyone - http://www.host.ru

[-- Attachment #2: Foto0049.jpg --]
[-- Type: image/jpeg, Size: 184750 bytes --]

Re: 2.6.39-rc3-git3 problem etc , reset-resistent problem

[Jens Axboe]

On 2011-04-16 06:22, werner wrote:
> 
> 
> Pls see the enclosed screen foto.
> 
> After the crashs of 2.6.39-rcX , which I already 
> reclaimed, and after -rc3-git4 and the patch suggested me 
> to try out, the computer in vesa grafic mode crashs 
> quickly, in fbdev only after longer time.     After this 
> crash, on re-booting, happens early during  the boot 
> process a next kind of  crash.   This don't go away on 
> reset nor on power off, i.e. booting 
> 2.6.39-rc3-git4-patchs  again, it repeats.    Only after 
> rebooting with 2.6.38.2 or another working kernel, one can 
> booting again with 2.6.39-rc3-git4-patchs -- until after 
> its next crash, when the same happens again.
> 
> Some of these secondary crashs show a message:   ata1: 
>  nv: stopping hardreset on occupied port,    and after 
> this the system attempts wrongly to understand the nv 
> grafic card as a hard disc, and claims about read errors, 
> until it crash.
> 
> Some of these secondary crashs, instead, look like the 
> enclosed foto, also understanding something wrongly as an 
> ata1 device.

Any chance you can setup a network console or serial console and capture
all of those messages?

-- 
Jens Axboe

2.6.39-rc3-git3 problem etc , reset-resistent problem

[werner]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

Enclosed pls find a screen foto of another crash with this 
reset-resistent problem.

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.

W.Landgraf
---
Professional hosting for everyone - http://www.host.ru

[-- Attachment #2: Foto0050.jpg --]
[-- Type: image/jpeg, Size: 188550 bytes --]

Re: 2.6.39-rc3-git3 problem etc , reset-resistent problem

[Tejun Heo]

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

Re: 2.6.39-rc3-git3 problem etc , reset-resistent problem

[werner]

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@kernel.org> 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@ru.ru>
---
Professional hosting for everyone - http://www.host.ru