From nobody@FreeBSD.org  Sun Aug 22 20:22:21 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 76FA616A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 22 Aug 2004 20:22:21 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5E13543D49
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 22 Aug 2004 20:22:21 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i7MKMLw9076423
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 22 Aug 2004 20:22:21 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.11/8.12.11/Submit) id i7MKMKoh076422;
	Sun, 22 Aug 2004 20:22:20 GMT
	(envelope-from nobody)
Message-Id: <200408222022.i7MKMKoh076422@www.freebsd.org>
Date: Sun, 22 Aug 2004 20:22:20 GMT
From: Marian Cerny <jojo@matfyz.cz>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Serious problems with RealTek NIC using re0 driver on Evo N1015v
X-Send-Pr-Version: www-2.3

>Number:         70832
>Category:       i386
>Synopsis:       [re] re0: watchdog timeout on Evo N1015v
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 22 20:30:25 GMT 2004
>Closed-Date:    Mon Oct 25 21:18:20 UTC 2010
>Last-Modified:  Mon Oct 25 21:18:20 UTC 2010
>Originator:     Marian Cerny
>Release:        FreeBSD 5.2.1R
>Organization:
>Environment:
FreeBSD potvorka 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Wed Aug 18 10:10:26 CEST 2004
majo@potvorka:/usr/src/sys/i386/compile/POTVORKA  i386
>Description:
I have got serious problems with my 're0: <RealTek 8139C+ 10/100BaseTX>'
network card. I have got two exactly the same laptops: Compaq Evo N1015v. I
have got a few problems with this NIC on both laptops.

I would like to notice that there was none of this problem on FreeBSD 5.1R when
the NICs were using the rl driver.

*Rarely* the machine hangs on boot (the kernel panics). It happens
approximately once a month. Keyboard is not working, so I can not debug this
more. Here are the messages, that are writen to the screen:

--------------------------------------------------------------------------

pcm0: <Analog Devices AD1886A AC97 Codec>
pci0: <bridge, PCI-CardBus> at device 10.0 (no driver attached)
re0: <RealTek 8139C+ 10/100BaseTX> port 0x8800-0x88ff mem 0xf0013000-0xf00130ff
irg 11 at device 11.0 on pci0
re0: Ethernet address: 00:0b:cd:84:25:06
miibus0: <MII bus> on re0
rlphy0: <RealTek internal media interface> on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: diagnostic failed, failed to receive packet in loopback mode
re0: attach aborted due to hardware diag failure


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x7c
fault code              = supervisor read, page net present
instruction pointer     = 0x8:0xc04fb503
stack pointer           = 0x10:0xc08219e4
frame pointer           = 0x10:0xc0821a00
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at      _mtx_lock_flags+0x43:   cmpl    $0xc06ab05c,0(%ebx)
db>

--------------------------------------------------------------------------

The other problem is, when I am turning off the laptop using 'halt -p' with
ACPI. *Often* the kernel panics here. It's like with 40% probability on one
laptop and around 80% probability on the other one. The laptops are exactly the
same, only one has got 512M + 128M memory and the other one has got 256M + 128M
memory. I have tried this with usb support compiled in, and also without it
(because there is ohci0+ in current process). The result is the same. Here are
the messages:

--------------------------------------------------------------------------

-bash-2.05b# halt -p
Aug 18 10:51:52 potvorka halt: halted by root
Aug 18 10:51:53 potvorka syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped

syncing disks, buffers remaining... 8 8 1 1
done
Uptime: 5m56s
Powering system off using ACPI

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc
fault code              = supervisor read, page net present
instruction pointer     = 0x8:0xc0475087
stack pointer           = 0x10:0xd156ec9c
frame pointer           = 0x10:0xd156ecc8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 22 (irq11: re0 ohci0+)
kernel: type 12 trap, code=0
Stopped at      re_rxeof+0x287: movl    %eax,0xc(%ebx)
db> trace
re_rxeof(c334a000,0,c0658482,71f,c336cd00) at re_rxeof+0x287
re_intr(c334a000,0,c06648ec,21f,c152ce20) at re_intr+0xc4
ithread_loop(c1522800,d156ed48,c0664766,311,c1522800) at ithread_loop+0x172
fork_exit(c04f1910,c1522800,d156ed48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd156ed7c, ebp = 0 ---
db> panic
panic: from debugger
Stack backtrace:
backtrace(c0666cfd,c06d07e0,c065486e,d156ea88,100) at backtrace+0x17
panic(c065486e,d156eb40,c043a56a,c0475087,0) at panic+0xb7
db_panic(c0475087,0,ffffffff,d156eab4,d156eab0) at db_panic+0x12
db_command(c06c6520,c0686320,c0680e34,c0680e38,10) at db_command+0x25a
db_command_loop(c0475087,c06f7d00,d156eb8c,c054d423,0) at db_command_loop+0x78
db_trap(c,0,0,246,1) at db_trap+0xb9
kbd_trap(c,0,d156ec5c,1,1) at kdb_trap+0x1b3
trap_fatal(d156ec5c,c,c067c786,2cd,c1527c80) at trap_fatal+0x2b8
trap_pfault(d156ec5c,0,c,12e800,c) at trap_pfault+0x1c1
trap(18,10,10,31022072,2) at trap+0x2f3
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc0475087, esp = 0xd156ec9c, ebp = 0xd156ecc8 ---
re_rxeof(c334a000,0,c0658482,71f,c336cd00) at re_rxeof+0x287
re_intr(c334a000,0,c06648ec,21f,c152ce20) at re_intr+0xc4
ithread_loop(c1522800,d156ed48,c0664766,311,c1522800) at ithread_loop+0x172
fork_exit(c04f1910,c1522800,d156ed48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd156ed7c, ebp = 0 ---
Debugger("panic")

Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer     = 0x8:0xc061d70d
stack pointer           = 0x10:0xd156ea44
frame pointer           = 0x10:0xd156ea50
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = IOPL = 0
current process         = 22 (irg11: re0 ohci0+)
Stopped at      re_rxeof+0x287: movl    %eax,0xc(%ebx)
db> call boot(0)
Uptime: 6m1s
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xdeadc0e2
fault code              = supervisor read, page net present
instruction pointer     = 0x8:0xc0520155
stack pointer           = 0x10:0xd156e990
frame pointer           = 0x10:0xd156e9a8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 22 (irg11: re0 ohci0+)
kernel: type 12 trap, code=0
Stopped at      eventhandler_deregister+0x45:   movl    %eax,0x4(%edx)
db> panic
panic: from debugger
Uptime: 6m2s
Dumping 352 MB
 12 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336
Dump complete
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xdeadc0e2
fault code              = supervisor read, page net present
instruction pointer     = 0x8:0xc0520155
stack pointer           = 0x10:0xd156e6bc
frame pointer           = 0x10:0xd156e6b4
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 22 (irg11: re0 ohci0+)
kernel: type 12 trap, code=0
Stopped at      eventhandler_deregister+0x45:   movl    %eax,0x4(%edx)
db>

*** I turned the laptop off

--------------------------------------------------------------------------

The last problem I have, that *everytime* I try to use cvsup to upgrade ports
tree (or source tree), the networks goes completely down after some seconds
(sometimes minutes).

--------------------------------------------------------------------------

-bash-2.05b# cvsup ports-supfile
Connected to cvsup.FreeBSD.cz
Updating collection ports-all/cvs
 Edit ports/MOVED
 Edit ports/benchmarks/himenobench/Makefile
 Edit ports/benchmarks/himenobench/pkg-plist
 Edit ports/devel/distcc/Makefile
 Edit ports/devel/p5-ExtUtils-XSBuilder/Makefile
 Edit ports/devel/p5-ExtUtils-XSBuilder/distinfo
 Edit ports/devel/p5-ExtUtils-XSBuilder/pkg-plist
 Edit ports/devel/root/Makefile
 Delete ports/ftp/lukemftpd/Makefile
 Delete ports/ftp/lukemftpd/distinfo
 Delete ports/ftp/lukemftpd/files/patch-ftpd.c
 Delete ports/ftp/lukemftpd/files/patch-logutmp.c
 Delete ports/ftp/lukemftpd/files/patch-logwtmp.c
 Delete ports/ftp/lukemftpd/files/patch-src-Makefile.in
 Delete ports/ftp/lukemftpd/pkg-descr
 Delete ports/ftp/lukemftpd/pkg-plist
 Edit ports/java/jdk14/Makefile
re0: watchdog timeout
re0: watchdog timeout
^C^C^CInterrupted

--------------------------------------------------------------------------

This re0: watchdog timeout repeats here. The network goes down, it is not
possible to (for example) ping google - there is no responsee. When I do:

        $ killall dhclient
        $ ifconfig re0 down
        $ dhlcient re0

Then I can again 'ping www.google.com', I get 2 to 5 packets in response and
the network goes down again. I must reboot the machine.

All these problems seems to be connected to me. Might be not.
>How-To-Repeat:
Use Compaq Evo N1015v with ACPI enabled and try to power off the system with 'halt -p'. Or try to use cvsup to update ports tree.
>Fix:
Not known. It works fine on FreeBSD 5.1R
>Release-Note:
>Audit-Trail:

From: Marian Cerny <jojo@matfyz.cz>
To: freebsd-gnats-submit@FreeBSD.org, jojo@matfyz.cz
Cc:  
Subject: Re: i386/70832: Serious problems with RealTek NIC using re0 driver on Evo N1015v
Date: Wed, 8 Sep 2004 07:49:38 +0200

 While I was testing 5.3-BETA3 and tried to use cvsup, this panic came
 after 10 minutes of cvsuping ports tree. This can be related to one of
 mine problems (most possibly with the third).
 
 panic: re_start: attempted use of a free mbug!
 cpuid = 0
 KDB: enter: panic
 [thread 100001]
 Stopped at      kdb_enter+0x2b: nop
 db> trace
 kdb_enter(c07f088b) at kdb_enter+0x2b
 panic(c07c5518,c07a5a7c,c177b0e8,c177b0e8,14) at panic+0x127
 re_start(c177b000) at re_start+0x147
 if_start(c177b000) at if_start+0x7b
 ether_output_frame(c177b000,c17d3700,f00,0,0) at ether_output_frame+0x1d9
 ether_output(c177b000,c17d3700,c19c4050,c1991948,c1a80b00) at ether_output+0x37c
 ip_output(c17d3700,0,ceec3acc,0,0) at ip_output+0x6f0
 tcp_output(c19b8a80,0,0,1,0) at tcp_output+0x1004
 tcp_input(c17dae00,14,5105cb0a,0,1) at tcp_input+0x21cf
 ip_input(c17dae00) at ip_input+0x4fd
 netisr_processqueue(c08e2d38) at netisr_processqueue
 swi_net(0) at swi_net+0xbe
 ithread_loop(c16bf080,ceec3d48,c16bf080,c05ed66c,0) at ithread_loop+0x124
 fork_exit(c05ed66c,c16bf080,ceec3d48) at fork_exit+0xa4
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0x1, eip = 0, esp = 0xceec3d7c, ebp = 0 ---
 db>
 
 I still have problems 2 and 3 on 5.3-BETA3. The problem 1 happened
 rarely, so I don't know yet, if it is still present in 5.3-BETA3.
 
 Marian Cerny
 
 -- 
 Marian Cerny <jojo@matfyz.cz>
 Jabber: jojo@njs.netlab.cz
 
 [ UNIX is user friendly. It's just selective about who its friends are. ]

From: Russell Jackson <rjackson@cserv63.csub.edu>
To: freebsd-gnats-submit@freebsd.org, jojo@matfyz.cz
Cc:  
Subject: Re: i386/70832: Serious problems with RealTek NIC using re0 on Evo N1015v
Date: Tue, 5 Oct 2004 10:57:47 -0700 (PDT)

 We're on 5.3BETA7 now, and this problem persists. The internal RT8139C+
 on my Compaq Presario 900 is complete unusable.
 
 Not only do I get the watchog timeouts and random panics at shutdown, but
 often the loopback test fails and the driver doesn't attach.Obviously, I'm
 not on a 64bit bus, so this test should not fail.
 
 Turning off ACPI does not seem to correct the problem, but I'm not certain that
 it rules it out as a source.
 
 I know many others have also reported this problem on freebsd-current. I have
 personally sent several messages to Bill Paul (maintainer) about the issue, but
 have never recieved a response.

From: Andrew Belashov <bel@orel.ru>
To: freebsd-gnats-submit@FreeBSD.org, jojo@matfyz.cz,
	rjackson@cserv63.csub.edu
Cc:  
Subject: Re: i386/70832: Serious problems with RealTek NIC using re0 driver
 on Evo N1015v
Date: Tue, 19 Oct 2004 10:45:01 +0400

 Try a patch from PR/61448:
 
 <http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61448>
 

From: Russell Jackson <raj@cserv63.csub.edu>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: re: i386/70832
Date: Wed, 27 Oct 2004 09:34:12 -0700

 That patch is for the if_rl driver and 4.x. This problem is specific to the
 if_re driver that appeared in 5.x-CURRENT after Bill Paul split the
 functionality for the RT8139C+ from if_rl out into if_re.
 
 My mailer was misconfigured and was sending with the wrong address in the from field.
 Sorry about any bounces that may have resulted.
 
 -- 
 Russell A. Jackson
 Q:  If Tarzan was Jewish, and Jane was a princess, what would Cheetah
     be?
 A:  A fur coat.

From: Florian Klemenz <fok@gmx.net>
To: freebsd-gnats-submit@FreeBSD.org, jojo@matfyz.cz
Cc:  
Subject: Re: i386/70832: Serious problems with RealTek NIC using re0 driver on Evo N1015v
Date: Sat, 30 Oct 2004 15:57:40 +0200

 I have exactly the same problems on my Compaq Evo N1015V using 5.3-RC1
 as Russell Jackson described (watchdog timeouts, loopback test
 failures).
 
 Interesting is that I had no problems doing a ftp installation from
 the three boot floppies using that NIC.
 What makes the floppy kernel different from GENERIC?
 
 I would suggest increasing severity and/or priority of this PR, since
 re(4) explicitly states to support "Compaq Evo N1015v Integrated
 Ethernet (8139C+)" which currently seems not to be the case.
 
 Florian Klemenz
 
 
 
 
 
 
 

From: Marian Cerny <jojo@matfyz.cz>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Russell Jackson <rjackson@cserv63.csub.edu>,
	Andrew Belashov <bel@orel.ru>, Florian Klemenz <fok@gmx.net>,
	John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Subject: Re: i386/70832: Serious problems with RealTek NIC using re0 driver on Evo N1015v
Date: Fri, 11 Feb 2005 11:52:31 +0100

 All of my problems are still actual on FreeBSD 5.3R, too :-(.
 
 Kernel panics on 'halt -p' always when network cable is connected. When
 network cable is plugged out, there is no panic at all and the laptop
 correctly turns itself off.
 
 Today I have discovered (thanks to pav@FreeBSD.org), that setting
 
 	> ifconfig re0 -txcsum -rxcsum
 
 solves most of my problems. cvsup works ok, no kernel panic on 'halt -p'
 even when the network cable is plugged in. Of course it does not solve
 "rarely hangs at boot", because the setting is applied after boot.
 
 I have not tested the "-txcsum -rxcsum" for long time, just for a few
 hours.
 
 Should I divide this PR (each subproblem into separate PR)?
 
 Other similar problems found:
 
  o PR kern/76551
     - re0: watchdog timeout problem
  o http://freebsd.rambler.ru/bsdmail/freebsd-current_2004/msg07324.html
     - problem with checksum offloading on re
  o http://freebsd.rambler.ru/bsdmail/freebsd-current_2004/msg20316.html
     - re0 device txcsum issue
 
 Would be great if this could be fixed before 5.4R.
 
 --
 Marian Cerny <jojo@matfyz.cz>
 Jabber: jojo@njs.netlab.cz
State-Changed-From-To: open->feedback 
State-Changed-By: gavin 
State-Changed-When: Thu Jun 28 17:19:30 UTC 2007 
State-Changed-Why:  

To submitter:  Is this still a problem on more recent versions of FreeBSD? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70832 

From: Marian Cerny <jojo@matfyz.cz>
To: bug-followup@FreeBSD.org
Cc: Gavin Atkinson <gavin@FreeBSD.org>, freebsd-i386@FreeBSD.org
Subject: Re: i386/70832: [re] serious problems with RealTek NIC using re0 driver on Evo N1015v
Date: Wed, 25 Jul 2007 09:03:56 +0200

 I tried to reproduce those problems on FreeBSD 6.2R.
 
 1. I was not able to reproduce the first problem with sporadic hangs at
    boot. However I have not tested the laptop for long enough period.
 
 2. I was not able to reproduce the panic on 'halt -p'. This problem
    seems to be fixed.
 
 3. I WAS able to reproduce the last problem with cvsup & "re0: watchdog
    timeout". But there is a difference in the behaviour. Now when
    watchdog timeouts appear on the screen, the network is still usable.
    The cvsup does not finish successfully. When I tried csup, there also
    was a problem with watchdog timeouts, however the csup doesn't seem
    to block itself and it finishes its job successfully.
 
 The problems are definitely less serious than in FreeBSD 5.2.1R.
 
 Marian Cerny
State-Changed-From-To: feedback->open 
State-Changed-By: gavin 
State-Changed-When: Mon Jul 30 10:35:58 UTC 2007 
State-Changed-Why:  
Feedback was received 


Responsible-Changed-From-To: freebsd-i386->freebsd-net 
Responsible-Changed-By: gavin 
Responsible-Changed-When: Mon Jul 30 10:35:58 UTC 2007 
Responsible-Changed-Why:  
Reassign 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70832 
Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Mon Jul 30 10:59:16 UTC 2007 
Responsible-Changed-Why:  
Grab. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70832 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: jojo@matfyz.cz
Cc: bug-followup@FreeBSD.org
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Mon, 30 Jul 2007 20:04:59 +0900

 On Mon, Jul 30, 2007 at 10:59:47AM +0000, yongari@FreeBSD.org wrote:
  > Synopsis: [re] re0: watchdog timeout on Evo N1015v
  > 
  > Responsible-Changed-From-To: freebsd-net->yongari
  > Responsible-Changed-By: yongari
  > Responsible-Changed-When: Mon Jul 30 10:59:16 UTC 2007
  > Responsible-Changed-Why: 
  > Grab.
  > 
  > http://www.freebsd.org/cgi/query-pr.cgi?pr=70832
 
 Would you show me verbosed boot messages related with re(4)?
 Also I'd like to see the output of "vmstat -i".
 
 -- 
 Regards,
 Pyun YongHyeon

From: Marian Cerny <jojo@matfyz.cz>
To: bug-followup@FreeBSD.org
Cc: Remko Lodder <remko@elvandar.org>
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Wed, 1 Aug 2007 14:46:18 +0200

 On 2007-07-26 10:59 +0200, Remko Lodder wrote:
 > Would it be possible to checkout 6-STABLE? (which will become 6.3 at some
 > point) to see whether that already resolved the known issues or not?
 > 
 > And if that would be possible... -CURRENT is also undergoing major changes
 > which also could already have resolved the mentioned problems.
 
 I was able to reproduce the "re0: watchdog timeout" problem on both
 6-STABLE and -CURRENT. 
 
 Marian Cerny

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Marian Cerny <jojo@matfyz.cz>
Cc: yongari@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Thu, 2 Aug 2007 10:33:27 +0900

 On Wed, Aug 01, 2007 at 12:50:10PM +0000, Marian Cerny wrote:
  > The following reply was made to PR i386/70832; it has been noted by GNATS.
  > 
  > From: Marian Cerny <jojo@matfyz.cz>
  > To: bug-followup@FreeBSD.org
  > Cc: Remko Lodder <remko@elvandar.org>
  > Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
  > Date: Wed, 1 Aug 2007 14:46:18 +0200
  > 
  >  On 2007-07-26 10:59 +0200, Remko Lodder wrote:
  >  > Would it be possible to checkout 6-STABLE? (which will become 6.3 at some
  >  > point) to see whether that already resolved the known issues or not?
  >  > 
  >  > And if that would be possible... -CURRENT is also undergoing major changes
  >  > which also could already have resolved the mentioned problems.
  >  
  >  I was able to reproduce the "re0: watchdog timeout" problem on both
  >  6-STABLE and -CURRENT. 
  >  
  >  Marian Cerny
 
 Check whether re(4) uses shared interrupt with other devices.
 (You can check the output of "vmstat -i".)
 If re(4) shares interrupt, try polling(4) which is supposed to be
 more suitable on shared interrupt environments.
 
 -- 
 Regards,
 Pyun YongHyeon

From: Marian Cerny <cerny@icomvision.com>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: bug-followup@FreeBSD.org, yongari@FreeBSD.org
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Mon, 6 Aug 2007 19:58:37 +0200

 On 2007-07-30 20:04 +0900, Pyun YongHyeon wrote:
 > Would you show me verbosed boot messages related with re(4)?
 > Also I'd like to see the output of "vmstat -i".
 
 Verbose boot messages (from -CURRENT) are available at
 http://artax.karlin.mff.cuni.cz/~cernm0bm/bugs/freebsd/70832.dmesg.boot.txt
 
 The output from vmstat -i:
 interrupt                          total       rate
 irq0: clk                         193756        993
 irq1: atkbd0                         626          3
 irq6: fdc0                            33          0
 irq8: rtc                          24829        127
 irq9: cbb0 acpi0                       3          0
 irq11: re0 ohci0+                     18          0
 irq14: ata0                          974          4
 irq15: ata1                           59          0
 Total                             220298       1129
 
 On 2007-08-02 10:33 +0900, Pyun YongHyeon wrote:
 > Check whether re(4) uses shared interrupt with other devices.
 > (You can check the output of "vmstat -i".)
 > If re(4) shares interrupt, try polling(4) which is supposed to be
 > more suitable on shared interrupt environments.
 
 Seems that re0 is using shared interrupt. I have recompiled the kernel
 (-CURRENT) with polling and enabled polling for re0 (ifconfig re0
 polling), but the "re0: watchdog timeout" messages still keeps appearing
 approximately one minute after running cvsup.
 
 Marian Cerny

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Marian Cerny <cerny@icomvision.com>
Cc: bug-followup@FreeBSD.org, yongari@FreeBSD.org
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Tue, 7 Aug 2007 09:11:44 +0900

 On Mon, Aug 06, 2007 at 07:58:37PM +0200, Marian Cerny wrote:
  > On 2007-07-30 20:04 +0900, Pyun YongHyeon wrote:
  > > Would you show me verbosed boot messages related with re(4)?
  > > Also I'd like to see the output of "vmstat -i".
  > 
  > Verbose boot messages (from -CURRENT) are available at
  > http://artax.karlin.mff.cuni.cz/~cernm0bm/bugs/freebsd/70832.dmesg.boot.txt
  > 
  > The output from vmstat -i:
  > interrupt                          total       rate
  > irq0: clk                         193756        993
  > irq1: atkbd0                         626          3
  > irq6: fdc0                            33          0
  > irq8: rtc                          24829        127
  > irq9: cbb0 acpi0                       3          0
  > irq11: re0 ohci0+                     18          0
  > irq14: ata0                          974          4
  > irq15: ata1                           59          0
  > Total                             220298       1129
  > 
  > On 2007-08-02 10:33 +0900, Pyun YongHyeon wrote:
  > > Check whether re(4) uses shared interrupt with other devices.
  > > (You can check the output of "vmstat -i".)
  > > If re(4) shares interrupt, try polling(4) which is supposed to be
  > > more suitable on shared interrupt environments.
  > 
  > Seems that re0 is using shared interrupt. I have recompiled the kernel
  > (-CURRENT) with polling and enabled polling for re0 (ifconfig re0
  > polling), but the "re0: watchdog timeout" messages still keeps appearing
  > approximately one minute after running cvsup.
  > 
 
 That's odd. polling(4) does not depend on timed interrupt delivery.
 Tx completion handler is processed by periodic kernel poll handler
 under polling. So there should be no lost Tx completion interrupt.
 Since you still suffer from watchdog timeouts the watchdog timeout
 might be real hardware issue. How about disaling acpi(4)?
 Did you try other OSes on your hardware?
 It seems that you have 8139C+(100Mbps only) based NIC. I guess it's
 somewhat rare in these days so re(4) might have other (unknown) issues
 on 8139C+ hardwares. However I don't know any known issues on 8139C+
 yet.
 
 -- 
 Regards,
 Pyun YongHyeon

From: Marian Cerny <jojo@matfyz.cz>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: bug-followup@FreeBSD.org, yongari@FreeBSD.org
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Tue, 14 Aug 2007 09:11:18 +0200

 On 2007-08-07 09:11 +0900, Pyun YongHyeon wrote:
 > That's odd. polling(4) does not depend on timed interrupt delivery.
 > Tx completion handler is processed by periodic kernel poll handler
 > under polling. So there should be no lost Tx completion interrupt.
 > Since you still suffer from watchdog timeouts the watchdog timeout
 > might be real hardware issue. How about disaling acpi(4)?
 
 Disabling ACPI does not help either.
 
 > Did you try other OSes on your hardware?
 
 Yes (Windows, older FreeBSD with rl driver), without any problems
 noticed. But even with the re driver there are no problems except for
 cvsup (or csup).
 
 I have noticed that when I run tcpdump, the "re0: watchdog timeout"
 message appears 2-4 seconds after this packet is logged by tcpdump:
 
 18:16:09.563908 IP 192.168.41.127.57685 > 195.113.15.29.5999: .
 0:1448(1448) ack 1 win 260 <nop,nop,timestamp 423252 963334269>
 
 This packet however does not appear on the gateway (probably not
 transmitted into LAN).
 
 Marian Cerny

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Marian Cerny <jojo@matfyz.cz>
Cc: bug-followup@FreeBSD.org, yongari@FreeBSD.org
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Tue, 14 Aug 2007 16:17:22 +0900

 On Tue, Aug 14, 2007 at 09:11:18AM +0200, Marian Cerny wrote:
  > On 2007-08-07 09:11 +0900, Pyun YongHyeon wrote:
  > > That's odd. polling(4) does not depend on timed interrupt delivery.
  > > Tx completion handler is processed by periodic kernel poll handler
  > > under polling. So there should be no lost Tx completion interrupt.
  > > Since you still suffer from watchdog timeouts the watchdog timeout
  > > might be real hardware issue. How about disaling acpi(4)?
  > 
  > Disabling ACPI does not help either.
  > 
  > > Did you try other OSes on your hardware?
  > 
  > Yes (Windows, older FreeBSD with rl driver), without any problems
  > noticed. But even with the re driver there are no problems except for
  > cvsup (or csup).
  > 
 
 Ok, then show me the output of "ifconfig re0" output.
 
  > I have noticed that when I run tcpdump, the "re0: watchdog timeout"
  > message appears 2-4 seconds after this packet is logged by tcpdump:
  > 
  > 18:16:09.563908 IP 192.168.41.127.57685 > 195.113.15.29.5999: .
  > 0:1448(1448) ack 1 win 260 <nop,nop,timestamp 423252 963334269>
  > 
  > This packet however does not appear on the gateway (probably not
  > transmitted into LAN).
  > 
  > Marian Cerny
 
 -- 
 Regards,
 Pyun YongHyeon

From: Jayson <jekubili@ktechs.net>
To: bug-followup@FreeBSD.org, jojo@matfyz.cz
Cc:  
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Sun, 29 Jun 2008 20:47:12 -0400

 I'm having the exact same issue on some embedded hardware which uses  
 the 8139C+ RealTek chipset.  Device will run ok for a day or two but  
 then start to see the watchdog timeouts in dmesg with stopped network  
 traffic until the watchdog process resets the card.  I've tried 6.2  
 then 6.3 release and current and have the same symptoms.
 
 Here's my info from what was provided above:
 vmstat -i yields:
 
 interrupt                          total       rate
 irq0: clk                         233835         99
 irq3: safe0                           75          0
 irq4: sio0                          6657          2
 irq5: re1                          36184         15
 irq7: ppc0                             1          0
 irq8: rtc                         299295        127
 irq10: re0                        111082         47
 irq11: re2                         16823          7
 irq14: ata0                        38620         16
 Total                             742572        317
 
 ifconfig re1:
 re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 	options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
 	inet 172.17.60.1 netmask 0xffffff00 broadcast 172.17.60.255
 	inet6 fe80::290:7fff:fe30:f282%re1 prefixlen 64 scopeid 0x2
 	ether 00:90:7f:30:f2:82
 	media: Ethernet autoselect (100baseTX <full-duplex>)
 	status: active
 
 
 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Jayson <jekubili@ktechs.net>
Cc: yongari@FreeBSD.org, bug-followup@FreeBSD.org, jojo@matfyz.cz
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Wed, 16 Jul 2008 13:07:40 +0900

 --IS0zKkzwUGydFO0o
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Mon, Jun 30, 2008 at 01:30:06AM +0000, Jayson wrote:
  > The following reply was made to PR i386/70832; it has been noted by GNATS.
  > 
  > From: Jayson <jekubili@ktechs.net>
  > To: bug-followup@FreeBSD.org, jojo@matfyz.cz
  > Cc:  
  > Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
  > Date: Sun, 29 Jun 2008 20:47:12 -0400
  > 
  >  I'm having the exact same issue on some embedded hardware which uses  
  >  the 8139C+ RealTek chipset.  Device will run ok for a day or two but  
  >  then start to see the watchdog timeouts in dmesg with stopped network  
  >  traffic until the watchdog process resets the card.  I've tried 6.2  
  >  then 6.3 release and current and have the same symptoms.
  >  
  >  Here's my info from what was provided above:
  >  vmstat -i yields:
  >  
  >  interrupt                          total       rate
  >  irq0: clk                         233835         99
  >  irq3: safe0                           75          0
  >  irq4: sio0                          6657          2
  >  irq5: re1                          36184         15
  >  irq7: ppc0                             1          0
  >  irq8: rtc                         299295        127
  >  irq10: re0                        111082         47
  >  irq11: re2                         16823          7
  >  irq14: ata0                        38620         16
  >  Total                             742572        317
  >  
  >  ifconfig re1:
  >  re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  >  	options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
  >  	inet 172.17.60.1 netmask 0xffffff00 broadcast 172.17.60.255
  >  	inet6 fe80::290:7fff:fe30:f282%re1 prefixlen 64 scopeid 0x2
  >  	ether 00:90:7f:30:f2:82
  >  	media: Ethernet autoselect (100baseTX <full-duplex>)
  >  	status: active
 
 Recently I've fixed a couple of bugs in re(4) which might help
 your issue. Would yoy try re(4) in latest RELENG_7 after applying
 attached patch?(The patch was generated against HEAD but it would
 apply to RELENG_7 too.)
 
 Thanks!
 -- 
 Regards,
 Pyun YongHyeon
 
 --IS0zKkzwUGydFO0o
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="re.link.patch4"
 
 Index: sys/pci/if_rlreg.h
 ===================================================================
 --- sys/pci/if_rlreg.h	(revision 180537)
 +++ sys/pci/if_rlreg.h	(working copy)
 @@ -839,6 +839,7 @@
  #define	RL_FLAG_PAR		0x0020
  #define	RL_FLAG_DESCV2		0x0040
  #define	RL_FLAG_MACSTAT		0x0080
 +#define	RL_FLAG_FASTETHER	0x0100
  #define	RL_FLAG_LINK		0x8000
  };
  
 Index: sys/dev/re/if_re.c
 ===================================================================
 --- sys/dev/re/if_re.c	(revision 180537)
 +++ sys/dev/re/if_re.c	(working copy)
 @@ -596,7 +596,38 @@
  re_miibus_statchg(dev)
  	device_t		dev;
  {
 +	struct rl_softc		*sc;
 +	struct ifnet		*ifp;
 +	struct mii_data		*mii;
  
 +	sc = device_get_softc(dev);
 +	mii = device_get_softc(sc->rl_miibus);
 +	ifp = sc->rl_ifp;
 +	if (mii == NULL || ifp == NULL ||
 +	    (ifp->if_drv_flags & IFF_DRV_RUNNING) == 0)
 +		return;
 +
 +	sc->rl_flags &= ~RL_FLAG_LINK;
 +	if ((mii->mii_media_status & IFM_AVALID) != 0) {
 +		switch (IFM_SUBTYPE(mii->mii_media_active)) {
 +		case IFM_10_T:
 +		case IFM_100_TX:
 +			sc->rl_flags |= RL_FLAG_LINK;
 +			break;
 +		case IFM_1000_T:
 +			if ((sc->rl_flags & RL_FLAG_FASTETHER) != 0)
 +				break;
 +			sc->rl_flags |= RL_FLAG_LINK;
 +			break;
 +		default:
 +			break;
 +		}
 +	}
 +	/*
 +	 * RealTek controllers does not provide any interface to
 +	 * Tx/Rx MACs for resolved speed, duplex and flow-control
 +	 * parameters.
 +	 */
  }
  
  /*
 @@ -1238,17 +1269,18 @@
  
  	switch (hw_rev->rl_rev) {
  	case RL_HWREV_8139CPLUS:
 -		sc->rl_flags |= RL_FLAG_NOJUMBO;
 +		sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_FASTETHER;
  		break;
  	case RL_HWREV_8100E:
  	case RL_HWREV_8101E:
  		sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
 -		    RL_FLAG_PHYWAKE;
 +		    RL_FLAG_PHYWAKE | RL_FLAG_FASTETHER;
  		break;
  	case RL_HWREV_8102E:
  	case RL_HWREV_8102EL:
  		sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
 -		    RL_FLAG_PHYWAKE | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT;
 +		    RL_FLAG_PHYWAKE | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
 +		    RL_FLAG_FASTETHER;
  		break;
  	case RL_HWREV_8168_SPIN1:
  	case RL_HWREV_8168_SPIN2:
 @@ -2049,30 +2081,14 @@
  {
  	struct rl_softc		*sc;
  	struct mii_data		*mii;
 -	struct ifnet		*ifp;
  
  	sc = xsc;
 -	ifp = sc->rl_ifp;
  
  	RL_LOCK_ASSERT(sc);
  
 -	re_watchdog(sc);
 -
  	mii = device_get_softc(sc->rl_miibus);
  	mii_tick(mii);
 -	if ((sc->rl_flags & RL_FLAG_LINK) != 0) {
 -		if (!(mii->mii_media_status & IFM_ACTIVE))
 -			sc->rl_flags &= ~RL_FLAG_LINK;
 -	} else {
 -		if (mii->mii_media_status & IFM_ACTIVE &&
 -		    IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) {
 -			sc->rl_flags |= RL_FLAG_LINK;
 -			if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
 -				taskqueue_enqueue_fast(taskqueue_fast,
 -				    &sc->rl_txtask);
 -		}
 -	}
 -
 +	re_watchdog(sc);
  	callout_reset(&sc->rl_stat_callout, hz, re_tick, sc);
  }
  
 @@ -2189,11 +2205,6 @@
  		re_init_locked(sc);
  	}
  
 -	if (status & RL_ISR_LINKCHG) {
 -		callout_stop(&sc->rl_stat_callout);
 -		re_tick(sc);
 -	}
 -
  	if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
  		taskqueue_enqueue_fast(taskqueue_fast, &sc->rl_txtask);
  
 @@ -2698,14 +2709,15 @@
  {
  	struct rl_softc		*sc;
  	struct mii_data		*mii;
 +	int			error;
  
  	sc = ifp->if_softc;
  	mii = device_get_softc(sc->rl_miibus);
  	RL_LOCK(sc);
 -	mii_mediachg(mii);
 +	error = mii_mediachg(mii);
  	RL_UNLOCK(sc);
  
 -	return (0);
 +	return (error);
  }
  
  /*
 @@ -2856,18 +2868,30 @@
  re_watchdog(sc)
  	struct rl_softc		*sc;
  {
 +	struct ifnet		*ifp;
  
  	RL_LOCK_ASSERT(sc);
  
  	if (sc->rl_watchdog_timer == 0 || --sc->rl_watchdog_timer != 0)
  		return;
  
 -	device_printf(sc->rl_dev, "watchdog timeout\n");
 -	sc->rl_ifp->if_oerrors++;
 +	ifp = sc->rl_ifp;
 +	re_txeof(sc);
 +	if (sc->rl_ldata.rl_tx_free == sc->rl_ldata.rl_tx_desc_cnt) {
 +		if_printf(ifp, "watchdog timeout (missed Tx interrupts) "
 +		    "-- recovering\n");
 +		if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
 +			taskqueue_enqueue_fast(taskqueue_fast, &sc->rl_txtask);
 +		return;
 +	}
  
 -	re_txeof(sc);
 +	if_printf(ifp, "watchdog timeout\n");
 +	ifp->if_oerrors++;
 +
  	re_rxeof(sc);
  	re_init_locked(sc);
 +	if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
 +		taskqueue_enqueue_fast(taskqueue_fast, &sc->rl_txtask);
  }
  
  /*
 
 --IS0zKkzwUGydFO0o--

From: Marian Cerny <jojo@matfyz.cz>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/70832: [re] re0: watchdog timeout on Evo N1015v
Date: Sun, 08 Nov 2009 01:48:02 +0100

 Feel free to close this bug report. Both my Evo N1015v laptops have 
 already died so I don't have a way to check any more. The last time I 
 have checked it did not work. I have tried HEAD after you (Pyun) have 
 post the last patch and it didn't work.
 
 Regards,
 
 Marian
State-Changed-From-To: open->closed 
State-Changed-By: yongari 
State-Changed-When: Mon Oct 25 21:17:47 UTC 2010 
State-Changed-Why:  
Close. Submitter wanted to close the PR becasue the user has no 
more access to the hardware. It is possible the issue was not fixed  
yet but it would be better to close PR now for not being able to 
test. 
For another user who reported simiar issues on 8139C+, are you still 
seeing the issue on more recent FreeBSD release? If similar issue 
show up on more recent FreeBSD release please open a new PR. 
Thanks for reporting! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70832 
>Unformatted:
