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
15 matches
Mail list logo
