Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
From: "Fred Clift" <[EMAIL PROTECTED]> > Hm so does that mean that non-bridge devices on those busses should also > be done depth first? I understand wanting to find all the busses first, > but devices too? All the bioses I've seen seem to find all the busses, > then assign resources to devices starting with those on bus 0 then bus 1 > etc. This is also how FreeBSD <=3.4 work. Am I just missing something? > > Fred No, I am. For some reason I didn't make a distinction between regular devices and bridge devices in my mind when I though about this. =p What needs to be changed is the assignment of resources based on a combination of chassis, slot numbers, and fuction number of a device in the slot, not based on the bus number. This would have the desired effect. There are four ways of obtaining information that may be used to do this. Useing the PCI interrupt routing table in BIOS memory, querying the PCI BIOS for the same table, use the PCI 2.2 chassis/slot numbering capabilities register, and using the function numbers of the device. Everything could be done while enumerating the buses. Doing this would also potentially allow the wiring down of devices based on the chassis, slot, and fuction of the slot. This would allow logical ordering of devices. Now it just needs to be implemented. - Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
> > The PCI spec basicly states that buses are to be probed depth first. As a > PCI bridge is found, it is assigned the next sequential bus number and > probed for additional bridges beyond it. As a new bridge is found, all the > parent bridges' subordinat bus number register is updated to the highest > numbered bus that exists beyond it. When no more PCI bridges are found on > the current bus, the routine should return to the parent bus and continue > probing for more PCI bridges, and so on. > Hm so does that mean that non-bridge devices on those busses should also be done depth first? I understand wanting to find all the busses first, but devices too? All the bioses I've seen seem to find all the busses, then assign resources to devices starting with those on bus 0 then bus 1 etc. This is also how FreeBSD <=3.4 work. Am I just missing something? Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
From: "Kenneth D. Merry" <[EMAIL PROTECTED]> > The problem is that when the new-bus code was introduced, the probe order > was changed from a bus-by-bus probe (breadth first?) to a depth-first > probe. > > i.e. as soon as another PCI bus is found (e.g. on a bridge chip) it is > probed, rather than deferring the probe of the new bus until the probe of > the current bus has been completed. > > I think Doug Rabson had plans to fix the probe order, but it never > happened. > > There is no way to hardwire PCI devices, so you'll probably have to just > change which card is referenced in your scripts. > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] The PCI spec basicly states that buses are to be probed depth first. As a PCI bridge is found, it is assigned the next sequential bus number and probed for additional bridges beyond it. As a new bridge is found, all the parent bridges' subordinat bus number register is updated to the highest numbered bus that exists beyond it. When no more PCI bridges are found on the current bus, the routine should return to the parent bus and continue probing for more PCI bridges, and so on. This is done in this fashion so that sub PCI bridges may claim the correct transactions. The probe routine is correct as is - at least for machines with a single host/PCI bridge. If anything, work may be done to allow the wiring down of devices, either by PCI bus, or as found by the probe. The first not really being practical considering that buses may be renumbered based on the addition or removal of PCI bridges. eg. a nice feature we don't support yet - hot swaping of PCI cards. -Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
On Thu, 1 Jun 2000, Kenneth D. Merry wrote: > On Thu, Jun 01, 2000 at 11:19:29 -0600, Fred Clift wrote: > > > > > > i suppose the only place where you use the actual card names > > > is the firewall config and rc.conf -- can't you just make these > > > scripts fetch the ethernet address of the card(s), set a shell > > > variable with the name of the good card, and go ahead with that ? > > > > Yeah I'm about to the point of doing this for lack of other options. > > Thanks for the sample code -- I'm sure it'll come in handy if I can solve > > this any other way. > > > > The best fix would be to find a way to hard-wire which card is which in > > the kernel config (ie fxp0 is always on pci0...) but I dont know if you > > can do that kind of thing with pci devices. > > The problem is that when the new-bus code was introduced, the probe order > was changed from a bus-by-bus probe (breadth first?) to a depth-first > probe. > > i.e. as soon as another PCI bus is found (e.g. on a bridge chip) it is > probed, rather than deferring the probe of the new bus until the probe of > the current bus has been completed. > > I think Doug Rabson had plans to fix the probe order, but it never > happened. > > There is no way to hardwire PCI devices, so you'll probably have to just > change which card is referenced in your scripts. I can see that that would be fun if I were to switch from 3.4-STABLE to 4.0-STABLE on my 7-NIC (8-port) router. Currently they all probe in a way that the physical layout of the cards mirrors the logical layout. One is a dual-port NIC with PCI bridge which would constitute a PCI bus all by itself, then I believe there are three separate PCI busses of three slots each for a total of 9 PCI slots (or it could be 4x2 and 1x1). I can just imagine a physical to logical mapping nightmare of 2-3-4-7-8-9-1-2-3 now. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
> > i suppose the only place where you use the actual card names > is the firewall config and rc.conf -- can't you just make these > scripts fetch the ethernet address of the card(s), set a shell > variable with the name of the good card, and go ahead with that ? Yeah I'm about to the point of doing this for lack of other options. Thanks for the sample code -- I'm sure it'll come in handy if I can solve this any other way. The best fix would be to find a way to hard-wire which card is which in the kernel config (ie fxp0 is always on pci0...) but I dont know if you can do that kind of thing with pci devices. Thanks for the help. -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
On Thu, Jun 01, 2000 at 11:19:29 -0600, Fred Clift wrote: > > > > i suppose the only place where you use the actual card names > > is the firewall config and rc.conf -- can't you just make these > > scripts fetch the ethernet address of the card(s), set a shell > > variable with the name of the good card, and go ahead with that ? > > Yeah I'm about to the point of doing this for lack of other options. > Thanks for the sample code -- I'm sure it'll come in handy if I can solve > this any other way. > > The best fix would be to find a way to hard-wire which card is which in > the kernel config (ie fxp0 is always on pci0...) but I dont know if you > can do that kind of thing with pci devices. The problem is that when the new-bus code was introduced, the probe order was changed from a bus-by-bus probe (breadth first?) to a depth-first probe. i.e. as soon as another PCI bus is found (e.g. on a bridge chip) it is probed, rather than deferring the probe of the new bus until the probe of the current bus has been completed. I think Doug Rabson had plans to fix the probe order, but it never happened. There is no way to hardwire PCI devices, so you'll probably have to just change which card is referenced in your scripts. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
> > i suppose the only place where you use the actual card names > is the firewall config and rc.conf -- can't you just make these > scripts fetch the ethernet address of the card(s), set a shell > variable with the name of the good card, and go ahead with that ? Yeah I'm about to the point of doing this for lack of other options. Thanks for the sample code -- I'm sure it'll come in handy if I can solve this any other way. The best fix would be to find a way to hard-wire which card is which in the kernel config (ie fxp0 is always on pci0...) but I dont know if you can do that kind of thing with pci devices. Thanks for the help. -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
... > The problem is that the cards get swapped. ... > It's a long story as to why switching cables, or changing which card gets > which IP address isn't really a good solution. The short answer is that i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? I did something similar in picobsd to make the same floppy recognise the hardware on different systems. Something like (in /etc/rc): n_ether="" for main_if in `ifconfig -l` ; do set `ifconfig $main_if` while [ "$1" != "" ] ; do if [ $1 = "ether" ] ; then main_ether=$2 break 2 else shift fi done done At which point $main_ether contains the ethernet address of your first ethernet interface and you can base decisions on that... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
changed pci bus probe order from 3.2 to 4.0 -- ideas?
Hi. I've just switched to 4.0 right now and I have a problem. (well the first problem is that I dont know enough about freebsd, but I digress) I have two fxp network cards in box (intel ether express pro 10/100), one of which is integrated into the motherboard, the other of which is pluged into an active pci riser card. In 3.2 and 4.0, the pci-bus on the riser card is pci3 and the 'integrated' pci bus is 0. In 3.2 pci0 is scanned first, for devices and the integrated card is found and made fxp0, then pci1, pci2 and finally pci3, finding the second card, making it fxp1. In 4.0 it seems that pci3, then pci2 then pci1 then pci0 are being probed, finding the cards in the other order, and swapping what is fxp0 and fxp1. The problem is that the cards get swapped. It's a long story as to why switching cables, or changing which card gets which IP address isn't really a good solution. The short answer is that the second card doesn't actually ever have a network cable plugged into it at all, and is just there as a carrier of a home-brew network boot-bios. So, is there some way in the kernel config file to wire down which busses fxp0 and fxp1 live on? The only experience I have with this is playing around with isa sound cards in my desktop machine... Or alternatively, I _think_ that the bus probe stuff is in /usr/src/sys/kern/subr_bus.c I tried fiddling with device_add_child and device_add_child_ordered, but in retrospect it seems that that would just ocntrol the order in which an individual bus is scanned. How can I change the order in which the busses are scanned? Thanks in advance for any help you can give me. Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
