With 2.5.19 tulip says the following for my 21143:
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 5 for device 02:0a.0
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0: MII transceiver #1 config 3000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xd800, 00:40:C7:99:3A:5B, IRQ 5.
But 2.5.20 tulip now spews the following and then misidentifies
the NIC as a 21140:
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 5 for device 02:0a.0
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media 100baseTx (#3) described by a 21140 non-MII (0) block.
tulip0: Index #1 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
...
[136 lines deleted]
...
tulip0: Index #139 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
tulip0: Index #140 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
eth%d: Invalid media table selection 255.
tulip0: MII transceiver #1 config 3000 status 782d advertising 01e1.
eth0: Digital DS21140 Tulip rev 65 at 0xd800, 00:40:C7:99:3A:5B, IRQ 5.
Also note the obviously broken "eth%d" printk format string.
/Mikael
Mikael,
Can you try an experiment for me?
Run 2.5.19 with the 2.5.20 tulip. Just copy drivers/net/tulip/* from
2.5.20 into 2.5.19.
Nothing changed in 2.5.20 tulip that should cause that, AFAICS. So I
want to narrow down the problem before looking further.
Jeff
On Thu, 6 Jun 2002, Jeff Garzik wrote:
> Mikael,
>
> Can you try an experiment for me?
>
> Run 2.5.19 with the 2.5.20 tulip. Just copy drivers/net/tulip/* from
> 2.5.20 into 2.5.19.
>
> Nothing changed in 2.5.20 tulip that should cause that, AFAICS. So I
> want to narrow down the problem before looking further.
There was a bug in the PCI code that only passed the first device ID the
driver supported to the driver's probe callback. It caused a few other
oddities. A patch was posted to the list:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102316813812289&w=2
and is now in Linus' tree. It should fix the problem, if you get a chance
to test it...
-pat
On Thu, 6 Jun 2002 11:41:55 -0700 (PDT), Patrick Mochel wrote:
>> Run 2.5.19 with the 2.5.20 tulip. Just copy drivers/net/tulip/* from
>> 2.5.20 into 2.5.19.
>>
>> Nothing changed in 2.5.20 tulip that should cause that, AFAICS. So I
>> want to narrow down the problem before looking further.
>
>There was a bug in the PCI code that only passed the first device ID the
>driver supported to the driver's probe callback. It caused a few other
>oddities. A patch was posted to the list:
>
>http://marc.theaimsgroup.com/?l=linux-kernel&m=102316813812289&w=2
>
>and is now in Linus' tree. It should fix the problem, if you get a chance
>to test it...
>
> -pat
The patch Pat refers to above fixed my tulip problem in 2.5.20.
For completeness I also tested 2.5.19 with 2.5.20's tulip code,
and it worked fine, as expected.
Thanks,
/Mikael
Patrick Mochel wrote:
> On Thu, 6 Jun 2002, Jeff Garzik wrote:
>
>
>>Mikael,
>>
>>Can you try an experiment for me?
>>
>>Run 2.5.19 with the 2.5.20 tulip. Just copy drivers/net/tulip/* from
>>2.5.20 into 2.5.19.
>>
>>Nothing changed in 2.5.20 tulip that should cause that, AFAICS. So I
>>want to narrow down the problem before looking further.
>
>
> There was a bug in the PCI code that only passed the first device ID the
> driver supported to the driver's probe callback. It caused a few other
> oddities. A patch was posted to the list:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=102316813812289&w=2
>
> and is now in Linus' tree. It should fix the problem, if you get a chance
> to test it...
Just wanted to restate that this patch is still not enough to
make my Xircom PCI CardBus card work properly (xircom_cb driver).
Jun 7 12:49:24 dolphin cardmgr[597]: get dev info on socket 0 failed: Resource temporarily unavailable
All LEDs on the card never light up at all.
--alessandro
"the hands that build / can also pull down
even the hands of love"
(U2, "Exit")
Hi,
On Thu, 6 Jun 2002, Mikael Pettersson wrote:
> Also note the obviously broken "eth%d" printk format string.
It's printk("%s: blah\n", dev->name);
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
Thunder from the hill wrote:
>Hi,
>
>On Thu, 6 Jun 2002, Mikael Pettersson wrote:
>
>
>>Also note the obviously broken "eth%d" printk format string.
>>
>>
>
>It's printk("%s: blah\n", dev->name);
>
>
The "eth%d" thing is a format string, but unrelated to printk. The %d
is replaced with the ethernet interface number by the system. That
cosmetic bug is a holdover from olden days, when the ethernet interfaces
would do
register ethernet interface, get a number
if we fail, release the number
So with the old system, it's possible that the user might be
eth0: error cannot load, aborting [first NIC]
eth0: error cannot load, aborting [second NIC]
eth0: error cannot load, aborting [third NIC]
The new system, which is hotplug-friendly, makes it impossible to know
the ethernet interface number until you _really_ are sure the NIC is ok
to use. Therefore, "eth%d" is "dev->name" that has not been translated
yet. The fix is simple, replace "eth%d" with "tulip%d" in the printk
message, and use the board count instead of ethernet interface number.
Jeff