Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Aug 2004 20:22:20 GMT
From:      Marian Cerny <jojo@matfyz.cz>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   i386/70832: Serious problems with RealTek NIC using re0 driver on Evo N1015v
Message-ID:  <200408222022.i7MKMKoh076422@www.freebsd.org>
Resent-Message-ID: <200408222030.i7MKUPIh000619@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         70832
>Category:       i386
>Synopsis:       Serious problems with RealTek NIC using re0 driver on Evo N1015v
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 22 20:30:25 GMT 2004
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408222022.i7MKMKoh076422>