> On Wednesday 27 June 2007 10:50, Tony Lambiris wrote:
> > You might be interested in some unofficial patches I had created when
> > experiencing the same thing. I hadn't officially released these
> > because of the awful DELAY() timeout hack taken from the original nfe
> > code from DragonFly BSD. Most of the updates were taken from NetBSD.
> > Either way, what you would be interested in is the encap_delay stuff,
> > specifically the part in nfe.c where it actually assigns the
> > variable:
> >
> > case PCI_PRODUCT_NVIDIA_CK804_LAN1:
> > case PCI_PRODUCT_NVIDIA_CK804_LAN2:
> > + sc->sc_encap_delay = 10;
> > + break;
> >
> > You would obviously have to locate where your interface matches and
> > assign it there. For me, my interface is a CK804. Not sure if it was
> > LAN1 or LAN2, but I assigned the delay to both anyway.
> >
> > These patches seemed to work good for me, didn't experience any
> > timeouts, YMMV. Let me know if this works. These will apply cleanly
> > against 4.1-RELEASE.
>
> I downloaded your patches and would like to try it out. Thanks very
> much. Because I don't know what I am doing here, I need a bit more
> help. How can I find out whether my interface is also a CK804?
>
> scanpci -v gave me the following:
>
> pci bus 0x0000 cardnum 0x08 function 0x00: vendor 0x10de device 0x0373
> nVidia Corporation MCP55 Ethernet
> CardVendor 0x1043 card 0x8239 (ASUSTeK Computer Inc., Card unknown)
> STATUS 0x00b0 COMMAND 0x0007
> CLASS 0x06 0x80 0x00 REVISION 0xa2
> BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00
> BASE0 0xfe02a000 addr 0xfe02a000 MEM
> BASE1 0x0000b001 addr 0x0000b000 I/O
> BASE2 0xfe029000 addr 0xfe029000 MEM
> BASE3 0xfe028000 addr 0xfe028000 MEM
> MAX_LAT 0x14 MIN_GNT 0x01 INT_PIN 0x01 INT_LINE 0x0a
> BYTE_0 0x43 BYTE_1 0x10 BYTE_2 0x39 BYTE_3 0x82
>
> pci bus 0x0000 cardnum 0x09 function 0x00: vendor 0x10de device 0x0373
> nVidia Corporation MCP55 Ethernet
> CardVendor 0x1043 card 0x8239 (ASUSTeK Computer Inc., Card unknown)
> STATUS 0x00b0 COMMAND 0x0007
> CLASS 0x06 0x80 0x00 REVISION 0xa2
> BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00
> BASE0 0xfe027000 addr 0xfe027000 MEM
> BASE1 0x0000ac01 addr 0x0000ac00 I/O
> BASE2 0xfe026000 addr 0xfe026000 MEM
> BASE3 0xfe025000 addr 0xfe025000 MEM
> MAX_LAT 0x14 MIN_GNT 0x01 INT_PIN 0x01 INT_LINE 0x0a
> BYTE_0 0x43 BYTE_1 0x10 BYTE_2 0x39 BYTE_3 0x82
>
> dmesg shows
>
> nfe0 at pci0 dev 8 function 0 "NVIDIA MCP55 LAN" rev 0xa2: irq 10,
> address 00:17:31:cb:ee:d1
> eephy0 at nfe0 phy 1: Marvell 88E1116 Gigabit PHY, rev. 1
>
> nfe1 at pci0 dev 9 function 0 "NVIDIA MCP55 LAN" rev 0xa2: irq 10,
> address 00:17:31:cb:dd:7a
> eephy1 at nfe1 phy 1: Marvell 88E1116 Gigabit PHY, rev. 1
>
>
>
> >
> >
http://lysergik.com/~tony/openbsd/
> >
> > On 6/25/07, patrick keshishian <pkeshish@gmail.com> wrote:
> > > On 6/24/07, Vijay Sankar <vsankar@foretell.ca> wrote:
> > > > On Sunday 24 June 2007 13:50, patrick keshishian wrote:
> > > > > Hi,
> > > > >
> > > > > I've been noticing some strange problems with the built-in nfe0
> > > > > interface on my desktop. Actually I've seen it on two such
> > > > > computers, but the description below is for my current desktop
> > > > > PC.
> > > > >
> > > > > The PC is running `cvs up -dP -rOPENBSD_4_1' built. I'm
> > > > > including netstat, ifconfig output[1] and dmesg below[2].
> > > > >
> > > > > I've noticed that once in a while the nfe0 interface will stop
> > > > > sending and receiving data. At this point I can not make it
> > > > > work again. The only solution I have is to reboot the box. I
> > > > > have installed a dc0 card in the box since. The problem seemed
> > > > > intermittent and not reliably reproducible. But I think I
> > > > > found a way to reproduce this problem on demand (at least for
> > > > > the time being). I have an ssh session to another box, on
> > > > > which I run '/usr/bin/nm somelib.so'. After a page or two of
> > > > > output the terminal "hangs". At this point nfe0 becomes
> > > > > unresponsive.
> > > > >
> > > > > I switch to the dc0 interface and the terminal finishes the
> > > > > output. Running the nm command while using the dc0 interface
> > > > > doesn't cause any problems.
> > > >
> > > > I experienced similar problems last year and can empathize.
> > > >
> > > > The following items improved my situation somewhat:
> > > >
> > > > 1) BIOS upgrade
> > > > 2) Removing dual boot (I had both OpenBSD and Windows 2003 on one
> > > > machine. There were more errors if I did not power off after
> > > > shutting down Windows 2003 and just did a restart from within
> > > > Windows. If I did not unplug the machine after shutting down
> > > > Windows, most of the time I saw watchdog timeouts but if I
> > > > powered off the host, and then powered it back on, there were
> > > > fewer errors)
> > >
> > > Both boxes I have run solely OpenBSD.
> > >
> > >
> > > One thing that I did notice was that after switching to the dc0
> > > interface for a short while (5 min or so?), I could switch back
> > > to the nfe0 and it would start responding again. Basically:
> > >
> > > # /sbin/ifconfig dc0 delete
> > > # /sbin/route delete default
> > > # /sbin/ifconfig nfe0 inet <IP> netmask <netmask> up
> > > # /sbin/route add default <gateway>
> > >
> > > Therefore, a reboot isn't the only way to "fix" the problem
> > > ("reset" the interface) as I had previously thought. I am not sure
> > > exactly what causes the interface to "reset": idle time, "no
> > > carrier", or something completely random?
> > >
> > >
> > > Either way, thanks for all the replies!
> > >
> > > > I experimented with different combinations and different switches
> > > > (10/100/1000, 10/100, and 10-Base-T). When all the hosts
> > > > connected to a 10/100 switch were running at 100 MB/s then
> > > > changing nfe0 from autoselect to full-duplex using
> > > >
> > > > ifconfig nfe0 media 100baseTX mediaopt full-duplex
> > > >
> > > > seemed to eliminate nfe0 hangs as well as timeouts completely. I
> > > > am not sure whether this has any rational basis or is specific to
> > > > some weird situation in my network, but that has been my
> > > > experience.
> > > >
> > > > Vijay
> > > >
> > > > > Interestingly enough, if I redirect the output of nm to a file
> > > > > and subsequently cat the file the nfe0 interface doesn't seem
> > > > > to exhibit the same problem.
> > > > >
> > > > > I am not sure how to diagnose this problem further. I've
> > > > > enabled debug on the nfe0 interface (/sbin/ifconfig nfe0
> > > > > debug), but don't see any output.
> > > > >
> > > > > Any and all suggestions are welcome.
> > > > > --patrick
> >
> > !DSPAM:1,46828755303376789618724!
>
> --
> Vijay Sankar
> ForeTell Technologies Limited
> 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6
> Phone: +1 (204) 885-9535, E-Mail:
vsankar@foretell.ca
