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
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
system.
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
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 down to
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
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 run. So
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
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.
Here you
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
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 sort of
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
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
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 subsystem
13 matches
Mail list logo
