Re: vr driver trouble on Soekris 5501
Not sure if related, but something similar has been fixed in 4.2-current already. This was also the first thing that came into my mind, however, I don't think it is related. VR_STICKHW is only written erroneously during attach, and since my machine runs now for several weeks without any problem, I doubt that the observed stall has something to do with this. Opinions by the vr maintainers? Anything I can do to debug the problem when it occurs next time?
Re: vr driver trouble on Soekris 5501
for the record, i have a via rhine2 and i never had trouble. (if they are not related i'm sorry to bother you, but it might help debugging) vr0 at pci0 dev 18 function 0 VIA RhineII-2 rev 0x51: irq 10, address 00:40:63:c9:5c:05 this is the one on the via c3 533Mhz board. alwin [demime 1.01d removed an attachment of type application/pgp-signature]
Re: vr driver trouble on Soekris 5501
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Plattner Sent: Friday, October 12, 2007 4:43 PM To: misc@openbsd.org Subject: Re: vr driver trouble on Soekris 5501 Not sure if related, but something similar has been fixed in 4.2-current already. This was also the first thing that came into my mind, however, I don't think it is related. VR_STICKHW is only written erroneously during attach, and since my machine runs now for several weeks without any problem, I doubt that the observed stall has something to do with this. Opinions by the vr maintainers? Anything I can do to debug the problem when it occurs next time? For what it's worth, I experienced the same problem caused by attaching and detaching a (short) crossover cable multiple times on a vr interface in soekris net5501 running 4.1-stable. As it was on a production firewall I didn't troubleshoot much, tcpdump didn't show any incoming traffic on that interface - then I went for a quick reboot that obviously fixed things. Let me see if I can replicate it in lab. Mitja
Re: vr driver trouble on Soekris 5501
For what it's worth, I experienced the same problem caused by attaching and detaching a (short) crossover cable multiple times on a vr interface in The cable used in the situation when things went wrong was also short, 1m. soekris net5501 running 4.1-stable. As it was on a production firewall I didn't troubleshoot much, tcpdump didn't show any incoming traffic on that OK, same phenomenon. interface - then I went for a quick reboot that obviously fixed things. Let me see if I can replicate it in lab. That would be very nice - unfortunately, I don't have any spare Soekris 5501 boxes.
Re: vr driver trouble on Soekris 5501
Are these interfaces configured in autoselect mode? What happens when you configure them in fixed mode, e.g. 100Mb/full duplex? Sounds like a good idea. In the future, I will configure them in fixed mode, it won't hurt. Even though it may have something to do with the autoselect mode, the whole story still has a bad smell =) I mean, the problem persisted even though I several times disconnected the cable, changed the cable, hooked the Soekris to a Dell 5324 Switch (to a port in autoselect mode) and nevertheless the interface did not get out of the stalled state until I did the ifconfig down/up sequence.
Re: vr driver trouble on Soekris 5501
On 12/10/2007, Christian Plattner [EMAIL PROTECTED] wrote: Hi, Today something strange happened on one of my Soekris 5501 boxes, it runs OpenBSD 4.1-stable. The box is connected with a cross-over cable to another machine via the vr1 interface (the box has 4 vr interfaces). Problem: After having rebooted the machine at the other end of the cable multiple times, the Soekris box suddenly stopped receiving packets on the vr1 interface. After playing around with ping and tcpdump on both sides I found out that the vr1 interface allowed me to send packets, but incoming packets did no show up in tcpdump, even though the LED on the interface was flickering. I changed the cable, connected the vr1 of the Soekris to another machine, then to a switch port with lots of broadcast traffic etc.etc. nothing helped, ingress traffic on vr1 did not show up in tcpdump. Solution: Finally, immediatelly after doing ifconfig vr1 down ifconfig vr1 up everything worked again as normal. The link on vr1 is currently only used to do SSH between the two machines, so this is really a low traffic link. On the other hand, vr0,vr2,vr3 are heavily used (BGP sessions etc., the Soekris is at the border of my AS). btw: the machine at the other end of the cable is a Soekris 5501 as well. Had to reboot it to perform a BIOS upgrade. No suspicious output in dmesg. Any ideas on how I could further track down the problem? Thanks, Christian The vr interfaces in dmesg: vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:c8:de:68 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:c8:de:69 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:c8:de:6a ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:c8:de:6b ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 # ifconfig vr1 vr1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:24:c8:de:69 media: Ethernet autoselect (100baseTX full-duplex) status: active inet XX.XX.XX.XX netmask 0xffe0 broadcast XX.XX.XX.YY inet6 fe80::200:24ff:fec8:de69%vr1 prefixlen 64 scopeid 0x2 Not sure if related, but something similar has been fixed in 4.2-current already. http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076486.html http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_vr.c#rev1.70 I think you should be able to safely apply the 1.69 to 1.70 diff to your source tree if this is of a concern. The diff is for vr_attach() only, so if your system is already up and running and you never reboot it, then you probably shouldn't bother until your next upgrade. Cheers, Constantine.
Re: vr driver trouble on Soekris 5501
Christian Plattner [EMAIL PROTECTED] wrote: Problem: After having rebooted the machine at the other end of the cable multiple times, the Soekris box suddenly stopped receiving packets on the vr1 interface. I think I've observed something likes this _once_ on my 5501 with 4.2. Any ideas on how I could further track down the problem? Find a way to reproduce it with some regularity? -- Christian naddy Weisgerber [EMAIL PROTECTED]
