done, bug number #7884
Cheers,
Eamonn
On Thu, 2007-01-25 at 09:17 +, Luming Yu wrote:
> > I didn't get a chance to try the -mm patch, but booting with acpi=off
> > works - other than no acpi, of course :)
> >
> > What now?
> Well, this should be ACPI interrupt configure issue.
> Please feel f
I didn't get a chance to try the -mm patch, but booting with acpi=off
works - other than no acpi, of course :)
What now?
Well, this should be ACPI interrupt configure issue.
Please feel free to enter a bug on bugzilla.kernel.org.
And, post acpidump output, /proc/interrupts ,lspci -vvx, dmesg for
Hi,
I didn't get a chance to try the -mm patch, but booting with acpi=off
works - other than no acpi, of course :)
What now?
Cheers,
Eamonn
On Thu, 2007-01-25 at 05:33 +, Luming Yu wrote:
> On 1/25/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:
> > I've also just found bug #7820 on bugzilla
On 1/25/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:
I've also just found bug #7820 on bugzilla which has a patch which may
address this issue from Ingo.
I'll give that a shot as well.
Yes, that patch workaround the problem. But it is just a workaround.
It would be much helpful to others by
I've also just found bug #7820 on bugzilla which has a patch which may
address this issue from Ingo.
I'll give that a shot as well.
Cheers,
Eamonn
On Wed, 2007-01-24 at 23:21 +0800, Luming Yu wrote:
> what about acpi=off?
>
> On 1/24/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
>
Hi,
I will give that a go tonight - it's my home system.
Cheers,
Eamonn
On Wed, 2007-01-24 at 23:21 +0800, Luming Yu wrote:
> what about acpi=off?
>
> On 1/24/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I can't get any kernel up to 2.6.20-rc5 to boot without using noapic on
>
what about acpi=off?
On 1/24/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:
Hi,
I can't get any kernel up to 2.6.20-rc5 to boot without using noapic on
an ABIT KN9-Ultra with a dual-core Athlon.
I booted with apic=debug as suggested and got the following :
ENABLING IO-APIC IRQs
.. TIMER: vect
Please check the revised patch
YH
[PATCH] x86_64: check_timer with io apic setup before try_apic_pin
add io apic setup before try_apic_pin for check_timer
also add remove_irq_to_pin call in io_apic.c
cc: Andi Kleen <[EMAIL PROTECTED]>
cc: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Yi
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 21, 2006 12:47 PM
> To: Lu, Yinghai
>>> +static int add_irq_entry(int type, int irqflag, int bus, int irq,
> int apic, int
>>> pin)
>
>>This is fai
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 12:47 PM
To: Lu, Yinghai
>> +static int add_irq_entry(int type, int irqflag, int bus, int irq,
int apic, int
>> pin)
>This is fairly sane but probably belongs in mptable.c as a helper.
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 12/19/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> So the pin2 case should be tested right after the pin1 case as we do
>> currently. On most new boards that will be a complete noop.
>>
>> But it is better than our current blind guess at using
Yinghai Lu wrote:
> On 12/19/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >So the pin2 case should be tested right after the pin1 case as we do
> >currently. On most new boards that will be a complete noop.
> >
> >But it is better than our current blind guess at using ExtINT mode.
> >
> >I f
On 12/19/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
So the pin2 case should be tested right after the pin1 case as we do
currently. On most new boards that will be a complete noop.
But it is better than our current blind guess at using ExtINT mode.
I figure after we try what the BIOS has
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 12/18/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Thanks. The bug is simply that the new code doesn't setup the
>> ioapic for the cases it intends to test. But it does clear out
>> the original programming. So if the normal good case doesn't
On 12/18/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Thanks. The bug is simply that the new code doesn't setup the
ioapic for the cases it intends to test. But it does clear out
the original programming. So if the normal good case doesn't work the
code is going to have problems.
Please
Tobias Diedrich <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Could you try removing the clear_IO_APIC_pin from try_io_apic_pin.
>>
>> This isn't a complete fix but I believe for your hardware it will
>> fix the problem and it points at what the real fix is.
>>
>> Not properly progr
Tobias Diedrich wrote:
> I can also report, that updating the BIOS to version 0609 (released
> last week or so, also adds the long-missing HPET support) also makes
> the problem go away since the first testcase then already works.
> I'm currently running with the BIOS downgraded to version 0402.
Eric W. Biederman wrote:
> Tobias Diedrich <[EMAIL PROTECTED]> writes:
>
> > Linus Torvalds wrote:
> >
> >> Your dmesg is kind of interesting:
> >>
> >> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on
> >> CPU0:
> > 04(40)
> >> .. failed
> >>
> >> where that APIC error o
Tobias Diedrich <[EMAIL PROTECTED]> writes:
> Linus Torvalds wrote:
>
>> Your dmesg is kind of interesting:
>>
>> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0:
> 04(40)
>> .. failed
>>
>> where that APIC error on CPU0 seems to be a "Send accept error" and "Send
>
On Sunday 17 December 2006 00:22, Eric W. Biederman wrote:
> Actually can anyone tell me how try_apic_pin is supposed to work at
> all?
>
> It doesn't appear to be programming the io_apic.
magic:-)
ACPI can't even _describe_ the scenarios being tried by check_timer(),
which is trying to navigat
On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>
> BTW, I'm also wondering if this secondary Oops is supposed to happen:
Well, if the timer doesn't work, then the NMI watchdog will trigger. So
it's "supposed" to happen in the sense that yeah, it's kind of expected,
but it's really bsically just
Linus Torvalds wrote:
> Your dmesg is kind of interesting:
>
> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0:
> 04(40)
> .. failed
>
> where that APIC error on CPU0 seems to be a "Send accept error" and "Send
> illegal vector" thing. I think we actually got the i
Linus Torvalds wrote:
> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
> >
> > No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
> tree in the hopes that Andi and/or Eric can see what's wrong and solve it.
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>>
>> No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
> tree in the hopes that Andi and/or Eric can see what's
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>>
>> No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
> tree in the hopes that Andi and/or Eric can see what's
On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>
> No such luck, it still panics and the APIC error is also unchanged.
Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
tree in the hopes that Andi and/or Eric can see what's wrong and solve it.
If we don't find a solution, I
On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>
> With commit b0268726 backed out, 2.6.20-rc1 boots fine.
Ok. It's sad, because that thing really did clean stuff up, and seemed
like a nice and robust approach.
Your dmesg is kind of interesting:
..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 ena
On Sat, 16 Dec 2006, Tobias Diedrich wrote:
>
> 2.6.20-rc1 won't boot with the error message "IO-APIC + timer
> doesn't work! Try using the 'noapic' kernel parameter".
> However, IO-APIC seems to work just fine with 2.6.19-rc6 and I'd
> rather like to continue using it. :)
Can you try "git bise
28 matches
Mail list logo
