From pm@zin.lublin.pl  Tue Aug 23 21:25:54 2005
Return-Path: <pm@zin.lublin.pl>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0F22016A41F
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 23 Aug 2005 21:25:54 +0000 (GMT)
	(envelope-from pm@zin.lublin.pl)
Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 393CE43D95
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 23 Aug 2005 21:25:40 +0000 (GMT)
	(envelope-from pm@zin.lublin.pl)
Received: by shellma.zin.lublin.pl (Postfix, from userid 1018)
	id A6E1A3474C2; Tue, 23 Aug 2005 23:24:00 +0200 (CEST)
Message-Id: <20050823212400.A6E1A3474C2@shellma.zin.lublin.pl>
Date: Tue, 23 Aug 2005 23:24:00 +0200 (CEST)
From: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
Reply-To: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: changing promisc mode on nic can lead to kernel panic
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         85258
>Category:       kern
>Synopsis:       [fxp] changing promisc mode on nic can lead to kernel panic
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 23 21:30:15 GMT 2005
>Closed-Date:    Sun Sep 19 23:31:28 UTC 2010
>Last-Modified:  Sun Sep 19 23:31:28 UTC 2010
>Originator:     Pawe Maachowski
>Release:        FreeBSD 5.3/5.4
>Organization:
osaczeni
>Environment:
FreeBSD 5.3 and 5.4-RELEASE, GENERIC kernel with DEVICE_POLLING, vlan, ipfw,
dummynet and ipl (IP Filter) loaded from modules (in sync with system).

>Description:
Router boxes have fxp NICs (usually renamed to wan0 and lan0, lan1 by
ifconfig rename), polling enabled, HZ set to 1000 and do a lot of NAT
(ipnat) and dummynet pipes processing.

Frequent changing of promisc flag on interface (for example, by using tcpdump
utility) will result in kernel panic (this was noticed by Krzysztof Cholewa).

This can be reproduced by executing ifconfig promisc and -promisc in endless
loop.

Backtrace is always the same. Please look at mtu value.

It also seems that turning polling off at least lowers the risk of panic.

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0646fab
stack pointer           = 0x10:0xc7aafb64
frame pointer           = 0x10:0xc7aafb88
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         = 28 (swi5: clock sio)
trap number             = 12
panic: page fault
Uptime: 2h56m54s

(kgdb) bt
#0  doadump () at pcpu.h:159
#1  0xc0614daa in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2  0xc0615040 in panic (fmt=0xc080b849 "%s")
    at /usr/src/sys/kern/kern_shutdown.c:566
#3  0xc07c3e14 in trap_fatal (frame=0xc7aafb24, eva=12)
    at /usr/src/sys/i386/i386/trap.c:817
#4  0xc07c3b7f in trap_pfault (frame=0xc7aafb24, usermode=0, eva=12)
    at /usr/src/sys/i386/i386/trap.c:735
#5  0xc07c37c1 in trap (frame=
      {tf_fs = -1051328488, tf_es = 16, tf_ds = -945160176, tf_edi = -1050883500, tf_esi = 16329, tf_ebp = -945095800, tf_isp = -945095856, tf_ebx = -1050883584, tf_edx = 0, tf_ecx = -1052078048, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1067159637, tf_cs = 8, tf_eflags = 66054, tf_esp = 0, tf_ss = -1065904684})
    at /usr/src/sys/i386/i386/trap.c:425
#6  0xc07b397a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7  0xc1560018 in ?? ()
#8  0x00000010 in ?? ()
#9  0xc7aa0010 in ?? ()
#10 0xc15cca54 in ?? ()
#11 0x00003fc9 in ?? ()
#12 0xc7aafb88 in ?? ()
#13 0xc7aafb50 in ?? ()
#14 0xc15cca00 in ?? ()
#15 0x00000000 in ?? ()
#16 0xc14a9020 in ?? ()
#17 0x00000000 in ?? ()
#18 0x0000000c in ?? ()
#19 0x00000000 in ?? ()
#20 0xc0646fab in m_copym (m=0x0, off0=16380, len=16360, wait=1)
    at /usr/src/sys/kern/uipc_mbuf.c:386
#21 0xc069e7a4 in ip_fragment (ip=0xc14a9020, m_frag=0xc7aafc40, mtu=-1050883584,
    if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967
#22 0xc069e450 in ip_output (m=0xc1bd7700, opt=0xc14a9020, ro=0xc7aafc0c, flags=0,
    imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:796
#23 0xc09f1ff5 in ?? ()
#24 0xc1bd7700 in ?? ()
#25 0x00000000 in ?? ()
#26 0xc7aafc0c in ?? ()
#27 0x00000000 in ?? ()
#28 0x00000000 in ?? ()
#29 0x00000000 in ?? ()
#30 0xc1bae000 in ?? ()
#31 0x00000033 in ?? ()
#32 0x00000000 in ?? ()
#33 0xc7aafca0 in ?? ()
#34 0xc09f231d in ?? ()
#35 0xc169ce00 in ?? ()
#36 0x0007d000 in ?? ()
#37 0x00000000 in ?? ()
#38 0x00000000 in ?? ()
#39 0x0007d000 in ?? ()
#40 0x00000000 in ?? ()
#41 0x00000001 in ?? ()
#42 0x00000000 in ?? ()
#43 0x00000001 in ?? ()
#44 0xc169ce00 in ?? ()
#45 0xc1bae000 in ?? ()
#46 0xc09f65c0 in ?? ()
#47 0x00000000 in ?? ()
#48 0xc7aafcc8 in ?? ()
#49 0xc09f2877 in ?? ()
#50 0xc1bae000 in ?? ()
#51 0xc09f65c0 in ?? ()
#52 0xc09f65e0 in ?? ()
#53 0xc09f65d0 in ?? ()
#54 0xb0c2eb80 in ?? ()
#55 0x00000006 in ?? ()
#56 0x00000000 in ?? ()
#57 0xc09f27a4 in ?? ()
#58 0xc7aafcf4 in ?? ()
#59 0xc0620bf6 in softclock (dummy=0xc169ce00)
    at /usr/src/sys/kern/kern_timeout.c:279
Previous frame inner to this frame (corrupt stack?)


>How-To-Repeat:
Execute the following shell script with proper interface as argument.
In my environment this will lead to panic within few minutes (up to
few hours). Sucessfully tested on three routers.


#!/bin/sh
while [ 1 ]
do
 date
 ifconfig $1 promisc
 sleep 5
 ifconfig $1 -promisc
 sleep 5
done


>Fix:
Unknown.

>Release-Note:
>Audit-Trail:

From: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
To: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/85258: changing promisc mode on nic can lead to kernel panic
Date: Wed, 24 Aug 2005 14:05:02 +0200

 On Tue, Aug 23, 2005 at 11:24:00PM +0200, Pawel Malachowski wrote:
 
 > It also seems that turning polling off at least lowers the risk of panic.
 
 FYI, when polling enable was set to 0, ifconfig promisc and -promisc in loop,
 system was running safely during all night (>18h).
 
 After enabling polling, it crashed within 5 minutes...
 With same backtrace.
 
 
 regards,
 -- 
 Pawe Maachowski

From: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
To: FreeBSD-gnats-submit@freebsd.org
Cc: freebsd-bugs@freebsd.org
Subject: Re: kern/85258: changing promisc mode on nic can lead to kernel panic
Date: Fri, 26 Aug 2005 20:30:24 +0200

 On Wed, Aug 24, 2005 at 12:10:20PM +0000, Pawel Malachowski wrote:
 
 >  FYI, when polling enable was set to 0, ifconfig promisc and -promisc in loop,
 >  system was running safely during all night (>18h).
 >  
 >  After enabling polling, it crashed within 5 minutes...
 >  With same backtrace.
 
 To sum up, factors are:
 . dummynet configured for outgoing packets seems to be needed;
 . frequent changes of fxp flags, one can use link0 (setting promisc
   is not needed at all);
 . kern.polling.enable=1.
 
 I've prepared static kernel for debugging, much better backtrace below. :)
 
 Test setup:
 ipfw pipe 100 config bw 512kbit/s queue 20KB mask src-ip 0xffffffff
 ipfw add 100 pipe 100 ip from any to any out xmit wan0
 
 (wan0 is renamed fxp0)
 
 while [ 1 ]
 do
  ifconfig $1 link0
  sleep 1
  ifconfig $1 -link0
  sleep 1
 done
 
 And ping -f from another box to speed things up. ;)
 
 Full reproducable for me within 10-20 minutes.
 
 (kgdb) bt
 #0  doadump () at pcpu.h:159
 #1  0xc060c948 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
 #2  0xc060cbc6 in panic (fmt=0xc081e7fd "m_copym, offset > size of mbuf chain") at /usr/src/sys/kern/kern_shutdown.c:566
 #3  0xc063e500 in m_copym (m=0x0, off0=16380, len=5124, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385
 #4  0xc0697780 in ip_fragment (ip=0xc13fa820, m_frag=0xc7aafc44, mtu=-1051870208, if_hwassist_flags=0, sw_csum=1)
     at /usr/src/sys/netinet/ip_output.c:974
 #5  0xc0697405 in ip_output (m=0xc13ef700, opt=0xc13fa820, ro=0xc7aafc10, flags=0, imo=0x0, inp=0x0)
     at /usr/src/sys/netinet/ip_output.c:798
 #6  0xc068b731 in transmit_event (pipe=0xc16e3d00) at /usr/src/sys/netinet/ip_dummynet.c:454
 #7  0xc068bab4 in ready_event (q=0xc172e280) at /usr/src/sys/netinet/ip_dummynet.c:624
 #8  0xc068c04b in dummynet (unused=0x0) at /usr/src/sys/netinet/ip_dummynet.c:779
 #9  0xc0617b12 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:279
 #10 0xc05fb4b8 in ithread_loop (arg=0xc12b9500) at /usr/src/sys/kern/kern_intr.c:547
 #11 0xc05fa92c in fork_exit (callout=0xc05fb394 <ithread_loop>, arg=0xc12b9500, frame=0xc7aafd48)
     at /usr/src/sys/kern/kern_fork.c:791
 #12 0xc07a0a4c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
 (kgdb) up 3
 #3  0xc063e500 in m_copym (m=0x0, off0=16380, len=5124, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385
 385                     KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain"));
 (kgdb) l
 380             KASSERT(len >= 0, ("m_copym, negative len %d", len));
 381             MBUF_CHECKSLEEP(wait);
 382             if (off == 0 && m->m_flags & M_PKTHDR)
 383                     copyhdr = 1;
 384             while (off > 0) {
 385                     KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain"));
 386                     if (off < m->m_len)
 387                             break;
 388                     off -= m->m_len;
 389                     m = m->m_next;
 (kgdb) up
 #4  0xc0697780 in ip_fragment (ip=0xc13fa820, m_frag=0xc7aafc44, mtu=-1051870208, if_hwassist_flags=0, sw_csum=1)
     at /usr/src/sys/netinet/ip_output.c:974
 974                     m->m_next = m_copy(m0, off, len);
 (kgdb) l
 969                             len = ip->ip_len - off;
 970                             m->m_flags |= M_LASTFRAG;
 971                     } else
 972                             mhip->ip_off |= IP_MF;
 973                     mhip->ip_len = htons((u_short)(len + mhlen));
 974                     m->m_next = m_copy(m0, off, len);
 975                     if (m->m_next == NULL) {        /* copy failed */
 976                             m_free(m);
 977                             error = ENOBUFS;        /* ??? */
 978                             ipstat.ips_odropped++;
 (kgdb) up
 #5  0xc0697405 in ip_output (m=0xc13ef700, opt=0xc13fa820, ro=0xc7aafc10, flags=0, imo=0x0, inp=0x0)
     at /usr/src/sys/netinet/ip_output.c:798
 798             error = ip_fragment(ip, &m, ifp->if_mtu, ifp->if_hwassist, sw_csum);
 (kgdb) l
 793              * Too large for interface; fragment if possible. If successful,
 794              * on return, m will point to a list of packets to be sent.
 795              */
 796     /*if (ifp->if_mtu) {
 797     }*/
 798             error = ip_fragment(ip, &m, ifp->if_mtu, ifp->if_hwassist, sw_csum);
 799             if (error)
 800                     goto bad;
 801             for (; m; m = m0) {
 802                     m0 = m->m_nextpkt;
 (kgdb) p *ifp
 $3 = {if_softc = 0xc1475000, if_link = {tqe_next = 0xc143b800, tqe_prev = 0xc1461004},
   if_xname = "lo0", '\0' <repeats 12 times>, if_dname = 0xc07f45e0 "lo", if_dunit = 0, if_addrhead = {
     tqh_first = 0xc14d0c00, tqh_last = 0xc1553260}, if_klist = {kl_lock = 0xc08db5a0, kl_list = {slh_first = 0x0}},
   if_pcount = 0, if_carp = 0x0, if_bpf = 0x0, if_index = 3, if_timer = 0, if_nvlans = 0, if_flags = 32841,
   if_capabilities = 0, if_capenable = 0, if_linkmib = 0x0, if_linkmiblen = 0, if_data = {ifi_type = 24 '\030',
     ifi_physical = 0 '\0', ifi_addrlen = 0 '\0', ifi_hdrlen = 0 '\0', ifi_link_state = 0 '\0', ifi_recvquota = 0 '\0',
     ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 16384, ifi_metric = 0, ifi_baudrate = 0, ifi_ipackets = 223,
     ifi_ierrors = 0, ifi_opackets = 223, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 38240, ifi_obytes = 38240,
     ifi_imcasts = 0, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 1, ifi_lastchange = {
       tv_sec = 1, tv_usec = 29757}}, if_multiaddrs = {tqh_first = 0xc151b3a0, tqh_last = 0xc151b0a0}, if_amcount = 0,
   if_output = 0xc0670efc <looutput>, if_input = 0, if_start = 0, if_ioctl = 0xc0671104 <loioctl>, if_watchdog = 0,
   if_init = 0, if_resolvemulti = 0, if_spare1 = 0x0, if_spare2 = 0x0, if_spare3 = 0x0, if_spare_flags1 = 0,
   if_spare_flags2 = 0, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 50, ifq_drops = 0, ifq_mtx = {
       mtx_object = {lo_class = 0xc0877e1c, lo_name = 0xc147500c "lo0", lo_type = 0xc082186a "if send queue",
         lo_flags = 196608, lo_list = {tqe_next = 0xc14d0c7c, tqe_prev = 0xc1475218}, lo_witness = 0xc08e1680}, mtx_lock = 4,
       mtx_recurse = 0}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 0, altq_type = 0,
     altq_flags = 0, altq_disc = 0x0, altq_ifp = 0xc1475000, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0,
     altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0x0, lltables = 0x0,
   if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc1475168}, if_afdata = {0x0 <repeats 28 times>, 0xc1470c00,
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_afdata_initialized = 1, if_afdata_mtx = {mtx_object = {
       lo_class = 0xc0877e1c, lo_name = 0xc082185a "if_afdata", lo_type = 0xc082185a "if_afdata", lo_flags = 196608,
       lo_list = {tqe_next = 0xc14750fc, tqe_prev = 0xc0880d20}, lo_witness = 0xc08e16a8}, mtx_lock = 4, mtx_recurse = 0},
   if_starttask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc066dc04 <if_start_deferred>,
     ta_context = 0xc1475000}}
 
 
 -- 
 Pawe Maachowski

From: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
To: FreeBSD-gnats-submit@freebsd.org
Cc: freebsd-bugs@freebsd.org
Subject: Re: kern/85258: changing promisc mode on nic can lead to kernel panic
Date: Mon, 29 Aug 2005 18:45:25 +0200

 On Fri, Aug 26, 2005 at 06:40:22PM +0000, Pawel Malachowski wrote:
 
 >  To sum up, factors are:
 >  . dummynet configured for outgoing packets seems to be needed;
 >  . frequent changes of fxp flags, one can use link0 (setting promisc
 >    is not needed at all);
 >  . kern.polling.enable=1.
 
 After todays testing I can say that:
 . switching from polled fxp(4) to polled rl(4) fixes the problem
 . ifconfig fxpX -polling fixes the problem
 . can't reproduce problem od 4.10, this is 5.x specific
 
 I would say fxp_ioctl() in case of SIOCSIFFLAGS is not safe on 5.x when
 fxp device works in polling mode and dummynet makes easier to expose the
 problem.
 
 HTH.
 
 -- 
 Pawe Maachowski
Responsible-Changed-From-To: freebsd-bugs->mux 
Responsible-Changed-By: pjd 
Responsible-Changed-When: Sun Sep 4 06:51:09 GMT 2005 
Responsible-Changed-Why:  
Maxime, can you take a look? 

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

From: Przemyslaw Frasunek <venglin@freebsd.lublin.pl>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/85258: [fxp] changing promisc mode on nic can lead to kernel
 panic
Date: Tue, 31 Jan 2006 11:02:16 +0100

 Hello,
 
 also experiencing this here.
 
 (kgdb) bt
 #0  0xc04fadbc in doadump ()
 #1  0xc04fb42e in boot ()
 #2  0xc04fb779 in panic ()
 #3  0xc06c266c in trap_fatal ()
 #4  0xc06c2342 in trap_pfault ()
 #5  0xc06c1eef in trap ()
 #6  0xc06afaca in calltrap ()
 #7  0x00000018 in ?? ()
 #8  0xc78a0010 in ?? ()
 #9  0xc04e0010 in fork1 ()
 #10 0xc05b0ac1 in ip_fragment ()
 #11 0xc05b06e9 in ip_output ()
 #12 0xc05a1b13 in transmit_event ()
 #13 0xc05a1eb8 in ready_event ()
 #14 0xc05a2532 in dummynet ()
 #15 0xc050a7f8 in softclock ()
 #16 0xc04e2428 in ithread_loop ()
 #17 0xc04e130f in fork_exit ()
 #18 0xc06afb2c in fork_trampoline ()
 
 Panic occurs almost every day, with dummynet and polling enabled, after the
 change from xl to fxp.
 
 ext-fw:root:/var/crash# uname -a
 FreeBSD ext-fw.czuby.net 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #0: Sun May 22
 15:59:54 CEST 2005     root@ext-fw.czuby.net:/usr/src/sys/i386/compile/EXTFW  i386
 ext-fw:root:/var/crash# dmesg
 Copyright (c) 1992-2005 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
 FreeBSD 5.4-RELEASE-p1 #0: Sun May 22 15:59:54 CEST 2005
     root@ext-fw.czuby.net:/usr/src/sys/i386/compile/EXTFW
 WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant
 WARNING: MPSAFE network stack disabled, expect reduced performance.
 Timecounter "i8254" frequency 1193182 Hz quality 0
 CPU: Intel Pentium III (647.19-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
 
 Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
 real memory  = 134217728 (128 MB)
 avail memory = 125890560 (120 MB)
 npx0: <math processor> on motherboard
 npx0: INT 16 interface
 cpu0 on motherboard
 pcib0: <Intel 82443BX (440 BX) host to PCI bridge> pcibus 0 on motherboard
 pir0: <PCI Interrupt Routing Table: 5 Entries> on motherboard
 pci0: <PCI bus> on pcib0
 agp0: <Intel 82443BX (440 BX) host to PCI bridge> mem 0x44000000-0x47ffffff at
 device 0.0 on pci0
 pcib1: <PCI-PCI bridge> at device 1.0 on pci0
 pci1: <PCI bus> on pcib1
 pci1: <display, VGA> at device 0.0 (no driver attached)
 fxp0: <Intel 82558 Pro/100 Ethernet> port 0x2000-0x201f mem
 0x40100000-0x401fffff,0x42000000-0x42000fff irq 11 at device 10.0 on pci0
 miibus0: <MII bus> on fxp0
 inphy0: <i82555 10/100 media interface> on miibus0
 inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 fxp0: Ethernet address: 00:50:8b:db:a0:02
 isab0: <PCI-ISA bridge> at device 20.0 on pci0
 isa0: <ISA bus> on isab0
 atapci0: <Intel PIIX4 UDMA33 controller> port
 0x2040-0x204f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 20.1 on pci0
 ata0: channel #0 on atapci0
 ata1: channel #1 on atapci0
 pci0: <serial bus, USB> at device 20.2 (no driver attached)
 intpm0: <Intel 82371AB Power management controller> port 0xfc00-0xfc0f irq 9 at
 device 20.3 on pci0
 intpm0: I/O mapped fc00
 intpm0: intr IRQ 9 enabled revision 0
 intsmb0: <Intel PIIX4 SMBUS Interface> on intpm0
 smbus1: <System Management Bus> on intsmb0
 smb0: <SMBus generic I/O> on smbus1
 intpm0: PM I/O mapped f800
 orm0: <ISA Option ROMs> at iomem 0xe0000-0xe7fff,0xc0000-0xc7fff on isa0
 pmtimer0 on isa0
 atkbdc0: <Keyboard controller (i8042)> at port 0x64,0x60 on isa0
 atkbd0: <AT Keyboard> irq 1 on atkbdc0
 kbd0 at atkbd0
 fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5 irq 6 drq 2 on isa0
 fd0: <1440-KB 3.5" drive> on fdc0 drive 0
 sc0: <System console> at flags 0x100 on isa0
 sc0: VGA <16 virtual consoles, flags=0x300>
 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
 sio0: type 16550A
 sio1 at port 0x2f8-0x2ff irq 3 on isa0
 sio1: type 16550A
 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
 unknown: <PNP0501> can't assign resources (port)
 unknown: <PNP0501> can't assign resources (port)
 unknown: <PNP0700> can't assign resources (port)
 unknown: <PNP0303> can't assign resources (port)
 unknown: <PNP0c02> can't assign resources (port)
 unknown: <PNP0c02> can't assign resources (port)
 Timecounter "TSC" frequency 647190171 Hz quality 800
 Timecounters tick every 1.000 msec
 IPsec: Initialized Security Association Processing.
 ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to
 accept, logging disabled
 ad0: 9732MB <SAMSUNG SV1021H/PJ100-21> [19774/16/63] at ata0-master UDMA33
 Mounting root from ufs:/dev/ad0s1a
 WARNING: / was not properly dismounted
 pflog0: promiscuous mode enabled
 tap0: Ethernet address: 00:bd:a7:16:01:00
 
 
 -- 
 * Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NICHDL: PMF9-RIPE *
 * JID: venglin@jabber.atman.pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ8JIV *

From: =?iso-8859-2?Q?Pawe=B3_Ma=B3achowski?= <pawmal@freebsd.lublin.pl>
To: Gleb Smirnoff <glebius@bestcom.ru>
Cc:  
Subject: Re: kern/85258
Date: Fri, 31 Mar 2006 22:35:50 +0200

 On Fri, Mar 03, 2006 at 05:36:06PM +0300, Gleb Smirnoff wrote:
 
 >   is it possible to reproduce this w/o dummynet? I have a small
 > hope that our latest fixes to dummynet locking, may affect your
 > problem.
 
 Unfortunetly, I no loger have access to FreeBSD machines to test
 this.
 
 
 -- 
 Pawe Maachowski
State-Changed-From-To: open->closed 
State-Changed-By: yongari 
State-Changed-When: Sun Sep 19 23:30:54 UTC 2010 
State-Changed-Why:  
Close. There had been a lot fixes in fxp(4) since 5.4-RELEASE so I 
believe the issue was already fixed. 
Given that submitter has no longer access to the hardware it's hard 
to reproduce this so close it now. If you happen to trigger it again 
on more recent FreeBSD releases, please open a new PR. 


Responsible-Changed-From-To: mux->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Sun Sep 19 23:30:54 UTC 2010 
Responsible-Changed-Why:  
Track. 

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