s2885

[YhLu]

Eric,

Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).

For the S2885's onboard 5703X, it says: EBUSY err.

Regards

Yinghai Lu

01:09.00 [14E4/16A7]
[tg3-5703X]The PCI BIOS has not enabled this device!
Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
Capability: 7
Capability: 1
err=-1
Problem fetching invariants of chip, aborting.

[Jeff Noxon]

I can't get it to work with a 3com 3C996T (14e4:1644) ... it recognizes
the card but thinks there's no cable plugged in.

On Fri, Aug 15, 2003 at 10:31:44PM -0700, YhLu wrote:
> Eric,
>
> Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).
>
> For the S2885's onboard 5703X, it says: EBUSY err.
>
> Regards
>
> Yinghai Lu
>
> 01:09.00 [14E4/16A7]
> [tg3-5703X]The PCI BIOS has not enabled this device!
> Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
> Capability: 7
> Capability: 1
> err=-1
> Problem fetching invariants of chip, aborting.

Guys the etherboot users list is really the right forum for
this kind of question.

Jeff Noxon  writes:
> I can't get it to work with a 3com 3C996T (14e4:1644) ... it recognizes
> the card but thinks there's no cable plugged in.

I don't know.  When the link detection code was written it was tested
and it worked here.  Except when the link really is not connected I
have not seen code like that fail forever.
> On Fri, Aug 15, 2003 at 10:31:44PM -0700, YhLu wrote:
> > Eric,
> >
> > Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).
> >
> > For the S2885's onboard 5703X, it says: EBUSY err.

Looking at the code it is should work.  I just stripped down the
appropriate driver.  I do admit I have not tested 5.2 yet.  But
I don't see why anything would have broken.
> > Regards
> >
> > Yinghai Lu
> >
> > 01:09.00 [14E4/16A7]
> > [tg3-5703X]The PCI BIOS has not enabled this device!
> > Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
> > Capability: 7
> > Capability: 1
> > err=-1
> > Problem fetching invariants of chip, aborting.

Hmm.  I have once or twice seen the problem of fetching invariants of
the chip.  But something is noticeably different from the tree I have
because I do not have an line that will print err=-1 in the tree I am
looking at.

Eric

[Yinghai Lu]

I add one printf if tg3.c to produce "err=?".

YH

-----邮件原件-----
发件人: Eric W. Biederman [mailto:[e-mail]] 代表 Eric W. Biederman
发送时间: 2003年8月16日 10:18
收件人: Etherboot-users
抄送: YhLu; '[e-mail]'; Jeff Noxon
主题: Re: s2885

Guys the etherboot users list is really the right forum for
this kind of question.

Jeff Noxon  writes:
> I can't get it to work with a 3com 3C996T (14e4:1644) ... it

recognizes
> the card but thinks there's no cable plugged in.

I don't know.  When the link detection code was written it was tested
and it worked here.  Except when the link really is not connected I
have not seen code like that fail forever.
> On Fri, Aug 15, 2003 at 10:31:44PM -0700, YhLu wrote:
> > Eric,
> >
> > Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).
> >
> > For the S2885's onboard 5703X, it says: EBUSY err.

Looking at the code it is should work.  I just stripped down the
appropriate driver.  I do admit I have not tested 5.2 yet.  But
I don't see why anything would have broken.
> > Regards
> >
> > Yinghai Lu
> >
> > 01:09.00 [14E4/16A7]
> > [tg3-5703X]The PCI BIOS has not enabled this device!
> > Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
> > Capability: 7
> > Capability: 1
> > err=-1
> > Problem fetching invariants of chip, aborting.

Hmm.  I have once or twice seen the problem of fetching invariants of
the chip.  But something is noticeably different from the tree I have
because I do not have an line that will print err=-1 in the tree I am
looking at.

Eric

[Etherboot-users] re: s2885

"Yinghai Lu"  writes:
> I add one printf if tg3.c to produce "err=?".

Ok.

So far the consensus is that we should not have seen any new problems
with version 5.2.x, as nothing has changed (except your printf :).

So either there is a LinuxBIOS bug where memory mapped I/O is not
being properly routed, or you have come across a bug in the driver.

It has had a moderate amount of testing, and I did my best to preserve
the initialization that the Linux driver was doing when I stripped it
down.  You do have a version of the tg3 I don't have on hand.  So I
don't currently have a clue where to start looking except to add more
printfs to track down which part of the initialization failed.

Eric