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 <[EMAIL PROTECTED]> wrote:
> > On 6/24/07, Vijay Sankar <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]

Reply via email to