[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <09ba01c74817$1ae12980$84163e05@kroptech.com>
Date: Sat, 3 Feb 2007 23:44:07 -0500
From: "Adam Kropelin" <akropel1@...hester.rr.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: "Auke Kok" <auke-jan.h.kok@...el.com>,
"Adrian Bunk" <bunk@...sta.de>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
<jgarzik@...ox.com>, <alan@...rguk.ukuu.org.uk>,
"Allen Parker" <parker@...hunt.com>, <jesse.brandeburg@...el.com>,
<gregkh@...e.de>, <linux-pci@...ey.karlin.mff.cuni.cz>,
<netdev@...r.kernel.org>
Subject: Re: 2.6.20-rc7: known regressions (v2) (part 1)
Eric W. Biederman wrote:
> "Adam Kropelin" <akropel1@...hester.rr.com> writes:
>
>>> Can I get the corresponding lspci -xxx output. I suspect the BIOS
>>> did not program the hypertransport MSI mapping capabilities
>>> correctly. All it has to do is set the enable but still,
>>> occasionally BIOS writers miss the most amazing things.
>>
>> Here you go. This is from 2.6.20-rc7.
>
> Thanks. Conclusion. I could not find bit 16 (the enable bit) set in
> any of your hypertransport msi mapping capabilities.
>
> So MSI interrupts won't work until someone enables your chipset
> to transform them into hypertransport interrupts.
Naive question... Can the pci layer (or e1000) detect that MSI is not
enabled in the hardware and avoid using it in that case? With the number
of MSI problems showing up it seems risky to assume it's usable on any
given platform without some sort of sanity check.
--Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists