em0 hangs on 8-STABLE again
Hello, Freebsd-net. My home server lost connection on em0 this night again. It was persistent problem some times ago, but with version 7.2.3 it is first time, but with worse symptoms. It looks like undetected hardware hang-up: no packets could be sent or received, and no any output in dmesg or log files. Interface up/down with ifconfig and cable unplugging doesn't help: ifaces sees all these changes, but no packets could be sent/received anyway. I was forced to reboot server to make it work again. IT is rather old 8-STABLE (Oct 2011), but it sems, that last change in e1000 for 8-STABLE was r223675, in Jun 2011, so it is fresh sources (I don't believe, that r229147 is related). Output of `sysctl dev.em' when card is not working (but after some up/down events) is attached. NIC is: em0: Intel(R) PRO/1000 Network Connection 7.2.3 port 0xd880-0xd89f mem 0xfea4-0xfea5,0xfea7a000-0xfea7afff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:8c:75:03:0d em0@pci0:0:25:0:class=0x02 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet -- // Black Lion AKA Lev Serebryakov l...@freebsd.orgdev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.0.%driver: em dev.em.0.%location: slot=25 function=0 handle=\_SB_.PCI0.GBEC dev.em.0.%pnpinfo: vendor=0x8086 device=0x10bd subvendor=0x1043 subdevice=0x8268 class=0x02 dev.em.0.%parent: pci0 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.eee_control: 0 dev.em.0.link_irq: 0 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 7742 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1477444160 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 8192 dev.em.0.fc_low_water: 6692 dev.em.0.queue0.txd_head: 158 dev.em.0.queue0.txd_tail: 125 dev.em.0.queue0.tx_irq: 0 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 3624 dev.em.0.queue0.rxd_tail: 3623 dev.em.0.queue0.rx_irq: 0 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 3404271 dev.em.0.mac_stats.missed_packets: 143616 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 73 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 1545 dev.em.0.mac_stats.crc_errs: 1610 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 6 dev.em.0.mac_stats.xon_recvd: 3560624 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 43541329 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 1393645238 dev.em.0.mac_stats.good_pkts_recvd: 1346464499 dev.em.0.mac_stats.bcast_pkts_recvd: 30744 dev.em.0.mac_stats.mcast_pkts_recvd: 8763 dev.em.0.mac_stats.rx_frames_64: 0 dev.em.0.mac_stats.rx_frames_65_127: 0 dev.em.0.mac_stats.rx_frames_128_255: 0 dev.em.0.mac_stats.rx_frames_256_511: 0 dev.em.0.mac_stats.rx_frames_512_1023: 0 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 157771296534 dev.em.0.mac_stats.good_octets_txd: 3105799379404 dev.em.0.mac_stats.total_pkts_txd: 2289914278 dev.em.0.mac_stats.good_pkts_txd: 2289914278 dev.em.0.mac_stats.bcast_pkts_txd: 4776 dev.em.0.mac_stats.mcast_pkts_txd: 101790 dev.em.0.mac_stats.tx_frames_64: 0 dev.em.0.mac_stats.tx_frames_65_127: 0 dev.em.0.mac_stats.tx_frames_128_255: 0 dev.em.0.mac_stats.tx_frames_256_511: 0 dev.em.0.mac_stats.tx_frames_512_1023: 0 dev.em.0.mac_stats.tx_frames_1024_1522: 0 dev.em.0.mac_stats.tso_txd: 652240789 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 1375041031 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.0.wake: 0 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
On Sat, 28 Jan 2012 15:00:01 -0800 Juli Mallett jmall...@freebsd.org wrote: On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko r...@ddteam.net wrote: As I see from your patch, mdio/miiproxy require special bits in MAC driver. When I design switch framework, I keeping in mind that MAC drivers should be standard as possible I don't understand why this is desirable in practice. It's a nice theory, but it falls down when one thinks in depth about how Ethernet interfaces are used and administered vs. how switches are used and administered. What should media report? What should media changes do? What is link status? Do you show the CPU-to-switch port, or all switch ports? IMO, if we about why to make MAC driver more standard, it is desired because most MAC, used in SoC's, used also in NIC cards or other SoC's which have no switch, but MII and MDIO pins to attach external PHY. Real example bfe(4), it is supported long ago as PCI card, but also found in BCM4701 family SoC's. In BCM5354 it attached to embedded switch. In BCM5836 it is two independent MAC. Last one used in D-Link DIR-330, there is one MAC attached to PHY, second to BCM5325 switch). Since BCM4701 family have internal SSB bus, a.k.a siba(4), I add only siba(4) bus glue. So if we able to attach switch driver to regular MAC drivers it will make our life simpler :) It makes me wonder if the understanding of the relationship in FreeBSD isn't backwards. Yes, the MAC sits on a bus and is memory-mapped, but you can conceptualize of it as a child of the PHY, rather than the parent of it, especially in systems with switch chipsets. Especially in systems where there is a switch chipset attached to multiple MACs. In that model, it makes sense to semi-generically attach a CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware) to a MAC generically, but that doesn't meant that the switch itself is attached generically to the MAC. There are a lot of switches out there that don't look or act much like MII-driven PHYs, but which are connected over MDIO, as I've tried to stress before. Yeah, for that case Marius commit phymask support for our miibus, to not touch reserved PHY IDs. I hope there will be as much separation between the MII work that is being done and the switch work that is being done as possible. I think anything else will prove rapidly-obsolete and perhaps even obstructive as soon as anyone seeks to add support for more switch chipsets to FreeBSD. I suppose the most likely reality, though, is that people simply won't add switch support to FreeBSD, and will administer them out-of-band from userland, using gross kernel shims. That is probably true whether any of the currently-outstanding work is committed or not, unfortunately :( I just hope we'll end up with something flexible enough, broad enough in applicability, narrow enough in requirements, etc., that we'll have feature-rich support for a few chipsets in tree that work in sufficiently-different manners that they can be models for other drivers in the future. Thanks, Juli. Thank you for comments Juli! WBW -- Aleksandr Rybalko r...@ddteam.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
Am 29.01.2012 um 00:00 schrieb Juli Mallett: On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko r...@ddteam.net wrote: As I see from your patch, mdio/miiproxy require special bits in MAC driver. When I design switch framework, I keeping in mind that MAC drivers should be standard as possible I don't understand why this is desirable in practice. It's a nice theory, but it falls down when one thinks in depth about how Ethernet interfaces are used and administered vs. how switches are used and administered. What should media report? What should media changes do? What is link status? Do you show the CPU-to-switch port, or all switch ports? The main thrust here is to reuse the existing PHY code to be able to configure the PHYs that are embedded in the switch chips. To confuse things, one of these PHYs might be connected to the SoCs ethernet interface via MII, GMII, etc. To confuse things further, these PHYs are controlled by an MDIO bus that has it's master in the switch chip, while the switch chip is a slave to the MDIO master in the ethernet controller. The goal is to be able to configure the switch ports and set media on one of them, for example. That code path could be entirely independent from the ethernet infrastructure, if dev/miibus didn't require if_media and hence a struct ifnet. This discussion is also about how to deal with this entanglement. The MII connection between the ethernet controller and the switch chip (usually referred to as the CPU port) is hard-coded and has no media settings, so there's no question what if_media settings should be presented on the interface. are a lot of switches out there that don't look or act much like MII-driven PHYs, but which are connected over MDIO, as I've tried to stress before. I hope there will be as much separation between the MII work that is being done and the switch work that is being done as possible. I think anything else will prove rapidly-obsolete and perhaps even obstructive as soon as anyone seeks to add support for more switch chipsets to FreeBSD. I suppose the most likely reality, though, is that people simply won't add switch support to FreeBSD, and will administer them out-of-band from userland, using gross kernel shims. That is probably true whether any of the currently-outstanding work is committed or not, unfortunately :( I just hope we'll end up with something flexible enough, broad enough in applicability, narrow enough in requirements, etc., that we'll have feature-rich support for a few chipsets in tree that work in sufficiently-different manners that they can be models for other drivers in the future. Which is a valid approach from a vendor's viewpoint. The reason we're talking is to try and make it easier to write a switch driver for this framework than roll your own hack. :-) Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
On Sun, 29 Jan 2012 13:26:00 +0100 Stefan Bethke s...@lassitu.de wrote: Am 29.01.2012 um 00:00 schrieb Juli Mallett: On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko r...@ddteam.net wrote: As I see from your patch, mdio/miiproxy require special bits in MAC driver. When I design switch framework, I keeping in mind that MAC drivers should be standard as possible I don't understand why this is desirable in practice. It's a nice theory, but it falls down when one thinks in depth about how Ethernet interfaces are used and administered vs. how switches are used and administered. What should media report? What should media changes do? What is link status? Do you show the CPU-to-switch port, or all switch ports? The main thrust here is to reuse the existing PHY code to be able to configure the PHYs that are embedded in the switch chips. To confuse things, one of these PHYs might be connected to the SoCs ethernet interface via MII, GMII, etc. To confuse things further, these PHYs are controlled by an MDIO bus that has it's master in the switch chip, while the switch chip is a slave to the MDIO master in the ethernet controller. The goal is to be able to configure the switch ports and set media on one of them, for example. That code path could be entirely independent from the ethernet infrastructure, if dev/miibus didn't require if_media and hence a struct ifnet. This discussion is also about how to deal with this entanglement. The MII connection between the ethernet controller and the switch chip (usually referred to as the CPU port) is hard-coded and has no media settings, so there's no question what if_media settings should be presented on the interface. Most switches (AR8x16 for example) have configurable MII port, so you can choose to use MII/RMII/GMII/RGMII. If you decide to use MII media can not be higher than 100baseTX. So it is possible to use some auto-negotiation here. are a lot of switches out there that don't look or act much like MII-driven PHYs, but which are connected over MDIO, as I've tried to stress before. I hope there will be as much separation between the MII work that is being done and the switch work that is being done as possible. I think anything else will prove rapidly-obsolete and perhaps even obstructive as soon as anyone seeks to add support for more switch chipsets to FreeBSD. I suppose the most likely reality, though, is that people simply won't add switch support to FreeBSD, and will administer them out-of-band from userland, using gross kernel shims. That is probably true whether any of the currently-outstanding work is committed or not, unfortunately :( I just hope we'll end up with something flexible enough, broad enough in applicability, narrow enough in requirements, etc., that we'll have feature-rich support for a few chipsets in tree that work in sufficiently-different manners that they can be models for other drivers in the future. Which is a valid approach from a vendor's viewpoint. The reason we're talking is to try and make it easier to write a switch driver for this framework than roll your own hack. :-) Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 -- Aleksandr Rybalko r...@ddteam.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
Am 29.01.2012 um 13:44 schrieb Aleksandr Rybalko: The MII connection between the ethernet controller and the switch chip (usually referred to as the CPU port) is hard-coded and has no media settings, so there's no question what if_media settings should be presented on the interface. Most switches (AR8x16 for example) have configurable MII port, so you can choose to use MII/RMII/GMII/RGMII. If you decide to use MII media can not be higher than 100baseTX. So it is possible to use some auto-negotiation here. The point is that the admin has no need to change it, it's hard coded in the driver or statically configured via hints. And for all of this discussion, I'm using MII as a synonym for all xMII busses. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: em0 hangs on 8-STABLE again
On 1/29/2012 4:38 AM, Lev Serebryakov wrote: Hello, Freebsd-net. My home server lost connection on em0 this night again. It was persistent problem some times ago, but with version 7.2.3 it is first time, but with worse symptoms. 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon :) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
Am 29.01.2012 um 08:05 schrieb Warner Losh: I think that the main issue here is that we have an assumption that we have a tree structure. However, it is more of a DAG across different domains. The hierarchy works well when each device owns all the devices below it and only interacted with them. Most devices are that way. However, in the embedded world, there's lots of reach-accrosses that are expected that break the model. What do people think would be a good approach to solve the concrete issue without too much hackery? Aleksandr and I have presented three possible approaches: 1. have a PHY driver that acts as a proxy and talks to a separate MDIO master 2. have a proxy between the ethernet driver and the miibus driver 3. modify miibus to have a separate device for mediachg() etc. All three suffer from a dependency problem: miibus attachment can only complete successfully when both the ethernet driver and the mdio driver have been attached. In the current model, the ethernet driver provides both the MDIO access as well as the target for the mediachg, etc. messages, so there's no attachment ordering issue. In my miiproxy patch (2.), it is necessary for the ethernet driver to cooperate in this delayed attachment, by splitting out the miibus attachment from the device_attach method implementation. That's a fairly intrusive change, and that would need to be made to any ethernet driver that is to support such a split MDIO/MII setup. I tried delaying just the call to mii_attach(), but it seems that interacts badly with an already attached interface. Specifically, I got a non-working interface when I tried to call mii_attach() long after if_etherattach(). Additionally, if_arge (and probably most other drivers) assumes that the miibus is attached after they've successfully attached themselves, and subsequently runs into null pointer issues when it isn't. Would it be possible to attach miibus without having a working PHY, and only attach the PHYs once the MDIO device has been attached? For the mips/atheros platforms, we could introduce ordering hints for nexus to make sure the mdio driver gets attached before the arge's. That's a fairly small changes (two lines), and does work, but it's more a hack than a general solution. With my proposed change to miibus (split devices), that would bring down the necessary changes to just a handful of lines. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
On Sun, Jan 29, 2012 at 02:14:42PM +0100, Stefan Bethke wrote: Am 29.01.2012 um 08:05 schrieb Warner Losh: I think that the main issue here is that we have an assumption that we have a tree structure. However, it is more of a DAG across different domains. The hierarchy works well when each device owns all the devices below it and only interacted with them. Most devices are that way. However, in the embedded world, there's lots of reach-accrosses that are expected that break the model. What do people think would be a good approach to solve the concrete issue without too much hackery? Aleksandr and I have presented three possible approaches: 1. have a PHY driver that acts as a proxy and talks to a separate MDIO master 2. have a proxy between the ethernet driver and the miibus driver 3. modify miibus to have a separate device for mediachg() etc. All three suffer from a dependency problem: miibus attachment can only complete successfully when both the ethernet driver and the mdio driver have been attached. In the current model, the ethernet driver provides both the MDIO access as well as the target for the mediachg, etc. messages, so there's no attachment ordering issue. In my miiproxy patch (2.), it is necessary for the ethernet driver to cooperate in this delayed attachment, by splitting out the miibus attachment from the device_attach method implementation. That's a fairly intrusive change, and that would need to be made to any ethernet driver that is to support such a split MDIO/MII setup. I tried delaying just the call to mii_attach(), but it seems that interacts badly with an already attached interface. Specifically, I got a non-working interface when I tried to call mii_attach() long after if_etherattach(). Additionally, if_arge (and probably most other drivers) assumes that the miibus is attached after they've successfully attached themselves, and subsequently runs into null pointer issues when it isn't. Would it be possible to attach miibus without having a working PHY, and only attach the PHYs once the MDIO device has been attached? This would break the concept of knowing that when mii_attach() returns success you can talk to all the hardware necessary to present a working interface. So you'll just need another way instead to ensure that there's also at least a single PHY before attaching the whole thing which I don't see getting us further with the attach ordering problem of the MDIO provider. For the mips/atheros platforms, we could introduce ordering hints for nexus to make sure the mdio driver gets attached before the arge's. That's a fairly small changes (two lines), and does work, but it's more a hack than a general solution. With my proposed change to miibus (split devices), that would bring down the necessary changes to just a handful of lines. How about adding the MDIO provider via multi-pass probing? That idea of that model was to attach things like drivers for interrupt controllers before any other driver that requires that resource. This seems like a perfect match here and requires neither a specific hack to the nexus (the platform generally needs to be multi-pass aware though and the thing enabled in subr_bus.c) nor a hack to miibus(4). We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place. Marius ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
Am 29.01.2012 um 16:31 schrieb Marius Strobl: How about adding the MDIO provider via multi-pass probing? That idea of that model was to attach things like drivers for interrupt controllers before any other driver that requires that resource. This seems like a perfect match here and requires neither a specific hack to the nexus (the platform generally needs to be multi-pass aware though and the thing enabled in subr_bus.c) nor a hack to miibus(4). Please recall the devinfo graph that I posted earlier. The PHY arge0 needs to talk to is attached to the MDIO master on the switch controller, which in turn is attached to GE1's MDIO master. This would require early attachment of the switch, in turn requiring early attachment of arge_mdio, in turn requiring early attachment of mips/mips/nexus. We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place. Why is the above is less of a hack than making the ordering in nexus configurable through a hint? Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 diff --git a/sys/mips/mips/nexus.c b/sys/mips/mips/nexus.c index b51357d..c4c207a 100644 --- a/sys/mips/mips/nexus.c +++ b/sys/mips/mips/nexus.c @@ -240,8 +240,11 @@ nexus_hinted_child(device_t bus, const char *dname, int dunit) int result; int irq; int mem_hints_count; + int order; - child = BUS_ADD_CHILD(bus, 0, dname, dunit); + order = 1000; /* there should be a define for the default order */ + resource_int_value(dname, dunit, order, order); + child = BUS_ADD_CHILD(bus, order, dname, dunit); if (child == NULL) return; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
On Sun, Jan 29, 2012 at 05:00:38PM +0100, Stefan Bethke wrote: Am 29.01.2012 um 16:31 schrieb Marius Strobl: How about adding the MDIO provider via multi-pass probing? That idea of that model was to attach things like drivers for interrupt controllers before any other driver that requires that resource. This seems like a perfect match here and requires neither a specific hack to the nexus (the platform generally needs to be multi-pass aware though and the thing enabled in subr_bus.c) nor a hack to miibus(4). Please recall the devinfo graph that I posted earlier. The PHY arge0 needs to talk to is attached to the MDIO master on the switch controller, which in turn is attached to GE1's MDIO master. This would require early attachment of the switch, in turn requiring early attachment of arge_mdio, in turn requiring early attachment of mips/mips/nexus. Yes We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place. Why is the above is less of a hack than making the ordering in nexus configurable through a hint? If it's generally true that driver A must be attached before driver B as B has a dependency on A than this should be expressed and configured in the drivers themselves and not need an extra hint to configure it at the runtime of the kernel. Marius ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
Am 29.01.2012 um 17:19 schrieb Marius Strobl: We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place. Why is the above is less of a hack than making the ordering in nexus configurable through a hint? If it's generally true that driver A must be attached before driver B as B has a dependency on A than this should be expressed and configured in the drivers themselves and not need an extra hint to configure it at the runtime of the kernel. Except that it is not generally true, but only in specific configurations. Other boards have other combinations of devices. The Atheros family of switches is available both embedded into certain SoC as well as separate silicon. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
On Sun, Jan 29, 2012 at 05:21:52PM +0100, Stefan Bethke wrote: Am 29.01.2012 um 17:19 schrieb Marius Strobl: We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place. Why is the above is less of a hack than making the ordering in nexus configurable through a hint? If it's generally true that driver A must be attached before driver B as B has a dependency on A than this should be expressed and configured in the drivers themselves and not need an extra hint to configure it at the runtime of the kernel. Except that it is not generally true, but only in specific configurations. Other boards have other combinations of devices. The Atheros family of switches is available both embedded into certain SoC as well as separate silicon. It still seems to be true to me that as soon as you have a separate MDIO driver that this one needs to be attached before any Ethernet, switch or whatever driver that needs to talk via the MDIO lines of the former. Similarly, if the switch attaches to an MDIO instance directly, that switch would need to be attached before the Ethernet driver (if there is one) that the switch is the MDIO master for (this isn't exactly the problematic arge-case). Multi-pass is per driver module, so if the switch attaches to a regular Ethernet driver providing both the MAC and the MDIO master instead, you can leave the default probe order and attach the switch after the Ethernet driver. So for the problematic arge-case you would attach the MDIO driver first (corresponding to the MDIO of arge1), then the switch to the MDIO driver and both arge0 and arge1 in whatever order last. Allowing that one special case to work properly shouldn't interfere with other device combinations as it basically boils down to the presence of a separate MDIO instance. Actually that should also work just fine when the MDIO master sits on the IIC bus as that again would mean that it needs to be attached before a Ethernet or switch driver can use it. Marius ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: em0 hangs on 8-STABLE again
No, I told Mike I'd get it into 8.x, have just been busy, but will try and get it pushed up in the queue. Jack 2012/1/29 Lev Serebryakov l...@freebsd.org Hello, Mike. You wrote 29 января 2012 г., 16:54:59: My home server lost connection on em0 this night again. It was persistent problem some times ago, but with version 7.2.3 it is first time, but with worse symptoms. 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon :) I'm afraid, that MFC'd means to 9-STABLE now :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: em0 hangs on 8-STABLE again
On 1/29/12 7:21 PM, Jack Vogel wrote: No, I told Mike I'd get it into 8.x, have just been busy, but will try and get it pushed up in the queue. Jack 2012/1/29 Lev Serebryakov l...@freebsd.org Hello, Mike. You wrote 29 января 2012 г., 16:54:59: My home server lost connection on em0 this night again. It was persistent problem some times ago, but with version 7.2.3 it is first time, but with worse symptoms. 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon :) I'm afraid, that MFC'd means to 9-STABLE now :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org Hello Jack, Any chance to get this in 8.3-RELEASE ? I'm afraid we don't track -STABLE, at work. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
I think for switches, that doesn't necessarily hold. ie, mii_attach() for single-PHY devices may work that way, but the weird and wonderful world of embedded switch SoC's doesn't. You're lucky in most instances since the bootloader does give you a mostly-working switch config. But I doubt that's a guarantee on all platforms. So for those (ethernet) devices, splitting out the mii/mdio stuff and _not_ necessarily presenting a working PHY may be acceptable. For now it's going to be a subset, to having it export an MDIO bus and doing late MII attachment may not be as architecturally no-no as I interpret your post. Adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: em0 hangs on 8-STABLE again
Yes, the whole reason to get it into that stable is to make the 8.3 release. Jack On Sun, Jan 29, 2012 at 10:47 AM, Damien Fleuriot m...@my.gd wrote: On 1/29/12 7:21 PM, Jack Vogel wrote: No, I told Mike I'd get it into 8.x, have just been busy, but will try and get it pushed up in the queue. Jack 2012/1/29 Lev Serebryakov l...@freebsd.org Hello, Mike. You wrote 29 января 2012 г., 16:54:59: My home server lost connection on em0 this night again. It was persistent problem some times ago, but with version 7.2.3 it is first time, but with worse symptoms. 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon :) I'm afraid, that MFC'd means to 9-STABLE now :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org Hello Jack, Any chance to get this in 8.3-RELEASE ? I'm afraid we don't track -STABLE, at work. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Ethernet Switch Framework
On Sun, Jan 29, 2012 at 11:00:22AM -0800, Adrian Chadd wrote: I think for switches, that doesn't necessarily hold. Err, what exactly doesn't hold? The suggestion about using multi-pass probing was just for the case when there's a separate MDIO master other drivers depend on. The latter would just use the default ordering (unless there are again ordering constraints whithin them). So if there's no separate MDIO master driver invovled that is attached first, the other drivers would still just be attached in the default ordering. ie, mii_attach() for single-PHY devices may work that way, but the weird What way? and wonderful world of embedded switch SoC's doesn't. You're lucky in most instances since the bootloader does give you a mostly-working switch config. But I doubt that's a guarantee on all platforms. So for those (ethernet) devices, splitting out the mii/mdio stuff and _not_ necessarily presenting a working PHY may be acceptable. For now it's going If there isn't a single working PHY, why would one want to attach miibus(4) in the first place? What is about the opposite case, when all you have is a MDIO master and a switch connected to it, but no MAC on the MII lines of the switch? to be a subset, to having it export an MDIO bus and doing late MII attachment may not be as architecturally no-no as I interpret your post. Originally, Stefan said that he wants to find a way to support all the odd combinations found in the embedded-world and I try to come up with model that is able to do that without needing hacks and hints left and right. As imp@ said, interrupt controllers and GPIO basically suffer the same dependency constraints across otherwise unrelated devices there, so we really should find a way to properly deal with that situation without again needing another set of hacks and hints in other types of drivers. As for MDIO you actually can have another layer of dependencies between MDIO master, Ethernet switch and PHY, f.e. at work we use a single MDIO master and switch it to different slave busses using a multiplexer managed via GPIO ... not that I'd ever wanted to support this via generic means in FreeBSD. Marius ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/164569: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386
Old Synopsis: msk network driver cause freeze in FreeBSD 9.0 i386 New Synopsis: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386 Responsible-Changed-From-To: freebsd-i386-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 30 04:10:16 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
