From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 13:58:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF45916A417 for ; Sun, 17 Feb 2008 13:58:48 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 2F67913C45A for ; Sun, 17 Feb 2008 13:58:42 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 17 Feb 2008 14:55:20 +0100 id 0002E010.47B83CC8.0000DC9E From: Milan Obuch To: freebsd-current@freebsd.org Date: Sun, 17 Feb 2008 14:58:26 +0100 User-Agent: KMail/1.9.7 References: <20080204022334.GC27999@cdnetworks.co.kr> <200802161949.02217.freebsd-current@dino.sk> <20080217112104.X80805@fledge.watson.org> In-Reply-To: <20080217112104.X80805@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802171458.26951.freebsd-current@dino.sk> Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 13:58:48 -0000 On Sunday 17 February 2008, Robert Watson wrote: > On Sat, 16 Feb 2008, Milan Obuch wrote: > >> I have tested 4-port Rhine III(6105LOM) and I never seen this hangs. > >> Does this also happen on other network interface too? When the system > >> hangs, would you break into DDB and show me the output of 'show > >> alllocks' and 'ps'? > > > > I need some tests with another box. I was not able to break into DDB. > > Ctrl-Alt-Esc worked until hang. Hang was really hard, Ctrl-Alt-Esc did > > not invoke DDB. I do not feel if_vr is culprit here, more probably PCI > > bus got somehow locked, but I have no idea how could I test it currently. > > FYI, there are known issues with the effectiveness of syscons ctrl-alt-esc > to get into the debugger -- if you haven't tried with a serial break on a > serial console, you might want to do so. This is because syscons's > interrupt handler acquires the Giant lock in an ithread, requiring a lot > more things to be happy to succeed. In constrast, sio (and friends) use > fast interrupt handlers and no Giant lock on the way to processing the > break request. It may well be that a serial break doesn't get into DDB for > you, but it's worth trying... > > Robert N M Watson > Computer Laboratory > University of Cambridge > You are right, after rebuilding kernel with BREAK_TO_DEBUGGER I am able to get requested data. BTW, I can't find just now what ALT_BREAK_TO_DEBUGGER means... After kldload if_vr, dhclient vr0 and ping -f in a minute system freezes. KDB: enter: Line break on console [thread pid 11 tid 100003 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> show alllocks db> ps pid ppid pgrp uid state wmesg wchan cmd 1231 936 1231 0 S+ nanslp 0xc07db764 ping 1230 1 1230 65 Ss select 0xc1d46868 dhclient 1174 1 1173 0 S+ select 0xc1d467e8 dhclient 936 924 936 0 S+ pause 0xc1cd130c csh 935 1 935 0 Ss+ ttyin 0xc18ca410 getty 934 1 934 0 Ss+ ttyin 0xc18ca810 getty 933 1 933 0 Ss+ ttyin 0xc18cac10 getty 932 1 932 0 Ss+ ttyin 0xc18cb010 getty 931 1 931 0 Ss+ ttyin 0xc18cb410 getty 930 1 930 0 Ss+ ttyin 0xc18cb810 getty 929 1 929 0 Ss+ ttyin 0xc18cbc10 getty 928 1 928 0 Ss+ ttyin 0xc18cc010 getty 927 1 927 0 Ss+ ttyin 0xc18cc410 getty 926 1 926 0 Ss+ ttyin 0xc18cc810 getty 925 1 925 0 Ss+ ttyin 0xc18ccc10 getty 924 1 924 0 Ss+ wait 0xc1bad804 login 882 1 882 0 Ss nanslp 0xc07db764 cron 876 1 876 25 Ss pause 0xc19b3864 sendmail 872 1 872 0 Ss select 0xc18c1828 sendmail 749 1 749 0 Ss select 0xc1900928 syslogd 703 1 703 0 Ss select 0xc18c1ea8 devd 369 1 369 65 Ss select 0xc19830a8 dhclient 349 1 30 0 S+ select 0xc18c17e8 dhclient 29 0 0 0 SL sdflush 0xc0835804 [softdepflush] 28 0 0 0 SL syncer 0xc07db58c [syncer] 27 0 0 0 SL vlruwt 0xc174eab0 [vnlru] 26 0 0 0 SL psleep 0xc082d1c4 [bufdaemon] 25 0 0 0 SL pgzero 0xc08363e0 [pagezero] 24 0 0 0 SL psleep 0xc0835ffc [vmdaemon] 23 0 0 0 SL psleep 0xc0835fc4 [pagedaemon] 22 0 0 0 SL - 0xc189e43c [fdc0] 21 0 0 0 SL - 0xc17c6000 [fw0_probe] 20 0 0 0 SL - 0xc17cdd00 [fw0_taskq] 19 0 0 0 SL usbevt 0xc1746210 [usb2] 18 0 0 0 SL usbevt 0xc1750210 [usb1] 17 0 0 0 SL usbtsk 0xc07d8ed4 [usbtask-dr] 16 0 0 0 SL usbtsk 0xc07d8ec0 [usbtask-hc] 15 0 0 0 SL usbevt 0xc1751210 [usb0] 14 0 0 0 SL ccb_scan 0xc07bee14 [xpt_thrd] 9 0 0 0 SL - 0xc1726780 [kqueue taskq] 8 0 0 0 SL - 0xc1726880 [acpi_task_2] 7 0 0 0 SL - 0xc1726880 [acpi_task_1] 6 0 0 0 SL - 0xc1726880 [acpi_task_0] 5 0 0 0 SL - 0xc1726b00 [thread taskq] 13 0 0 0 SL - 0xc07db594 [yarrow] 4 0 0 0 SL - 0xc07d95ec [g_down] 3 0 0 0 SL - 0xc07d95e8 [g_up] 2 0 0 0 SL - 0xc07d95e0 [g_event] 12 0 0 0 WL (threaded) intr 100077 I [irq16: re0 vr3] 100076 I [irq19: fwohci0 vr2] 100075 I [irq18: vr1] 100074 I [irq17: vr0] 100038 I [irq7: ppbus0 ppc0] 100037 I [irq12: psm0] 100036 I [irq1: atkbd0] 100035 I [swi0: sio] 100031 I [irq15: ata1] 100030 I [irq14: ata0] 100028 I [irq23: ehci0] 100026 I [irq22: ohci1+] 100022 I [irq21: ohci0] 100021 I [irq9: acpi0] 100020 I [swi5: +] 100019 I [swi2: cambio] 100013 I [swi6: task queue] 100012 I [swi6: Giant taskq] 100006 I [swi3: vm] 100005 I [swi4: clock sio] 100004 I [swi1: net] 11 0 0 0 RL CPU 0 [idle: cpu0] 1 0 1 0 SLs wait 0xc16baab0 [init] 10 0 0 0 SL audit_wo 0xc0835264 [audit] 0 0 0 0 WLs [swapper] db> After continue, I am able to break ping, but no more packet could be sent... 'sendto: no buffer space available' is all I get from ping now. Does this help in any way? Is there anything else I should test? Regards, Milan -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead.