linux-kernel - Re: Kernel panic on HT machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201106162345.16305.marogge@onlinehome.de>
Date:	Thu, 16 Jun 2011 23:45:16 +0200
From:	Martin <marogge@...inehome.de>
To:	wzab@....pw.edu.pl
Cc:	"vger.kernel.org, " <linux-kernel@...r.kernel.org>
Subject: Re: Kernel panic on HT machine - maybe i915 related?

On Thursday 16 June 2011 13:41:04 Wojciech Zabołotny wrote:
> W dniu 15.06.2011 22:24, Martin wrote:
> > Same here, although my panics look different from yours. In both cases I
> > had a lot of hardware interrupts on the stack trace but no kmemcheck. I
> > only remembered to take a photo with my mobile phone the second time.
> > The stack trace contains handle_*irq*, tg3, ata_bmdma, __ata_sff, i915,
> > drm_vblank_put, intel_thermal, try_preempt, resched*, drm_vblank_put,
> > do_invalid_op, oops_end, do_bounds, panic. The EIP is
> > drm_vblank_put+0x13/0x50.
> 
> Probably you have not enabled kmemcheck in the kernel configuration?

good point. ;)

> 
> > Could this be an i915 issue with 2.6.39.1? At home I have two other
> > machines on i915 but with different chipsets that run fine with the same
> > kernel.
> 
> The i915 driver with 82865G chipset works strange for quite a long time
> (since 2.6.37???) The machine which causes problem uses this chipset.
> Another one which works good with 2.6.39.1 (I write this message on it)
> uses: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
> Graphics Controller (rev 03)
> 

I had i915 weirdness with different chipsets at different times. Other than 
the oops happening in drm_vblank_put it occurred to me that a random X 
screensaver must have been active when it happened.

I didn't manage to trigger the panic over night with the problematic kernel in 
runlevel 3 (console), nor did it occur with a vanilla 2.6.39.1 during the day. 
I shall have to continue testing.

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