Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Andrew Morton
On Tue, 31 Jul 2007 11:25:26 +0900 Fernando Luis Vázquez Cao <[EMAIL PROTECTED]> wrote: > > runtime. Some drivers don't get used by many people and users of some > > architectures (esp embedded) tend to lag kernel.org by a long time. So it > > could be years before all the fallout from this

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Fernando Luis Vázquez Cao
On Mon, 2007-07-30 at 11:22 -0700, Andrew Morton wrote: > On Mon, 30 Jul 2007 18:58:14 +0900 > Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote: > > > > > > > So bad things might happen because of this change. And if they do, they > > > will take a lng time to be discovered, because

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Andrew Morton
On Mon, 30 Jul 2007 18:58:14 +0900 Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote: > > > > So bad things might happen because of this change. And if they do, they > > will take a lng time to be discovered, because non-shared interrupt > > handlers tend to dwell in crufty old drivers

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Fernando Luis Vázquez Cao
On Fri, 2007-07-20 at 14:43 -0700, Andrew Morton wrote: > On Fri, 20 Jul 2007 11:20:43 +0900 > Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote: > > > With the advent of kdump it is possible that device drivers receive > > interrupts generated in the context of a previous kernel. Ideally > >

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Fernando Luis Vázquez Cao
On Fri, 2007-07-20 at 14:43 -0700, Andrew Morton wrote: On Fri, 20 Jul 2007 11:20:43 +0900 Fernando Luis V__zquez Cao [EMAIL PROTECTED] wrote: With the advent of kdump it is possible that device drivers receive interrupts generated in the context of a previous kernel. Ideally quiescing

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Andrew Morton
On Mon, 30 Jul 2007 18:58:14 +0900 Fernando Luis V__zquez Cao [EMAIL PROTECTED] wrote: So bad things might happen because of this change. And if they do, they will take a lng time to be discovered, because non-shared interrupt handlers tend to dwell in crufty old drivers which not

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Fernando Luis Vázquez Cao
On Mon, 2007-07-30 at 11:22 -0700, Andrew Morton wrote: On Mon, 30 Jul 2007 18:58:14 +0900 Fernando Luis V__zquez Cao [EMAIL PROTECTED] wrote: So bad things might happen because of this change. And if they do, they will take a lng time to be discovered, because non-shared

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-30 Thread Andrew Morton
On Tue, 31 Jul 2007 11:25:26 +0900 Fernando Luis Vázquez Cao [EMAIL PROTECTED] wrote: runtime. Some drivers don't get used by many people and users of some architectures (esp embedded) tend to lag kernel.org by a long time. So it could be years before all the fallout from this change is

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-20 Thread Andrew Morton
On Fri, 20 Jul 2007 11:20:43 +0900 Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote: > With the advent of kdump it is possible that device drivers receive > interrupts generated in the context of a previous kernel. Ideally > quiescing the underlying devices should suffice but not all drivers

Re: [PATCH 2/2] Debug handling of early spurious interrupts

2007-07-20 Thread Andrew Morton
On Fri, 20 Jul 2007 11:20:43 +0900 Fernando Luis V__zquez Cao [EMAIL PROTECTED] wrote: With the advent of kdump it is possible that device drivers receive interrupts generated in the context of a previous kernel. Ideally quiescing the underlying devices should suffice but not all drivers do

[PATCH 2/2] Debug handling of early spurious interrupts

2007-07-19 Thread Fernando Luis Vázquez Cao
With the advent of kdump it is possible that device drivers receive interrupts generated in the context of a previous kernel. Ideally quiescing the underlying devices should suffice but not all drivers do this, either because it is not possible or because they did not contemplate this case. Thus

[PATCH 2/2] Debug handling of early spurious interrupts

2007-07-19 Thread Fernando Luis Vázquez Cao
With the advent of kdump it is possible that device drivers receive interrupts generated in the context of a previous kernel. Ideally quiescing the underlying devices should suffice but not all drivers do this, either because it is not possible or because they did not contemplate this case. Thus