Andi Kleen <[EMAIL PROTECTED]> writes:
> On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
>>
>> Ok, new patch attached, taking into account Andi's request for a cleaner
> method
>
> Sorry for not noticing that earlier, but was there a specific reason this
> needs
> to be an early
On Mon, Dec 17, 2007 at 04:16:42PM +0100, Ingo Molnar wrote:
>
> * Neil Horman <[EMAIL PROTECTED]> wrote:
>
> > Ok, new patch attached, taking into account Andi's request for a
> > cleaner method to implement single application quirks. I've spoken
> > with Ben, who is continuing to retest,
* Neil Horman <[EMAIL PROTECTED]> wrote:
> Ok, new patch attached, taking into account Andi's request for a
> cleaner method to implement single application quirks. I've spoken
> with Ben, who is continuing to retest, and reports that clean
> methodical testing results in success with this
On Thu, Dec 13, 2007 at 10:32:22AM -0500, Neil Horman wrote:
> On Thu, Dec 13, 2007 at 04:16:29PM +0100, Andi Kleen wrote:
> > On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
> > >
> > > Ok, new patch attached, taking into account Andi's request for a cleaner
> > > method
> >
> >
On Thu, Dec 13, 2007 at 10:32:22AM -0500, Neil Horman wrote:
On Thu, Dec 13, 2007 at 04:16:29PM +0100, Andi Kleen wrote:
On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
Ok, new patch attached, taking into account Andi's request for a cleaner
method
Sorry for not
* Neil Horman [EMAIL PROTECTED] wrote:
Ok, new patch attached, taking into account Andi's request for a
cleaner method to implement single application quirks. I've spoken
with Ben, who is continuing to retest, and reports that clean
methodical testing results in success with this patch.
On Mon, Dec 17, 2007 at 04:16:42PM +0100, Ingo Molnar wrote:
* Neil Horman [EMAIL PROTECTED] wrote:
Ok, new patch attached, taking into account Andi's request for a
cleaner method to implement single application quirks. I've spoken
with Ben, who is continuing to retest, and reports
Andi Kleen [EMAIL PROTECTED] writes:
On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
Ok, new patch attached, taking into account Andi's request for a cleaner
method
Sorry for not noticing that earlier, but was there a specific reason this
needs
to be an early quirk at all?
On Thu, Dec 13, 2007 at 04:16:29PM +0100, Andi Kleen wrote:
> On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
> >
> > Ok, new patch attached, taking into account Andi's request for a cleaner
> > method
>
> Sorry for not noticing that earlier, but was there a specific reason this
>
On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
>
> Ok, new patch attached, taking into account Andi's request for a cleaner
> method
Sorry for not noticing that earlier, but was there a specific reason this needs
to be an early quirk at all? kexec can only happen after the
Ok, new patch attached, taking into account Andi's request for a cleaner method
to implement single application quirks. I've spoken with Ben, who is continuing
to retest, and reports that clean methodical testing results in success with
this patch.
Summary:
Recently a kdump bug was discovered
Ok, new patch attached, taking into account Andi's request for a cleaner method
to implement single application quirks. I've spoken with Ben, who is continuing
to retest, and reports that clean methodical testing results in success with
this patch.
Summary:
Recently a kdump bug was discovered
On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
Ok, new patch attached, taking into account Andi's request for a cleaner
method
Sorry for not noticing that earlier, but was there a specific reason this needs
to be an early quirk at all? kexec can only happen after the standard
On Thu, Dec 13, 2007 at 04:16:29PM +0100, Andi Kleen wrote:
On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
Ok, new patch attached, taking into account Andi's request for a cleaner
method
Sorry for not noticing that earlier, but was there a specific reason this
needs
to
Neil Horman <[EMAIL PROTECTED]> writes:
> I think this just leaves us with deciding on a mechanism for how to do
> single-application quirks. I take Andi's point that adding a flag set to the
> quirk data structure is a fine solution, but I'm really ok with static
> integers
> in individual
On Wed, Dec 12, 2007 at 12:43:34PM -0700, Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
> >
> > It could enable the extended APIC IDs but not use them?
>
> In which case complaining is still correct (the BIOS was out of sync),
> enabling bit 17 is still correct and we are
Andi Kleen <[EMAIL PROTECTED]> writes:
>
> It could enable the extended APIC IDs but not use them?
In which case complaining is still correct (the BIOS was out of sync),
enabling bit 17 is still correct and we are just in overkill mode.
> Anyways I haven't got docs on that NV bridge so I might
On Wed, Dec 12, 2007 at 10:55:15AM -0500, Neil Horman wrote:
> On Wed, Dec 12, 2007 at 03:21:32PM +0100, Andi Kleen wrote:
> > > + htcfg = read_pci_config(num, slot, func, 0x68);
> > > + if (htcfg & (1 << 18)) {
> > > + printk(KERN_INFO "Detected use of extended apic ids on
> > >
On Wed, Dec 12, 2007 at 03:21:32PM +0100, Andi Kleen wrote:
> > + htcfg = read_pci_config(num, slot, func, 0x68);
> > + if (htcfg & (1 << 18)) {
> > + printk(KERN_INFO "Detected use of extended apic ids on
> > hypertransport bus\n");
> > + if ((htcfg & (1 << 17))
> + htcfg = read_pci_config(num, slot, func, 0x68);
> + if (htcfg & (1 << 18)) {
> + printk(KERN_INFO "Detected use of extended apic ids on
> hypertransport bus\n");
> + if ((htcfg & (1 << 17)) == 0) {
> + printk(KERN_INFO "Enabling
+ htcfg = read_pci_config(num, slot, func, 0x68);
+ if (htcfg (1 18)) {
+ printk(KERN_INFO Detected use of extended apic ids on
hypertransport bus\n);
+ if ((htcfg (1 17)) == 0) {
+ printk(KERN_INFO Enabling hypertransport
On Wed, Dec 12, 2007 at 03:21:32PM +0100, Andi Kleen wrote:
+ htcfg = read_pci_config(num, slot, func, 0x68);
+ if (htcfg (1 18)) {
+ printk(KERN_INFO Detected use of extended apic ids on
hypertransport bus\n);
+ if ((htcfg (1 17)) == 0) {
+
On Wed, Dec 12, 2007 at 10:55:15AM -0500, Neil Horman wrote:
On Wed, Dec 12, 2007 at 03:21:32PM +0100, Andi Kleen wrote:
+ htcfg = read_pci_config(num, slot, func, 0x68);
+ if (htcfg (1 18)) {
+ printk(KERN_INFO Detected use of extended apic ids on
hypertransport
Andi Kleen [EMAIL PROTECTED] writes:
It could enable the extended APIC IDs but not use them?
In which case complaining is still correct (the BIOS was out of sync),
enabling bit 17 is still correct and we are just in overkill mode.
Anyways I haven't got docs on that NV bridge so I might be
On Wed, Dec 12, 2007 at 12:43:34PM -0700, Eric W. Biederman wrote:
Andi Kleen [EMAIL PROTECTED] writes:
It could enable the extended APIC IDs but not use them?
In which case complaining is still correct (the BIOS was out of sync),
enabling bit 17 is still correct and we are just in
Neil Horman [EMAIL PROTECTED] writes:
I think this just leaves us with deciding on a mechanism for how to do
single-application quirks. I take Andi's point that adding a flag set to the
quirk data structure is a fine solution, but I'm really ok with static
integers
in individual functions.
On Dec 11, 2007 4:52 PM, Neil Horman <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 11, 2007 at 04:16:32PM -0800, Ben Woodard wrote:
> > We may need to go back and do some additional work on this. It doesn't
> > seem to be quite as cut and dried as we initially thought.
> >
> > This quirk doesn't appear
On Tue, Dec 11, 2007 at 04:16:32PM -0800, Ben Woodard wrote:
> We may need to go back and do some additional work on this. It doesn't
> seem to be quite as cut and dried as we initially thought.
>
> This quirk doesn't appear to work on virtually the same motherboard with
> the barcelona
We may need to go back and do some additional work on this. It doesn't
seem to be quite as cut and dried as we initially thought.
This quirk doesn't appear to work on virtually the same motherboard with
the barcelona processors in it. It also may be sensitive to the firmware
version. More
Recently a kdump bug was discovered in which a system would hang inside
calibrate_delay during the booting of the kdump kernel. This was caused by the
fact that the jiffies counter was not being incremented during timer
calibration. The root cause of this problem was found to be a bios
On Dec 11, 2007 11:24 AM, Neil Horman <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 11, 2007 at 11:46:34AM -0700, Eric W. Biederman wrote:
> > Neil Horman <[EMAIL PROTECTED]> writes:
> >
> > Ok. My only remaining nit to pick is that fix_hypertransport_config
> > is right in the middle of the nvidia
On Tue, Dec 11, 2007 at 11:46:34AM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> Ok. My only remaining nit to pick is that fix_hypertransport_config
> is right in the middle of the nvidia quirks, which can be a bit
> confusing when reading through the code.
Neil Horman <[EMAIL PROTECTED]> writes:
> On Tue, Dec 11, 2007 at 08:29:20AM -0700, Eric W. Biederman wrote:
>> Neil Horman <[EMAIL PROTECTED]> writes:
>>
>> > On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
>> >> Neil Horman <[EMAIL PROTECTED]> writes:
>>
>> Ok. I just
On Dec 11, 2007 10:29 AM, Neil Horman <[EMAIL PROTECTED]> wrote:
>
> On Tue, Dec 11, 2007 at 10:00:00AM -0800, Yinghai Lu wrote:
> > On Dec 11, 2007 7:29 AM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > >
> > > I'm actually inclined to remove the return magic and just do something
> > > like:
On Tue, Dec 11, 2007 at 10:00:00AM -0800, Yinghai Lu wrote:
> On Dec 11, 2007 7:29 AM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> > Neil Horman <[EMAIL PROTECTED]> writes:
> >
> > > On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
> > >> Neil Horman <[EMAIL PROTECTED]>
On Tue, Dec 11, 2007 at 08:29:20AM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> > On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
> >> Neil Horman <[EMAIL PROTECTED]> writes:
>
> Ok. I just looked at read_pci_config. It doesn't do the right
On Dec 11, 2007 7:29 AM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> > On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
> >> Neil Horman <[EMAIL PROTECTED]> writes:
> >>
> >> Almost there.
> > cool! :)
> >
> >
> >>
> >> We should
Neil Horman <[EMAIL PROTECTED]> writes:
> On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
>> Neil Horman <[EMAIL PROTECTED]> writes:
>>
>> Almost there.
> cool! :)
>
>
>>
>> We should not need check_hypertransport_config as the generic loop
>> now does the work for us.
>> >
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> Almost there.
cool! :)
>
> We should not need check_hypertransport_config as the generic loop
> now does the work for us.
> > +
> > static void __init nvidia_bugs(void)
> > {
> >
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
cool! :)
snip
We should not need check_hypertransport_config as the generic loop
now does the work for us.
+
static void __init nvidia_bugs(void)
{
#ifdef
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
cool! :)
snip
We should not need check_hypertransport_config as the generic loop
now does the work for us.
+
static void
On Dec 11, 2007 7:29 AM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
cool! :)
snip
We should not need
On Tue, Dec 11, 2007 at 08:29:20AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Ok. I just looked at read_pci_config. It doesn't do the right thing for
a
On Tue, Dec 11, 2007 at 10:00:00AM -0800, Yinghai Lu wrote:
On Dec 11, 2007 7:29 AM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost
On Dec 11, 2007 10:29 AM, Neil Horman [EMAIL PROTECTED] wrote:
On Tue, Dec 11, 2007 at 10:00:00AM -0800, Yinghai Lu wrote:
On Dec 11, 2007 7:29 AM, Eric W. Biederman [EMAIL PROTECTED] wrote:
I'm actually inclined to remove the return magic and just do something
like:
static
Neil Horman [EMAIL PROTECTED] writes:
On Tue, Dec 11, 2007 at 08:29:20AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Ok. I just looked at read_pci_config.
On Tue, Dec 11, 2007 at 11:46:34AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Ok. My only remaining nit to pick is that fix_hypertransport_config
is right in the middle of the nvidia quirks, which can be a bit
confusing when reading through the code. Otherwise I
On Dec 11, 2007 11:24 AM, Neil Horman [EMAIL PROTECTED] wrote:
On Tue, Dec 11, 2007 at 11:46:34AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Ok. My only remaining nit to pick is that fix_hypertransport_config
is right in the middle of the nvidia quirks, which
Recently a kdump bug was discovered in which a system would hang inside
calibrate_delay during the booting of the kdump kernel. This was caused by the
fact that the jiffies counter was not being incremented during timer
calibration. The root cause of this problem was found to be a bios
We may need to go back and do some additional work on this. It doesn't
seem to be quite as cut and dried as we initially thought.
This quirk doesn't appear to work on virtually the same motherboard with
the barcelona processors in it. It also may be sensitive to the firmware
version. More
On Tue, Dec 11, 2007 at 04:16:32PM -0800, Ben Woodard wrote:
We may need to go back and do some additional work on this. It doesn't
seem to be quite as cut and dried as we initially thought.
This quirk doesn't appear to work on virtually the same motherboard with
the barcelona processors
On Dec 11, 2007 4:52 PM, Neil Horman [EMAIL PROTECTED] wrote:
On Tue, Dec 11, 2007 at 04:16:32PM -0800, Ben Woodard wrote:
We may need to go back and do some additional work on this. It doesn't
seem to be quite as cut and dried as we initially thought.
This quirk doesn't appear to work on
On Dec 10, 2007 8:48 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> Almost there.
>
>
>
> > On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
> >> Neil Horman <[EMAIL PROTECTED]> writes:
> >>
> >
> >>
> >> Ok. This test is broken.
Neil Horman <[EMAIL PROTECTED]> writes:
Almost there.
> On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
>> Neil Horman <[EMAIL PROTECTED]> writes:
>>
>
>>
>> Ok. This test is broken. Please remove the == 1. You are looking
>> for == (1 << 18). So just saying: "if
On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
>
> Ok. This test is broken. Please remove the == 1. You are looking
> for == (1 << 18). So just saying: "if (htcfg & (1 << 18))" should be clearer.
>
Fixed. Thanks!
> > +
> Sorry to reply to myself, but do we have consensus on this patch? I'd like to
> figure out its disposition if possible.
What the patch tries to do looks like the right thing. So if we can get
a version that is clean and actually works we should merge it.
Eric
--
To unsubscribe from this
Neil Horman <[EMAIL PROTECTED]> writes:
> On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
>> On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
>> > On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
>> > >
>> > > On Dec 6, 2007 4:33 PM, Eric W. Biederman <[EMAIL
On Mon, Dec 10, 2007 at 10:39:59AM -0500, Neil Horman wrote:
> On Fri, Dec 07, 2007 at 12:58:32PM -0500, Neil Horman wrote:
> >
> > Ok, New patch attached. It preforms the same function as previously
> > described,
> > but is more restricted in its application. As Yinghai pointed out, the
> >
On Fri, Dec 07, 2007 at 12:58:32PM -0500, Neil Horman wrote:
>
> Ok, New patch attached. It preforms the same function as previously
> described,
> but is more restricted in its application. As Yinghai pointed out, the
> broadcast mask bit (bit 17 in the htcfg register) should only be enabled,
On Fri, Dec 07, 2007 at 12:58:32PM -0500, Neil Horman wrote:
Ok, New patch attached. It preforms the same function as previously
described,
but is more restricted in its application. As Yinghai pointed out, the
broadcast mask bit (bit 17 in the htcfg register) should only be enabled, if
On Mon, Dec 10, 2007 at 10:39:59AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 12:58:32PM -0500, Neil Horman wrote:
Ok, New patch attached. It preforms the same function as previously
described,
but is more restricted in its application. As Yinghai pointed out, the
broadcast
Neil Horman [EMAIL PROTECTED] writes:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Sorry to reply to myself, but do we have consensus on this patch? I'd like to
figure out its disposition if possible.
What the patch tries to do looks like the right thing. So if we can get
a version that is clean and actually works we should merge it.
Eric
--
To unsubscribe from this
On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
snip
Ok. This test is broken. Please remove the == 1. You are looking
for == (1 18). So just saying: if (htcfg (1 18)) should be clearer.
Fixed. Thanks!
+ printk(KERN_INFO
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
snip
Ok. This test is broken. Please remove the == 1. You are looking
for == (1 18). So just saying: if (htcfg (1 18))
On Dec 10, 2007 8:48 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
snip
Ok. This test is broken. Please remove the == 1.
On Fri, Dec 07, 2007 at 11:19:10AM -0800, yhlu wrote:
> On Dec 7, 2007 9:58 AM, Neil Horman <[EMAIL PROTECTED]> wrote:
> > On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
> > > On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
> > > > On Dec 7, 2007 12:50 AM, Yinghai Lu
On Dec 7, 2007 9:58 AM, Neil Horman <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
> > On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
> > > On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Dec 6, 2007 4:33 PM,
Neil Horman <[EMAIL PROTECTED]> writes:
> this seems reasonable, I can reroll the patch for this. As I think about it
> I'm
> also going to update the patch to make this check occur for any pci class 0600
> device from vendor AMD, since its possible that more than just nvidia chipsets
> can be
On Fri, Dec 07, 2007 at 11:36:58AM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> > this seems reasonable, I can reroll the patch for this. As I think about
> > it I'm
> > also going to update the patch to make this check occur for any pci class
> > 0600
> >
Neil Horman <[EMAIL PROTECTED]> writes:
>> Does LAPIC allow to disable a specific vector and not accept interrupts? I
>> don't think so. If a timer interrupt is broadcasted to every cpu I think
>> everybody will accept it (like broadcast IPI). That's why intelligence
>> is built into IOAPIC and
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
> On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
> > On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 6, 2007 4:33 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > ...
> > > >
> > > > My
On Fri, Dec 07, 2007 at 10:16:23AM -0500, Vivek Goyal wrote:
> On Fri, Dec 07, 2007 at 09:53:15AM -0500, Neil Horman wrote:
> > On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
> > > On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
> > > > On Thu, Dec 06, 2007 at 05:11:43PM
On Fri, Dec 07, 2007 at 09:53:15AM -0500, Neil Horman wrote:
> On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
> > On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
> > > On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
> > > > On Thu, Dec 06, 2007 at 04:39:51PM
On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
> On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
> > On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
> > > On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
> > > > On Fri, Nov 30, 2007 at 09:51:31AM
On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
> On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
> > On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
> > > On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
> > > > On Fri, Nov 30, 2007 at 09:42:50AM
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
> On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 6, 2007 4:33 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> ...
> > >
> > > My feel is that if it is for legacy interrupts only it should not be a
> > >
On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> On Dec 6, 2007 4:33 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
...
> >
> > My feel is that if it is for legacy interrupts only it should not be a
> > problem.
> > Let's investigate and see if we can unconditionally enable
On Dec 6, 2007 4:33 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
>
> > On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
> >> On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
> >> > On Fri, Nov 30, 2007 at 09:42:50AM -0500,
On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500,
On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500,
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
...
My feel is that if it is for legacy interrupts only it should not be a
problem.
Let's
On Fri, Dec 07, 2007 at 10:16:23AM -0500, Vivek Goyal wrote:
On Fri, Dec 07, 2007 at 09:53:15AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
On Thu, Dec 06, 2007 at 05:11:43PM -0500,
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
...
My feel is that if it is for legacy interrupts only it should not be a
problem.
Let's investigate and see if we can unconditionally enable this quirk
for
On Fri, Dec 07, 2007 at 09:53:15AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 04:39:51PM -0500,
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
...
My feel is that if it is
Neil Horman [EMAIL PROTECTED] writes:
this seems reasonable, I can reroll the patch for this. As I think about it
I'm
also going to update the patch to make this check occur for any pci class 0600
device from vendor AMD, since its possible that more than just nvidia chipsets
can be
On Fri, Dec 07, 2007 at 11:36:58AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
this seems reasonable, I can reroll the patch for this. As I think about
it I'm
also going to update the patch to make this check occur for any pci class
0600
device from vendor
Neil Horman [EMAIL PROTECTED] writes:
Does LAPIC allow to disable a specific vector and not accept interrupts? I
don't think so. If a timer interrupt is broadcasted to every cpu I think
everybody will accept it (like broadcast IPI). That's why intelligence
is built into IOAPIC and direct
On Fri, Dec 07, 2007 at 11:19:10AM -0800, yhlu wrote:
On Dec 7, 2007 9:58 AM, Neil Horman [EMAIL PROTECTED] wrote:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL
On Dec 7, 2007 9:58 AM, Neil Horman [EMAIL PROTECTED] wrote:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman
On Thu, Dec 06, 2007 at 05:33:31PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
> >> On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
> >> > On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
>> On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
>> > On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
>>
>> >
>> > Thats what I'm doing at the moment. I'm working
On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
> On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
> > On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
> > > On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
> >
> > >
> > > Thats what I'm doing at
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
> On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
> > On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
>
> >
> > Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the
> > moment
> > (since
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
> On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
>
> Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the
> moment
> (since thats whats on the production system thats failing), and will forward
> port
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
snip
Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the
moment
(since thats whats on the production system thats failing), and will forward
port
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
snip
Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the
moment
(since thats
Vivek Goyal [EMAIL PROTECTED] writes:
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
snip
Thats what I'm doing at the moment. I'm working on a RHEL5
1 - 100 of 198 matches
Mail list logo
