On Wed, Jul 1, 2015 at 9:26 AM, Rui Wang wrote:
> On Tuesday, June 30, 2015 11:24 PM, Daniel Vetter
> wrote:
>> On Tue, Jun 30, 2015 at 9:23 AM, Rui Wang wrote:
>> > But einj does something more than what an IPI can do, it injects hardware
>> > errors which trigger exceptions in NMI context...
On Tuesday, June 30, 2015 11:24 PM, Daniel Vetter
wrote:
> On Tue, Jun 30, 2015 at 9:23 AM, Rui Wang wrote:
> > But einj does something more than what an IPI can do, it injects hardware
> > errors which trigger exceptions in NMI context... and the exception handler
> > usually panics on fatal er
On Tue, Jun 30, 2015 at 9:23 AM, Rui Wang wrote:
> On Tuesday, June 30, 2015 2:37 PM, Daniel Vetter
> wrote:
>> On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang wrote:
>> >
>> > I think testing can be done by injecting a fatal machine check
>> > exception via einj's debugfs interface. I can reproduce
On Tuesday, June 30, 2015 2:37 PM, Daniel Vetter wrote:
> On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang wrote:
> >
> > I think testing can be done by injecting a fatal machine check
> > exception via einj's debugfs interface. I can reproduce the hard hang every
> time.
> > I think It can be a simple
On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang wrote:
> On Monday, June 29, 2015 5:25 PM, Daniel Vetter
> wrote:
>> As long as the display is up and running we should have a fair stab at
>> showing the oops - it's just that no one has seriously bothered with
>> the necessary infastructure, automated
On Monday, June 29, 2015 5:25 PM, Daniel Vetter wrote:
> As long as the display is up and running we should have a fair stab at
> showing the oops - it's just that no one has seriously bothered with
> the necessary infastructure, automated testing (it won't work
> otherwise) and driver work.
I th
On Mon, Jun 29, 2015 at 11:42 AM, Borislav Petkov wrote:
>> drm_fb_helper_panic isn't the only panic handler - fbdev/fbcon have
>> their own. They interfere, and fbdev blissfully assumes that it can
>> call almost any driver hook from hardirq context. Which means you'd
>> also need to consolidate
On Mon, Jun 29, 2015 at 11:25:17AM +0200, Daniel Vetter wrote:
> As long as the display is up and running we should have a fair stab at
> showing the oops
Yeah, that has the same problem as all the other methods for showing
oops - *if* it is still healthly. Like, for example, trying to catch an
oo
On Mon, Jun 29, 2015 at 10:09 AM, Borislav Petkov wrote:
> On Sat, Jun 27, 2015 at 07:56:19PM +0200, Daniel Vetter wrote:
>
>
>
>> Which could all happen very much after the kernel made it's dying
>> sigh. Display hw has long stopped being this simple and display
>> drivers also.
>
> Thanks for t
On Sat, Jun 27, 2015 at 07:56:19PM +0200, Daniel Vetter wrote:
> Which could all happen very much after the kernel made it's dying
> sigh. Display hw has long stopped being this simple and display
> drivers also.
Thanks for the explanation. I was fearing that it would go in such
direction thoug
On Sat, Jun 27, 2015 at 4:12 PM, Borislav Petkov wrote:
> On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote:
>> Hm, what do you mean by fixing this in the allocator? I've made some
>> rough sketch of the problem space in
>> http://www.x.org/wiki/DRMJanitors/ under "Make panic handling
On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote:
> Hm, what do you mean by fixing this in the allocator? I've made some
> rough sketch of the problem space in
> http://www.x.org/wiki/DRMJanitors/ under "Make panic handling work".
> Problem is that the folks which know what to do (drm
On Fri, Jun 26, 2015 at 8:30 PM, Luck, Tony wrote:
>>> I'm here to report two panics which hang forever (the machine cannot
>>> reboot). It is because mgag200 doesn't work in panic context. It sleeps and
>>> allocates memory non-atomically.
>>
>> This is the same for all drm drivers, the drm ato
>> I'm here to report two panics which hang forever (the machine cannot
>> reboot). It is because mgag200 doesn't work in panic context. It sleeps and
>> allocates memory non-atomically.
>
> This is the same for all drm drivers, the drm atomic handling with
> fbcon/fbdev is totally broken. It wou
On Fri, Jun 26, 2015 at 9:55 AM, Rui Wang wrote:
> Hi all,
>
> I'm here to report two panics which hang forever (the machine cannot reboot).
> It is because mgag200 doesn't work in panic context. It sleeps and allocates
> memory non-atomically.
This is the same for all drm drivers, the drm atom
Hi all,
I'm here to report two panics which hang forever (the machine cannot reboot).
It is because mgag200 doesn't work in panic context. It sleeps and allocates
memory non-atomically.
These were triggered while injecting machine checks using einj.
1)
[321381.466885] [ cut here ]
16 matches
Mail list logo
