mskc0: Tx descriptor error
Hey, I'm having problems getting my Marvell Yukon to work. I can successfully get it set up using DHCP, but when I start using it, I get error messages such as: "mskc0: Tx descriptor error" and "msk0: watchdog timeout". This is using the msk(4) module from 8.0-RELEASE. A bit of googling indicates that this problem is not uncommon, but had each time been resolved by patches that appear to have already been applied to the msk module that I'm using. Some help would be appreciated. Here is the ''dmesg'' output with bootverbose on and a ''vmstat -i'' should it matter. From dmesg: mskc0: port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 17 at device 0.0 on pci4 pcib4: mskc0 requested memory range 0xfebfc000-0xfebf: good mskc0: MSI count : 1 mskc0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 58 mskc0: using IRQ 256 for MSI mskc0: RAM buffer size : 0KB msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:1f:c6:83:a7:d0 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [MPSAFE] mskc0: [FILTER] pci5: driver added pci6: driver added msk0: link state changed to DOWN msk0: link state changed to UP mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error mskc0: Tx descriptor error msk0: watchdog timeout msk0: link state changed to DOWN msk0: link state changed to UP From vmstat -i: interrupt total rate irq14: ata0 246 0 irq17: fwohci0 2 0 irq20: ohci1 1 0 irq21: ehci19412 0 irq22: ohci05379 0 irq23: ehci0+ 11296 1 cpu0: timer 18926028 1999 irq256: mskc0377 0 Total 18952741 2002 ___ 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/141848: [vimage][panic] kernel with vimage panics on xen/domu/hvm guest
Synopsis: [vimage][panic] kernel with vimage panics on xen/domu/hvm guest State-Changed-From-To: open->closed State-Changed-By: bz State-Changed-When: Wed Dec 23 11:04:46 UTC 2009 State-Changed-Why: As discussed von freebsd-virtualization, pf is not yet supported with VIMAGE. What you get is expected. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Wed Dec 23 11:04:46 UTC 2009 Responsible-Changed-Why: Take in case of foolow-up. http://www.freebsd.org/cgi/query-pr.cgi?pr=141848 ___ 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"
Fw: KASSERT when connect to the peer(system is running out of memory) .
2009-12-23
fengdreamer
发件人： fengdreamer
发送时间： 2009-12-22 22:05:20
收件人： freebsd-net
抄送：
主题： KASSERT when connect to the peer(system is running out of memory) .
Hello ALL:
I am using the FreeBSD 7.1. My system is running out of memory, in this
sidution when i create the socket and connect, the the KASSERT come out. Here
is my description, please read the brief first and get the problem and then
contnue with the detail description.
How is this problem happen:
Brief description:
1. First, Connect side send SYN to the listerner
2. Second, Connect side will retransmit the SYN packet, but when it alloc mbuf
fail in the tcp_output. the tcp_sndnxt will not increase.
3. SYN ACK arrives, tcp_snduna increase, and will lager then tcp_sndnxt by 1.
sender side will response the ACK, invoke tcp_output: len is 1, but cc is zero.
KASSERT happen.
Detail description:
1.First, Connect side send SYN to the listerner, tcp->snd_nxt will just larger
than the tcp->snd_una by 1.
2. Second, Connect side will retransmit the SYN packet. The retransmit is
triger by the retransmit timer, it will then roll back the tcp->snd_nxt equal
to tcp->snd_una. and begin to call the tcp_output. If the tcp_output working
fun, the tcp->snd_nxt will then advanced by 1 before it calls the ip_output.
But if the mbuf alloc fail, the tcp->snd_nxt will stay equal to tcp->snd_una.
(on my system, memery is running out, so mbuf alloc may fail. ) please refer
the below code in the tcp_output:
MGETHDR(m, M_DONTWAIT, MT_DATA);
if (m == NULL) {
error = ENOBUFS;
goto out; // goto out, so the tcp->snd_nxt will not increased.
}
3. as above describtion, the tcp->snd_nxt is equal to tcp->snd_una. then the
SYN ACK packet arrives, and the connection is established, and the tcp->snd_una
will increase by 1. Also the connect side will then send the last ACK, it
invode the tcp_output, tcp output len is compute by the below expression:
off = tp->snd_nxt - tp->snd_una;
len = ((long)ulmin(so->so_snd.sb_cc, sendwin) - off);
ofcourse you have seen. the off is -1, the so_snd.sb_cc is 0, so the len is 1.
so below KASSERT will came:
KASSERT(sb->sb_mb != NULL, ("%s: sb_mb is NULL", __func__)); /* (sbsndptr ) */
Thanks
Regard
___
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"
