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 qui
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
* 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 pa
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
> >
> > So
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 standard
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
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 func
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
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 b
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
> > > h
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 hyper
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 processo
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 ext
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
misconfigu
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 quir
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. Otherwi
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 looke
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]> wri
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 th
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 n
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 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 (htcfg
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!
> > + printk
> 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 lis
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
> > b
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 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 <[EMA
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 a
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
> > devic
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 di
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 f
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
> > > p
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 thi
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, Vive
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 G
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 o
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 t
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 th
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:42:50AM -0500, Vivek Goyal wrote:
> [..]
> >> Can you print the LAPIC registers (print_local_APIC) during normal boot
> >> and during kdump boot and paste here?
> >
> > Here are the ones from a normal bootup.
> >
> > I was unable to get info from a kdump boot. I haven't f
[..]
>> Can you print the LAPIC registers (print_local_APIC) during normal boot
>> and during kdump boot and paste here?
>
> Here are the ones from a normal bootup.
>
> I was unable to get info from a kdump boot. I haven't figured out why yet.
> With the same patch that I used to capture this, whe
On Thu, Nov 29, 2007 at 07:54:16PM -0700, Eric W. Biederman wrote:
> Ben Woodard <[EMAIL PROTECTED]> writes:
>
> > Eric W. Biederman wrote:
> >> Vivek Goyal <[EMAIL PROTECTED]> writes:
> >>
> >>> Ok. Got it. So in this case we route the interrupts directly through LAPIC
> >>> and put LVT0 in ExtIn
On Fri, Nov 30, 2007 at 12:59:26AM -0800, Yinghai Lu wrote:
> On Nov 29, 2007 6:54 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > Ben Woodard <[EMAIL PROTECTED]> writes:
> >
> >
> > > Eric W. Biederman wrote:
> > >> Vivek Goyal <[EMAIL PROTECTED]> writes:
> > >>
> > >>> Ok. Got it. So in this
On Nov 29, 2007 6:54 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ben Woodard <[EMAIL PROTECTED]> writes:
>
>
> > Eric W. Biederman wrote:
> >> Vivek Goyal <[EMAIL PROTECTED]> writes:
> >>
> >>> Ok. Got it. So in this case we route the interrupts directly through LAPIC
> >>> and put LVT0 in E
Ben Woodard <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Vivek Goyal <[EMAIL PROTECTED]> writes:
>>
>>> Ok. Got it. So in this case we route the interrupts directly through LAPIC
>>> and put LVT0 in ExtInt mode and IOAPIC is bypassed.
>>>
>>> I am looking at Intel Multiprocessor speci
Eric W. Biederman wrote:
Vivek Goyal <[EMAIL PROTECTED]> writes:
Ok. Got it. So in this case we route the interrupts directly through LAPIC
and put LVT0 in ExtInt mode and IOAPIC is bypassed.
I am looking at Intel Multiprocessor specification v1.4 and as per figure
3-3 on page 3-9, 8259 is con
Vivek Goyal wrote:
On Wed, Nov 28, 2007 at 11:02:06AM -0500, Neil Horman wrote:
On Wed, Nov 28, 2007 at 10:36:49AM -0500, Vivek Goyal wrote:
On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
Andi Kleen wrote:
Are we putting the system back in PIC mode or virtual wire mode? I have
n
Neil Horman <[EMAIL PROTECTED]> writes:
> On Wed, Nov 28, 2007 at 12:42:22PM -0700, Eric W. Biederman wrote:
>> Vivek Goyal <[EMAIL PROTECTED]> writes:
>>
>> > Ok. Got it. So in this case we route the interrupts directly through LAPIC
>> > and put LVT0 in ExtInt mode and IOAPIC is bypassed.
>> >
On Wed, Nov 28, 2007 at 12:42:22PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > Ok. Got it. So in this case we route the interrupts directly through LAPIC
> > and put LVT0 in ExtInt mode and IOAPIC is bypassed.
> >
> > I am looking at Intel Multiprocessor specifi
Vivek Goyal <[EMAIL PROTECTED]> writes:
> Ok. Got it. So in this case we route the interrupts directly through LAPIC
> and put LVT0 in ExtInt mode and IOAPIC is bypassed.
>
> I am looking at Intel Multiprocessor specification v1.4 and as per figure
> 3-3 on page 3-9, 8259 is connected to LINTIN0 l
On Wed, Nov 28, 2007 at 11:02:06AM -0500, Neil Horman wrote:
> On Wed, Nov 28, 2007 at 10:36:49AM -0500, Vivek Goyal wrote:
> > On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
> > > Andi Kleen wrote:
> > >>> Are we putting the system back in PIC mode or virtual wire mode? I have
> > >>
On Wed, Nov 28, 2007 at 10:36:12AM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> > On Wed, Nov 28, 2007 at 10:36:49AM -0500, Vivek Goyal wrote:
> >> On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
> >> > Andi Kleen wrote:
> >> >>> Are we putting the sys
Neil Horman <[EMAIL PROTECTED]> writes:
> On Wed, Nov 28, 2007 at 10:36:49AM -0500, Vivek Goyal wrote:
>> On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
>> > Andi Kleen wrote:
>> >>> Are we putting the system back in PIC mode or virtual wire mode? I have
>> >>> not seen systems which
On Wed, Nov 28, 2007 at 10:36:49AM -0500, Vivek Goyal wrote:
> On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
> > Andi Kleen wrote:
> >>> Are we putting the system back in PIC mode or virtual wire mode? I have
> >>> not seen systems which support PIC mode. All latest systems seems
> >
On Tue, Nov 27, 2007 at 04:05:58PM -0500, Neil Horman wrote:
> On Tue, Nov 27, 2007 at 12:50:52PM -0800, Ben Woodard wrote:
> > Eric W. Biederman wrote:
> > >Neil Horman <[EMAIL PROTECTED]> writes:
> > >
> > >>So, it sounds to me then, like unless I'm willing to really re-write the
> > >>APIC
> >
On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
> Andi Kleen wrote:
>>> Are we putting the system back in PIC mode or virtual wire mode? I have
>>> not seen systems which support PIC mode. All latest systems seems
>>> to be having virtual wire mode. I think in case of PIC mode, interru
Neil Horman <[EMAIL PROTECTED]> writes:
>> Close. There are two options with virtual wire mode.
>> - Either the local apic is in virtual wire mode, and somehow the
>> legacy interrupts make it to the local cpu.
> I assume this is the case if the ioapic is also in virtual wire
> mode.
No. T
Ben Woodard <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Neil Horman <[EMAIL PROTECTED]> writes:
>>
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
>>
>> Ben, what chipset is this?
>
> nVidia MCP55 pro
>
> It is the original version of
> http://www.supermicro.com/Aplus/mothe
> Would anyone have any problems with code that simply verified that the
> state which we are restoring allowed interrupts to get to the processor
> that we are currently crashing on and if not, poked in a reasonable value.
Sounds reasonable by itself.
>
> Yes this would add some complexity to
On Tue, Nov 27, 2007 at 03:38:52PM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> >>
> >> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
>
> Ben, what chipset is this?
>
> >
> > Ok, I think from what I understand of what we're reading here, the apic2 =
> >
Andi Kleen wrote:
Are we putting the system back in PIC mode or virtual wire mode? I have
not seen systems which support PIC mode. All latest systems seems
to be having virtual wire mode. I think in case of PIC mode, interrupts
Yes it's probably virtual wire. For real PIC mode we would need rea
Eric W. Biederman wrote:
Neil Horman <[EMAIL PROTECTED]> writes:
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Ben, what chipset is this?
nVidia MCP55 pro
It is the original version of
http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm
i.e. not the -2. Howe
Neil Horman <[EMAIL PROTECTED]> writes:
>>
>> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Ben, what chipset is this?
>
> Ok, I think from what I understand of what we're reading here, the apic2 = -1
> and pin2 = -1 indicate that the 8259 has no direct connection to any cpu,
> which
>
> Are we putting the system back in PIC mode or virtual wire mode? I have
> not seen systems which support PIC mode. All latest systems seems
> to be having virtual wire mode. I think in case of PIC mode, interrupts
Yes it's probably virtual wire. For real PIC mode we would need really
old systems
On Tue, Nov 27, 2007 at 12:50:52PM -0800, Ben Woodard wrote:
> Eric W. Biederman wrote:
> >Neil Horman <[EMAIL PROTECTED]> writes:
> >
> >>So, it sounds to me then, like unless I'm willing to really re-write the
> >>APIC
> >>setup code (which I don't feel qualified to do quite yet), that the
> >>
On Tue, Nov 27, 2007 at 03:00:11PM -0500, Vivek Goyal wrote:
> On Tue, Nov 27, 2007 at 02:42:20PM -0500, Neil Horman wrote:
>
> [..]
> >
> > Ben I tend to agree. I think re-enabling the APIC early in the boot process
> > provides a greater degree of reliability in that it more quickly restores
Eric W. Biederman wrote:
Neil Horman <[EMAIL PROTECTED]> writes:
So, it sounds to me then, like unless I'm willing to really re-write the APIC
setup code (which I don't feel qualified to do quite yet), that the immediate
solution would be to not rely on interrupts in legacy mode, which was acco
On Tue, Nov 27, 2007 at 02:42:20PM -0500, Neil Horman wrote:
[..]
>
> Ben I tend to agree. I think re-enabling the APIC early in the boot process
> provides a greater degree of reliability in that it more quickly restores the
> system to a state where booting on a cpu other than cpu0 will be mor
On Tue, Nov 27, 2007 at 10:41:15AM -0800, Ben Woodard wrote:
> >>But if CPU #0 has interrupts disabled no interrupts get delivered.
> >>
> >>So choices are:
> >>- Move to CPU #0
> >>- Do not use legacy mode during shutdown.
> >(Do not use legacy mode in the kdump kernel. removing it from shutdo
Eric W. Biederman wrote:
Andi Kleen <[EMAIL PROTECTED]> writes:
his is any less reliable that what we have currently.
It doesn't make things more reliable, and it adds code to a code path
that already has to much code to be solid reliable (thus your
problem).
Putting the system back in PIC
> So, it sounds to me then, like unless I'm willing to really re-write the APIC
> setup code (which I don't feel qualified to do quite yet), that the immediate
> solution would be to not rely on interrupts in legacy mode, which was
> according
> to my understanding, what the use of the irqpoll co
On Tue, Nov 27, 2007 at 08:30:47AM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> > So, it sounds to me then, like unless I'm willing to really re-write the
> > APIC
> > setup code (which I don't feel qualified to do quite yet), that the
> > immediate
> > solution
On Tue, Nov 27, 2007 at 07:56:44AM -0700, Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
> > his is any less reliable that what we have currently.
> >>
> >> It doesn't make things more reliable, and it adds code to a code path
> >> that already has to much code to be solid re
Neil Horman <[EMAIL PROTECTED]> writes:
> So, it sounds to me then, like unless I'm willing to really re-write the APIC
> setup code (which I don't feel qualified to do quite yet), that the immediate
> solution would be to not rely on interrupts in legacy mode, which was
> according
> to my under
Andi Kleen <[EMAIL PROTECTED]> writes:
> his is any less reliable that what we have currently.
>>
>> It doesn't make things more reliable, and it adds code to a code path
>> that already has to much code to be solid reliable (thus your
>> problem).
>>
>> Putting the system back in PIC legacy mo
On Tue, Nov 27, 2007 at 03:43:11PM +0100, Andi Kleen wrote:
>
> >
> > As for solution 2, that brings me to my previous question. Is that really
> > as
> > simple as just not moving the apic to legacy mode? It would seem some
> > additional programming would be in order to route the interrupt i
>
> As for solution 2, that brings me to my previous question. Is that really as
> simple as just not moving the apic to legacy mode? It would seem some
> additional programming would be in order to route the interrupt in question to
> the proper cpu.
The Linux kernel right now relies on being
On Tue, Nov 27, 2007 at 02:45:56PM +0100, Andi Kleen wrote:
> his is any less reliable that what we have currently.
> >
> > It doesn't make things more reliable, and it adds code to a code path
> > that already has to much code to be solid reliable (thus your
> > problem).
> >
> > Putting the sy
On Tue, Nov 27, 2007 at 06:28:13AM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> > What makes you say this? I don't see any need for interrupts prior to
> > calibrate_delay()
>
> Yes. calibrate_delay() is the first place we send interrupts over
> hypertransport.
his is any less reliable that what we have currently.
>
> It doesn't make things more reliable, and it adds code to a code path
> that already has to much code to be solid reliable (thus your
> problem).
>
> Putting the system back in PIC legacy mode on the kexec on panic path
> was supposed to
On Tue, Nov 27, 2007 at 11:55:03AM +0100, Andi Kleen wrote:
> On Mon, Nov 26, 2007 at 08:47:40PM -0500, Neil Horman wrote:
> > Hey all-
> > I've been working on an issue lately involving multi socket x86_64
> > systems connected via hypertransport bridges. It appears that some systems,
> > dis
Neil Horman <[EMAIL PROTECTED]> writes:
> What makes you say this? I don't see any need for interrupts prior to
> calibrate_delay()
Yes. calibrate_delay() is the first place we send interrupts over
hypertransport. However I/O still works. Thus hypertransport from
the first cpu is working, and
On Mon, Nov 26, 2007 at 09:12:25PM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> > Hey all-
> > I've been working on an issue lately involving multi socket x86_64
> > systems connected via hypertransport bridges. It appears that some systems,
> > disable the hy
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Mon, Nov 26, 2007 at 08:47:40PM -0500, Neil Horman wrote:
>> Hey all-
>> I've been working on an issue lately involving multi socket x86_64
>> systems connected via hypertransport bridges. It appears that some systems,
>> disable the hypertransport
On Mon, Nov 26, 2007 at 08:47:40PM -0500, Neil Horman wrote:
> Hey all-
> I've been working on an issue lately involving multi socket x86_64
> systems connected via hypertransport bridges. It appears that some systems,
> disable the hypertransport connections during a kdump operation when al
Neil Horman <[EMAIL PROTECTED]> writes:
> Hey all-
> I've been working on an issue lately involving multi socket x86_64
> systems connected via hypertransport bridges. It appears that some systems,
> disable the hypertransport connections during a kdump operation when all but
> the
> crash
Hey all-
I've been working on an issue lately involving multi socket x86_64
systems connected via hypertransport bridges. It appears that some systems,
disable the hypertransport connections during a kdump operation when all but the
crashing processor gets halted in machine_crash_shutdown.
99 matches
Mail list logo
