I'm not subscribed to lkm so please Cc me in any responses.
This may be relevant to a post by [email protected] who
reported e100 as not working; perhaps if he uses a cross-over cable it
will "work" again.
I notice a patch in 2005 from Micahel O'Donnel to the e100.c driver has
stopped auto-crossover working on some e100 devices we use.
On one system the auto-negotiation was restored by commenting out:
(nic->mac == mac_82551_10) in function e100_phy_init where the MDI/MDI-X
is disabled.
lspci reports:
01:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 10)
01:04.0 Class 0200: 8086:1229 (rev 10)
and on another device
01:05.0 Ethernet controller: Intel Corp. 82559ER (rev 10)
01:01.0 Class 0200: 8086:1209 (rev 10)
So it is true that we are revision 10, but 82557/9 not 82551.
I must confess that having gotten this far, I am lost. Of course I can
"fix" the driver for our hardware but I am not sure how to contrive a
general fix.
Maybe the actual damage is done in
e100_get_defaults(struct nic *nic)
where nic->mac is set to nic->rev_id ?
But it generally seems to be a failure to take into account the actual
hardware type, and only consider the revision.
Any ideas?
Sam
sorry for the delay, your mail got marked as spam. In the future
please copy networking issues to [email protected], and be sure
to copy the maintainers of the driver you're having problems with
(they are in the MAINTAINERS file)
On 11/22/06, Amin Azez <[email protected]> wrote:
> I notice a patch in 2005 from Micahel O'Donnel to the e100.c driver has
> stopped auto-crossover working on some e100 devices we use.
>
> On one system the auto-negotiation was restored by commenting out:
> (nic->mac == mac_82551_10) in function e100_phy_init where the MDI/MDI-X
> is disabled.
are you sure that patch did that? What version of e100 are you using?
we've since enabled MDI-X on most parts with this patch:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=60ffa478759f39a2eb3be1ed179bc3764804b2c8;hp=09e590e5d5a93f2eaa748a89c623258e6bad1648
Please try the latest kernel or the latest e100 available from e1000.sf.net
if that doesn't work we'll need to know what kernel are you using?
> lspci reports:
> 01:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
> (rev 10)
> 01:04.0 Class 0200: 8086:1229 (rev 10)
>
> and on another device
> 01:05.0 Ethernet controller: Intel Corp. 82559ER (rev 10)
> 01:01.0 Class 0200: 8086:1209 (rev 10)
>
> So it is true that we are revision 10, but 82557/9 not 82551.
you're getting confused between decimal and hex. 82551 is rev 16 (0x10)
> I must confess that having gotten this far, I am lost. Of course I can
> "fix" the driver for our hardware but I am not sure how to contrive a
> general fix.
>
> Maybe the actual damage is done in
> e100_get_defaults(struct nic *nic)
> where nic->mac is set to nic->rev_id ?
>
> But it generally seems to be a failure to take into account the actual
> hardware type, and only consider the revision.
the only relevant way to tell e100 parts apart is the revision id
Jesse Brandeburg wrote:
> sorry for the delay, your mail got marked as spam. In the future
> please copy networking issues to [email protected], and be sure
> to copy the maintainers of the driver you're having problems with
> (they are in the MAINTAINERS file)
>
> On 11/22/06, Amin Azez <[email protected]> wrote:
>> I notice a patch in 2005 from Micahel O'Donnel to the e100.c driver has
>> stopped auto-crossover working on some e100 devices we use.
>>
>> On one system the auto-negotiation was restored by commenting out:
>> (nic->mac == mac_82551_10) in function e100_phy_init where the MDI/MDI-X
>> is disabled.
>
> are you sure that patch did that? What version of e100 are you using?
> we've since enabled MDI-X on most parts with this patch:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=60ffa478759f39a2eb3be1ed179bc3764804b2c8;hp=09e590e5d5a93f2eaa748a89c623258e6bad1648
>
>
> Please try the latest kernel or the latest e100 available from
> e1000.sf.net
> if that doesn't work we'll need to know what kernel are you using?
Let me have another check and get back to you.
It will be at least a week though.
Thanks for your response.
Sam