"Adam Kropelin" <[EMAIL PROTECTED]> writes:
> 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 s
Eric W. Biederman wrote:
"Adam Kropelin" <[EMAIL PROTECTED]> 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 am
"Adam Kropelin" <[EMAIL PROTECTED]> 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.
>
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
maybe I've been unclear, but here's how e1000 detects link changes:
1) by checking every 2 seconds in the watchdog by reading PHY
registers 2) by receiving an interrupt from the NIC with the LSI bit
in the interrupt control register
Auke Kok <[EMAIL PROTECTED]> writes:
> that's explained by a driver change that did that. Since at initialization
> we're
> basically waiting for a link change to tell the stack that we're up, we
> decided
> to change the order to have the hardware fire an LSI interrupt to trigger a
> watchdog r
Adam Kropelin wrote:
Auke Kok wrote:
Adam Kropelin wrote:
I've never had this device work 100% with MSI on any kernel version
I've tested so far. But I'm not the original reporter of the
problem, and I believe for him it was a true regression where a
previous kernel wored correctly.
maybe I've
Auke Kok <[EMAIL PROTECTED]> writes:
> maybe I've been unclear, but here's how e1000 detects link changes:
>
> 1) by checking every 2 seconds in the watchdog by reading PHY registers
> 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt
> control register
>
> if the link is
Auke Kok wrote:
Adam Kropelin wrote:
I've never had this device work 100% with MSI on any kernel version
I've tested so far. But I'm not the original reporter of the
problem, and I believe for him it was a true regression where a
previous kernel wored correctly.
maybe I've been unclear, but he
Adam Kropelin wrote:
> Eric W. Biederman wrote:
>> Auke Kok <[EMAIL PROTECTED]> writes:
>>> None of the MSI code in e1000 has changed significantly either. as
>>> far as I can see, the msi code in e1000 has not changed since
>>> 2.6.18. Nonetheless there's no way I can debug any of this without a
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
None of the MSI code in e1000 has changed significantly either. as
far as I can see, the msi code in e1000 has not changed since
2.6.18. Nonetheless there's no way I can debug any of this without a
system.
[...]
Perhaps Adam can git-b
Auke Kok <[EMAIL PROTECTED]> writes:
> Adrian Bunk wrote:
>> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
>> that are not yet fixed in Linus' tree.
>>
>> If you find your name in the Cc header, you are either submitter of one
>> of the bugs, maintainer of an affectected
Adrian Bunk wrote:
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breaka
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
13 matches
Mail list logo