Thread: Re: [Etherboot-developers] rtl8139 TX timeout solved (for me)
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Marty C. <md...@th...> - 2001-09-05 16:14:26
|
On 9/4/2001 4:59 PM Eric W. Biederman ebi...@ln... wrote:
>Given that we need this for both linuxBIOS and some of the more different
>BIOS's I suspect we should create some helper functions like
>pci_enable_device and pci_set_master (examples from the linux kernel api)
>and use these in all of the pci networking drivers.
>Marty, Ken what do you think?
I think this would be a good idea. There is inconsistency in how drivers
handle PCI initialization, and I think it should probably be done before
the call to eth_reset, so that the driver doesn't have to deal with it.
This shouldn't increase code size, and would likely fix some BIOS
incompatibility bugs.
Marty
---
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
Voice: (617) 491-6935, Fax: (617) 491-7046
Email: md...@th...
Web: http://www.thinguin.org/
|
|
From: Marty C. <md...@th...> - 2001-09-09 16:44:24
|
On 9/5/2001 2:30 PM Eric W. Biederman ebi...@ln... wrote:
>> My gut reaction is not to make this common, and just to insert helper
>> functions calls. The reason is that pci devices while they tend to
>> be fairly standard, they are not always so. Leaving this logic to the
>> device driver sounds a little more reasonable to me. I don't
>> think etherboot supports any unreasonable hardware at the moment.
>And I forgot to say. If you code it I really don't care how it is dealt
>with, unless I'm the project maintainer. If I code it I'll write it my
>way :)
I am of two minds on this. One one hand, since PCI bus initialization is
generally done outside the drivers anyway, I suspect his won't make much
difference, since most of the code I've looked at seems to be doing the
same thing for all the cards that need it.
The sticky part is that we're trying to deal with (possibly) buggy
drivers that have failed to properly locate and initialize a card. Since
this seems like a BIOS interface issue and not a driver issue, I'd prefer
that the etherboot core deal with it, and let the driver deal with making
the card ready to send and receive packets.
I'll be interested in hearing what Ken's take on this is when he gets
back. The other way to look at it is that if we put the logic in the
Etherboot core, it might break more things, rather than just the drivers
we add the code to. I don't think this is the case though, since,
basically, it's code very similar to what the etherboot core does (or
should do) now.
Anyway, interesting to think about.
Marty
---
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
Voice: (617) 491-6935, Fax: (617) 491-7046
Email: md...@th...
Web: http://www.thinguin.org/
|
|
From: <ke...@us...> - 2001-09-11 08:07:07
|
>>> My gut reaction is not to make this common, and just to insert helper >>> functions calls. The reason is that pci devices while they tend to >>> be fairly standard, they are not always so. Leaving this logic to the >>> device driver sounds a little more reasonable to me. I don't >>> think etherboot supports any unreasonable hardware at the moment. >>And I forgot to say. If you code it I really don't care how it is dealt >>with, unless I'm the project maintainer. If I code it I'll write it my >>way :) > >I am of two minds on this. One one hand, since PCI bus initialization is >generally done outside the drivers anyway, I suspect his won't make much >difference, since most of the code I've looked at seems to be doing the >same thing for all the cards that need it. > >The sticky part is that we're trying to deal with (possibly) buggy >drivers that have failed to properly locate and initialize a card. Since >this seems like a BIOS interface issue and not a driver issue, I'd prefer >that the etherboot core deal with it, and let the driver deal with making >the card ready to send and receive packets. > >I'll be interested in hearing what Ken's take on this is when he gets >back. The other way to look at it is that if we put the logic in the >Etherboot core, it might break more things, rather than just the drivers >we add the code to. I don't think this is the case though, since, >basically, it's code very similar to what the etherboot core does (or >should do) now. My feeling is make it a helper function until it's judged worthwhile to be something done for every PCI NIC. It won't make any difference to the size since a boot image typically contains only one copy of the function as it will contain only one driver. |
|
From: <ebi...@ln...> - 2001-09-05 18:26:31
|
Marty Connor <md...@th...> writes: > On 9/4/2001 4:59 PM Eric W. Biederman ebi...@ln... wrote: > >Given that we need this for both linuxBIOS and some of the more different > >BIOS's I suspect we should create some helper functions like > >pci_enable_device and pci_set_master (examples from the linux kernel api) > >and use these in all of the pci networking drivers. > >Marty, Ken what do you think? > > I think this would be a good idea. There is inconsistency in how drivers > handle PCI initialization, and I think it should probably be done before > the call to eth_reset, so that the driver doesn't have to deal with it. > This shouldn't increase code size, and would likely fix some BIOS > incompatibility bugs. Hmm. Code size is an issue... My gut reaction is not to make this common, and just to insert helper functions calls. The reason is that pci devices while they tend to be fairly standard, they are not always so. Leaving this logic to the device driver sounds a little more reasonable to me. I don't think etherboot supports any unreasonable hardware at the moment. Eric |
|
From: <ebi...@ln...> - 2001-09-05 18:30:53
|
ebi...@ln... (Eric W. Biederman) writes: > Marty Connor <md...@th...> writes: > > > On 9/4/2001 4:59 PM Eric W. Biederman ebi...@ln... wrote: > > >Given that we need this for both linuxBIOS and some of the more different > > >BIOS's I suspect we should create some helper functions like > > >pci_enable_device and pci_set_master (examples from the linux kernel api) > > >and use these in all of the pci networking drivers. > > >Marty, Ken what do you think? > > > > I think this would be a good idea. There is inconsistency in how drivers > > handle PCI initialization, and I think it should probably be done before > > the call to eth_reset, so that the driver doesn't have to deal with it. > > This shouldn't increase code size, and would likely fix some BIOS > > incompatibility bugs. > > Hmm. Code size is an issue... > > My gut reaction is not to make this common, and just to insert helper > functions calls. The reason is that pci devices while they tend to > be fairly standard, they are not always so. Leaving this logic to the > device driver sounds a little more reasonable to me. I don't > think etherboot supports any unreasonable hardware at the moment. And I forgot to say. If you code it I really don't care how it is dealt with, unless I'm the project maintainer. If I code it I'll write it my way :) Eric |
