Kernel panic from interface address list manipulation

2010-08-17 Thread Nima Misaghian






 I’ve been able to trivially
trigger a kernel panic while testing ifaddr list manipulation on –CURRENT (r
211427).  The hardware is a four-core i386
machine with em interfaces.

 

This is the test script I’ve
used to trigger the problem:

 

#!/bin/sh



addr_loop()

{

while true

do

ifconfig em1 1.0.0.1/24

ifconfig em1 -alias 1.0.0.1

done

}



addr_loop &

addr_loop &

 


With WITNESS and INVARIANTS the
panic happens immediately upon starting the script, with the following
backtrace:

 

panic: Bad link elm 0xd17aec00
prev->next != elm

 

#0  doadump () at pcpu.h:231

231 pcpu.h: No such file or directory.

in pcpu.h

(kgdb) #0  doadump () at pcpu.h:231

#1  0xc088a4ef in boot (howto=260) at
/d2/head/sys/kern/kern_shutdown.c:416

#2  0xc088a7bb in panic (fmt=Variable
"fmt" is not available.

) at /d2/head/sys/kern/kern_shutdown.c:590

#3  0xc098caf8 in in_control (so=0xd30af4d4,
cmd=2151704858,

data=0xd1923b80 "em1",
ifp=0xd1554800, td=0xd31262c0)

at /d2/head/sys/netinet/in.c:602

#4  0xc0938869 in ifioctl (so=0xd30af4d4,
cmd=2151704858,

data=0xd1923b80 "em1",
td=0xd31262c0) at /d2/head/sys/net/if.c:2469

#5  0xc08d7e6b in soo_ioctl (fp=0xd2540ce8,
cmd=2151704858, data=0xd1923b80,

active_cred=0xd2594900, td=0xd31262c0)

at /d2/head/sys/kern/sys_socket.c:212

#6  0xc08d2075 in kern_ioctl (td=0xd31262c0,
fd=3, com=2151704858,

data=0xd1923b80 "em1") at
file.h:254

#7  0xc08d21e2 in ioctl (td=0xd31262c0,
uap=0xf3a2ecec)

at /d2/head/sys/kern/sys_generic.c:678

#8  0xc08c77d8 in syscallenter (td=0xd31262c0,
sa=0xf3a2ece4)

at /d2/head/sys/kern/subr_trap.c:319

#9  0xc0bb18f3 in syscall (frame=0xf3a2ed28)

at /d2/head/sys/i386/i386/trap.c:1060

#10 0xc0b9a231 in
Xint0x80_syscall ()

at /d2/head/sys/i386/i386/exception.s:264

#11 0x0033 in ?? ()

Previous frame inner to this
frame (corrupt stack?)

(kgdb)

 

I’ve also reproduced it without
WITNESS and INVARIANTS, but it seems to need additional copies of the script
running simultaneously and still takes longer to panic.  I’ve produced
several different backtraces from the non-debugging kernel.

 




  
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: kern/147245: [dummynet] dummynet skip traffic over configured limit with net.inet.ip.dummynet.io_fast:1

2010-08-17 Thread oleg
Synopsis: [dummynet] dummynet skip traffic over configured limit with 
net.inet.ip.dummynet.io_fast:1

Responsible-Changed-From-To: freebsd-net->oleg
Responsible-Changed-By: oleg
Responsible-Changed-When: Tue Aug 17 17:05:24 UTC 2010
Responsible-Changed-Why: 
i'll look at it.


http://www.freebsd.org/cgi/query-pr.cgi?pr=147245
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: kern/147824: [msk]: watchdog timeouts

2010-08-17 Thread Ihsan Junaidi Ibrahim
The following reply was made to PR kern/147824; it has been noted by GNATS.

From: Ihsan Junaidi Ibrahim 
To: bug-follo...@freebsd.org, d...@edarb.com
Cc:  
Subject: Re: kern/147824: [msk]: watchdog timeouts
Date: Wed, 18 Aug 2010 02:29:09 +0800

 --0015174c0fe2fb030f048e091f88
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi,
 
 I'm also having this issue on the same model of motherboard except that I'm
 running on a 100mbps network. I would get watchdog timeouts and TX
 descriptor errors more frequently then not even there is minimal network
 activity i.e. just SSH in the box. I'm running 8.1-RELEASE.
 
 mskc0:  port 0xe800-0xe8ff mem
 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2
 msk0:  on
 mskc0
 msk0: Ethernet address: 00:ea:01:15:c6:52
 miibus0:  on msk0
 mskc0: [ITHREAD]
 msk0: link state changed to UP
 msk0: watchdog timeout
 msk0: link state changed to DOWN
 msk0: link state changed to UP
 
 Having TSO and MSI disabled in sysctl and loader respectively does not
 appear to have any improvement.
 
 Additionally the kernel would panic when booting, this happens 1 in every 2
 tries:
 
 Aug 18 01:35:26  kernel: mskc0: 
 port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2
 Aug 18 01:35:26  kernel: msk0:  on mskc0
 Aug 18 01:35:26  kernel: msk0: Ethernet address: ff:ff:ff:ff:ff:ff
 Aug 18 01:35:26  kernel: msk0: No PHY found!
 ...
 Panic message ensues
 
 This happens regardless whether the cable is plugged or not.
 
 Normal booting would be like this:
 
 Aug 18 01:35:26  kernel: mskc0: 
 port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2
 Aug 18 01:35:26  kernel: msk0:  on mskc0
 Aug 18 01:35:26  kernel: msk0: Ethernet address: 00:ea:01:15:c6:52
 Aug 18 01:35:26  kernel: miibus0:  on msk0
 Aug 18 01:35:26  kernel: e1000phy0:  PHY 0 on
 miibus0
 Aug 18 01:35:26  kernel: e1000phy0:  10baseT, 10baseT-FDX, 100baseTX,
 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
 Aug 18 01:35:26  kernel: mskc0: [ITHREAD]
 
 # ifconfig msk0
 msk0: flags=8843 metric 0 mtu 1500
 
  options=c011a
 ether 00:ea:01:15:c6:52
 inet 192.168.2.10 netmask 0xff00 broadcast 192.168.2.255
 media: Ethernet autoselect (100baseTX )
 status: active
 
 -- 
 Thank you for your time,
 Ihsan Junaidi Ibrahim
 
 --0015174c0fe2fb030f048e091f88
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Hi,I'm also having this issue on the same model of =
 motherboard except that I'm running on a 100mbps network. I would get w=
 atchdog timeouts and TX descriptor errors more frequently then not even the=
 re is minimal network activity i.e. just SSH in the box. I'm running 8.=
 1-RELEASE.
 mskc0:  p=
 ort 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2msk0:  on mskc0
 msk0: Ethernet address: 00:ea:01:15:c6:52miibus0:  on msk0mskc0: [ITHREAD]msk0: link state change=
 d to UPmsk0: watchdog timeoutmsk0: link state changed=
  to DOWN
 msk0: link state changed to UPHaving TSO and=
  MSI disabled in sysctl and loader respectively does not appear to have any=
  improvement.Additionally the kernel would panic =
 when booting, this happens 1 in every 2 tries:
 Aug 18 01:35:26 =A0kernel: mskc0:  port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq =
 18 at device 0.0 on pci2Aug 18 01:35:26 =A0kernel: msk0:  on mskc0
 Aug 18 01:35:26 =A0kernel: msk0: Ethernet address: ff:ff:ff:ff:ff:ffAug 18 01:35:26 =A0kernel: msk0: No PHY found!...=
 Panic message ensuesThis happens regardless =
 whether the cable is plugged or not.
 Normal booting would be like this:=
 Aug 18 01:35:26 =A0kernel: mskc0:  port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at devi=
 ce 0.0 on pci2
 Aug 18 01:35:26 =A0kernel: msk0:  on mskc0Aug 18 01:35:26 =A0kern=
 el: msk0: Ethernet address: 00:ea:01:15:c6:52Aug 18 01:35:26 =A0=
 kernel: miibus0:  on msk0
 Aug 18 01:35:26 =A0kernel: e1000phy0:  metric 0 mtu 1500=A0=A0 =A0 =A0 =A0opt=
 ions=3Dc011a=
 ;
 =A0=A0 =A0 =A0 =A0ether 00:ea:01:15:c6:52=A0=A0 =A0 =A0 =A0=
 inet 192.168.2.10 netmask 0xff00 broadcast 192.168.2.255=A0=
 =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX )=A0=A0 =A0 =A0 =A0status: active
 -- Thank you for your time,Ihsan Junaidi Ibrah=
 im
 
 
 --0015174c0fe2fb

Re: kern/147824: [msk]: watchdog timeouts

2010-08-17 Thread Ihsan Junaidi Ibrahim
The following reply was made to PR kern/147824; it has been noted by GNATS.

From: Ihsan Junaidi Ibrahim 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/147824: [msk]: watchdog timeouts
Date: Wed, 18 Aug 2010 06:14:13 +0800

 Hi,
 
 I believe PR 116853 is related to this.
 
 --
 Thank you for your time,
 Ihsan Junaidi Ibrahim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: kern/147824: [msk]: watchdog timeouts

2010-08-17 Thread Brad Degnan
The following reply was made to PR kern/147824; it has been noted by GNATS.

From: Brad Degnan 
To: Ihsan Junaidi Ibrahim 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/147824: [msk]: watchdog timeouts
Date: Tue, 17 Aug 2010 16:57:03 -0700

 On 8/17/2010 11:29 AM, Ihsan Junaidi Ibrahim wrote:
 > Hi,
 >
 > I'm also having this issue on the same model of motherboard except that
 > I'm running on a 100mbps network. I would get watchdog timeouts and TX
 > descriptor errors more frequently then not even there is minimal network
 > activity i.e. just SSH in the box. I'm running 8.1-RELEASE.
 >
 > mskc0:  port 0xe800-0xe8ff mem
 > 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2
 > msk0:  on
 > mskc0
 > msk0: Ethernet address: 00:ea:01:15:c6:52
 > miibus0:  on msk0
 > mskc0: [ITHREAD]
 > msk0: link state changed to UP
 > msk0: watchdog timeout
 > msk0: link state changed to DOWN
 > msk0: link state changed to UP
 >
 > Having TSO and MSI disabled in sysctl and loader respectively does not
 > appear to have any improvement.
 >
 
 I had to change the network interface to 100mbps half-duplex before the 
 watchdog timeouts disappeared.  It's definitely not optimal but works 
 for me in the mean time.  Full-duplex at 1000 and 100 and half-duplex at 
 1000 give me the watchdog timeouts and tx descriptor errors.  Hope that 
 helps
 
 > Additionally the kernel would panic when booting, this happens 1 in
 > every 2 tries:
 >
 > Aug 18 01:35:26  kernel: mskc0: 
 > port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2
 > Aug 18 01:35:26  kernel: msk0:  Ultra Id 0xb4 Rev 0x05> on mskc0
 > Aug 18 01:35:26  kernel: msk0: Ethernet address: ff:ff:ff:ff:ff:ff
 > Aug 18 01:35:26  kernel: msk0: No PHY found!
 > ...
 > Panic message ensues
 >
 > This happens regardless whether the cable is plugged or not.
 
 I haven't seen this yet, but I'm still on 8.1-PRERELEASE.  I have no 
 idea if downgrading would help.  Do you have the latest bios?
 
 best,
 Brad
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: startup network configuration choice

2010-08-17 Thread jhell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/15/2010 08:42, Julian H. Stacey wrote:
> Personally I have this in /etc/rc.conf, 
>   host="mylap" ; domain="company.com"
>   host="mylap" ; domain="no.net"
>   host="mylap" ; domain="home.net"
>   hostname="$host.$domain"
>   case $hostname in   #{
>   "mylap.home.net")  #{
>   ifconfig_fxp0="inet 192.168.10.11"
>   # whatever other things too
>   ;;
>   "mylap.company.com") 
>   ifconfig_fxp0="inet 10..
>   ;;
>   ifco
>   "mylap.no.net") 
>   ;;
>esac


This is not a bad configuration but lacks the ability to be booted into
the right environment via a single keystroke or boot into its default.

I was playing around with this idea a while back but do not really have
a need for such a thing at this time as DHCP in most cases that I need
it surfices for a client machine, and servers don't normally move unless
the daemons carry them away. PS: do not let the daemons drink 'Red Bull'.

The files that I was modifying to do just this was /etc/network.subr,
/boot/beastie.4th and ultimately /etc/rc.conf.

/etc/network.subr:
* This needed the ability to parse kenv(1) for a variable I will call
``network_profile''

network_profile:
* Initialized to an integer 0, 1, 2, 3. left unset defaulting to 0.

/boot/beastie.4th:
* Should be modified to contain entries that allow you to set the
network_profile to the values stated above and then boot normally.

/etc/rc.conf:
* Would contain something similiar to what you have above but to just
look at the value of network_profile and throw your ifconfig and
whatever lines in its respective case statements.


You might be able to set a kenv(1) variable through grub or other
utilities from ports but still some modification would be needed to the
beastie boot menu to allow you to change them dynamically.


Another thought that had come to mind while doing the above was to
create a script in /etc/rc.d that when run with keyword BEFORE NETWORK
would wait for the user to press 1, 2, 3, 4 if network_profiles="YES"
and then source its respective variables from /etc/netprofile.1 .2 .3 .4
and continue on its way through the rest of the configuration after a
predetermined hard coded timeout.

There is a ton of ways that you can go about doing this but the final
approach is up to you as one does not exist in the base system at this time.



Good luck & Regards,

jhell,v

- -- 

 jhell,v
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMazoiAAoJEJBXh4mJ2FR+fK8IAKAO6NmMTrwmqse9mfCNw53o
NU84VScWVbat97HwSP+7nfPuS9NV/VNI0jjasvNmW4nxXAUF10+Vc/ej683Juwrg
Ds7t6ZaZaGxfYRHB8DFaLHnM38kwQDY+aZB2hU94/jX+OgV6KQainOQ+xjzEUxjj
9CCNHvsUP2XCKAyNhcUq9pMb8bB9QKsd10qAeaWRK2N+RPhXi4Z8IREmIB/i1A4/
nOIcuNmLwJ6qmjzIZBWEN7/WpE9AQy5IB9yu+Qqo10MyVqJWkZRqww9THOaiEv3L
qRFTdQlkpQom0txV+6nA6c75rhd0P1aSlKC0X9U82aue8rQy+RfYESGHLgAoGNQ=
=DFae
-END PGP SIGNATURE-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: kern/147824: [msk]: watchdog timeouts & Tx descriptor error

2010-08-17 Thread andre
Synopsis: [msk]: watchdog timeouts &  Tx descriptor error

Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: andre
Responsible-Changed-When: Wed Aug 18 06:28:13 UTC 2010
Responsible-Changed-Why: 
Over to yongari.

http://www.freebsd.org/cgi/query-pr.cgi?pr=147824
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"