freebsd-stable Digest, Vol 351, Issue 7
freebsd-sta...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-sta...@freebsd.org
You can reach the person managing the list at
freebsd-st...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: FreeBSD 7.3/i386 libalias related panic (Artem Kim)
2. Re: em driver regression (Brandon Gooch)
3. Re: em driver regression (Jack Vogel)
4. Re: em driver regression (Brandon Gooch)
5. Re: em driver regression (Jack Vogel)
6. Re: random FreeBSD panics (Anoop Kumar Narayanan)
7. Re: em driver regression (Brandon Gooch)
8. Re: em driver regression (Jack Vogel)
9. Re: em driver regression (Mike Tancsa)
10. Re: random FreeBSD panics (Masoom Shaikh)
11. Re: em driver regression (Pyun YongHyeon)
12. Re: em driver regression (Jack Vogel)
13. Re: em driver regression (Jack Vogel)
14. Re: em driver regression (Jack Vogel)
15. Re: em driver regression (Jack Vogel)
16. Re: em driver regression (Mike Tancsa)
17. Re: em driver regression (Jack Vogel)
18. Re: em driver regression (Pyun YongHyeon)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Apr 2010 20:32:44 +0400
From: Artem Kim <arte...@inbox.ru>
Subject: Re: FreeBSD 7.3/i386 libalias related panic
To: freebsd...@freebsd.org
Cc: Peter Jeremy <peter...@acm.org>
Message-ID: <201004082032.4...@inbox.ru>
Content-Type: Text/Plain; charset="iso-8859-15"
On Tuesday 06 April 2010 23:24:52 Peter Jeremy wrote:
> On 2010-Apr-06 00:37:51 +0400, Artem Kim <arte...@inbox.ru> wrote:
> >Fatal trap 12: page fault while in kernel mode
> >cpuid = 1; apic id = 01
> >fault virtual address = 0x7d4c
>
> This suggests an offset from a NULL pointer.
>
> >0x8069ac41 is in DeleteLink
> > (/usr/src/sys/netinet/libalias/alias_db.c:857). 852 {
> >853 struct libalias *la = lnk->la;
> >854
> >855 LIBALIAS_LOCK_ASSERT(la);
> >856 /* Don't do anything if the link is marked permanent */
> >857 if (la->deleteAllLinks == 0 && lnk->flags &
> > LINK_PERMANENT) 858 return;
> >
> >(kgdb) bt
> >#7 0x8069ac41 in DeleteLink (lnk=0x84e0f980) at
> > /usr/src/sys/netinet/libalias/alias_db.c:853 #8 0x8069ae3e in
> > HouseKeeping (la=0x84874000) at
> > /usr/src/sys/netinet/libalias/alias_db.c:843
>
> In the absence of someone who's seen this before, my initial guess is
> that lnk->la is corrupted in frame #7. I'd start with 'print *lnk' at
> frame #7 to confirm this. If so, you could go up to frame #8 and work
> through the linkTableOut chain to find which entry is corrupt - but
> actually finding _why_ it's corrupt will take a lot more work.
>
> If this is repeatable, I'd suggest adding WITNESS, WITNESS_SKIPSPIN
> and INVARIANTS and see if you can get the problem to show up closer
> to its cause.
>
I have three almost nearly identical machines (two HP DL-140G3 and a HP
DL-160G5). These machines have approximately the same setting.
Problem occurred only on one (140G3).
Two errors occurred in intervals of one hour. Last error happened three days
ago. Until now, the problem is not repeated.
Introducing additional options to debug the kernel - it is very difficult to
machine is under heavy load. On a test desk, I can not reproduce the problem.
(kgdb) f 7
#7 0x8069ac41 in DeleteLink (lnk=0x84e0f980) at
/usr/src/sys/netinet/libalias/alias_db.c:853
853 struct libalias *la = lnk->la;
(kgdb) print *lnk
$1 = {la = 0x0, src_addr = {s_addr = 1}, dst_addr = {s_addr = 0}, alias_addr =
{s_addr = 0}, proxy_addr = {s_addr = 0}, src_port = 0, dst_port = 0,
alias_port = 0, proxy_port = 0, server = 0x0, link_type = 0, flags = 0,
pflags = 0, timestamp = 0, expire_time = 0, list_out = {le_next = 0x0,
le_prev = 0x853dcdb4}, list_in = {le_next = 0x0, le_prev = 0x84861c48},
data = {frag_ptr = 0x0, frag_addr = {s_addr = 0}, tcp = 0x0}}
I'm sorry I do not understand what I should do next.
------------------------------
Message: 2
Date: Thu, 8 Apr 2010 11:32:54 -0500
From: Brandon Gooch <jamesbra...@gmail.com>
Subject: Re: em driver regression
To: Jack Vogel <jfv...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID:
<m2g179b97fb1004080932u8...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 11:04 AM, Jack Vogel <jfv...@gmail.com> wrote:
> Brandon,
>
> Did the checkin of yesterday afternoon resolve the problem of the win7
> systems in
> VirtualBox? I will continue to look at this today.
>
> Jack
>
Sorry, I was a little unclear on that :(
No, the issue wasn't resolved even after the most recent commits.
I will be available for testing all day (and this evening if
required), let me know what you'd like from me, and I'll help any way
I can.
-Brandon
>
> On Thu, Apr 8, 2010 at 8:29 AM, Brandon Gooch <jamesbra...@gmail.com>
> wrote:
>>
>> On Thu, Apr 8, 2010 at 9:46 AM, Mike Tancsa <mi...@sentex.net> wrote:
>> >
>> > OK, some more data... It seems dhclient is getting upset as well since
>> > the
>> > updated driver
>> >
>> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
>> > 255.255.255.255
>> > port 67 interval 6
>> > Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with bytes
>> > received 332.
>> > Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data after
>> > udp
>> > payload.
>> > Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
>> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
>> > 255.255.255.255
>> > port 67
>> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with bytes
>> > received 332.
>> > Apr 8 10:28:40 ich10 dhclient[1383]: accepting packet with data after
>> > udp
>> > payload.
>> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPACK from 192.168.xx.1
>> >
>> > I also tried manually applying the patch below
>> >
>> >
>> > <http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016189.html>http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016189.html
>> >
>> > but still get the same error on dhclient
>> >
>> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with bytes
>> > received 332.
>> >
>> > which was not there before the 7.0.0 driver update
>> >
>> > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>> > 1500
>> >
>> >
>> > options=399b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
>> > ether 00:1c:c0:95:0d:0d
>> > inet 192.168.43.219 netmask 0xffffff00 broadcast 192.168.43.255
>> > media: Ethernet autoselect (100baseTX <full-duplex>)
>> > status: active
>> >
>> > Also, should not
>> >
>> > # ifconfig em0 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso
>> > 0(ich10)# ifconfig em0
>> > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>> > 1500
>> >
>> >
>> > options=388b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
>> > ether 00:1c:c0:95:0d:0d
>> > inet 192.168.43.219 netmask 0xffffff00 broadcast 192.168.43.255
>> > media: Ethernet autoselect (100baseTX <full-duplex>)
>> > status: active
>> > 0(ich10)# killall dhclient
>> > 0(ich10)# dhclient em0
>> > DHCPREQUEST on em0 to 255.255.255.255 port 67
>> > ip length 328 disagrees with bytes received 332.
>> > accepting packet with data after udp payload.
>> > DHCPACK from 192.168.xx.1
>> > bound to 192.168.xx.219 -- renewal in 22777 seconds.
>> > 0(ich10)#
>> >
>> > disable all the vlan features on the nic ?
>> >
>> > ---Mike
>> >
>> >
>> > --------------------------------------------------------------------
>> > Mike Tancsa, tel +1 519 651 3400
>> > Sentex Communications, mi...@sentex.net
>> > Providing Internet since 1994 www.sentex.net
>> > Cambridge, Ontario Canada www.sentex.net/mike
>> >
>> > _______________________________________________
>> > freebsd...@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> > To unsubscribe, send any mail to
>> > "freebsd-stabl...@freebsd.org"
>> >
>>
>> I'm also seeing this.
>>
>> Jack, I've built the most recent revision from CURRENT and installed
>> it on the 8-STABLE machine. This is the computer I e-mailed about
>> yesterday (20100407) with which I've been having trouble with
>> VirtualBox 3.1.6 (FreeBSD Host) Windows Guests, bridged networking,
>> etc...
>>
>> Same situation with VirtualBox and still:
>>
>> ip length 328 disagrees with bytes received 332
>>
>> -Brandon
>
>
------------------------------
Message: 3
Date: Thu, 8 Apr 2010 09:52:33 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: Mike Tancsa <mi...@sentex.net>
Cc: freebsd...@freebsd.org
Message-ID:
<l2n2a41acea1004080952u9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Mike, I noticed this connection is only 100Mb, that isn't accidental? And,
is it possible for
you to check a connection at 1Gb and see if the watchdogs don't happen.
My test engineer is running this code, and we are having trouble repro'ing
the issue, so any
clues might help. Is the kernel 64 or 32 bit?
Jack
On Thu, Apr 8, 2010 at 6:20 AM, Mike Tancsa <mi...@sentex.net> wrote:
> At 09:12 AM 4/8/2010, Mike Tancsa wrote:
>
>> Hi Jack,
>> I looks like the latest MFC to RELENG_8 for the em driver has
>> caused a regression. The box is not doing much as its a development server
>> in the lab. This is an Intel MB (DX58SO). dmesg and pciconf -lvc attached.
>>
>
>
>
> Here are the stats from the NIC as well.
>
> em0: Excessive collisions = 0
> em0: Sequence errors = 0
> em0: Defer count = 0
> em0: Missed Packets = 0
> em0: Receive No Buffers = 0
> em0: Receive Length Errors = 0
> em0: Receive errors = 0
> em0: Crc errors = 0
> em0: Alignment errors = 0
> em0: Collision/Carrier extension errors = 0
> em0: watchdog timeouts = 16
> em0: XON Rcvd = 0
> em0: XON Xmtd = 0
> em0: XOFF Rcvd = 0
> em0: XOFF Xmtd = 0
> em0: Good Packets Rcvd = 65839
> em0: Good Packets Xmtd = 13100
> em0: TSO Contexts Xmtd = 203
> em0: TSO Contexts Failed = 0
>
> It just grabs the IP via DHCP
>
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>
> options=399b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
> ether 00:1c:c0:95:0d:0d
> inet 192.168.xx.yy netmask 0xffffff00 broadcast 192.168.xx.zz
> media: Ethernet autoselect (100baseTX <full-duplex>)
> status: active
>
>
>
>
> --------------------------------------------------------------------
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, mi...@sentex.net
> Providing Internet since 1994 www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
>
------------------------------
Message: 4
Date: Thu, 8 Apr 2010 12:01:45 -0500
From: Brandon Gooch <jamesbra...@gmail.com>
Subject: Re: em driver regression
To: Jack Vogel <jfv...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID:
<o2y179b97fb1004081001qb...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel <jfv...@gmail.com> wrote:
> Mike, I noticed this connection is only 100Mb, that isn't accidental? And,
> is it possible for
> you to check a connection at 1Gb and see if the watchdogs don't happen.
>
> My test engineer is running this code, and we are having trouble repro'ing
> the issue, so any
> clues might help. Is the kernel 64 or 32 bit?
>
> Jack
>
Not to butt in or anything...
64-bit FreeBSD Stable, 1Gb em(4) connected to Cisco 2960G trunking port.
My dmesg:
Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-STABLE #2 r206210:206343MS: Wed Apr 7 16:18:14 CDT 2010
ro...@bgooch755.se.edu:/usr/obj/usr/src/sys/DELL755 amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.00-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
AMD Features=0x20100800<SYSCALL,NX,LM>
AMD Features2=0x1<LAHF>
TSC: P-state invariant
real memory = 8589934592 (8192 MB)
avail memory = 8103940096 (7728 MB)
ACPI APIC Table: <DELL B9K >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
cpu2 (AP): APIC ID: 2
cpu3 (AP): APIC ID: 3
ioapic0: Changing APIC ID to 8
ioapic0 <Version 2.0> irqs 0-23 on motherboard
lapic0: Forcing LINT1 to edge trigger
kbd1 at kbdmux0
acpi0: <DELL B9K > on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xdc80-0xdcff mem
0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq
16 at device 0.0 on pci1
nvidia0: <GeForce 8400 GS> on vgapci0
vgapci0: child nvidia0 requested pci_enable_busmaster
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia0: [ITHREAD]
pci0: <simple comms> at device 3.0 (no driver attached)
atapci0: <Intel ATA controller> port
0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff
irq 18 at device 3.2 on pci0
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
pci0: <simple comms, UART> at device 3.3 (no driver attached)
em0: <Intel(R) PRO/1000 Network Connection 7.0.1> port 0xecc0-0xecdf
mem 0xfebe0000-0xfebfffff,0xfebdb000-0xfebdbfff irq 21 at device 25.0
on pci0
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:1e:4f:d5:84:b7
uhci0: <Intel 82801I (ICH9) USB controller> port 0xff20-0xff3f irq 16
at device 26.0 on pci0
uhci0: [ITHREAD]
uhci0: LegSup = 0x2f00
usbus0: <Intel 82801I (ICH9) USB controller> on uhci0
uhci1: <Intel 82801I (ICH9) USB controller> port 0xff00-0xff1f irq 17
at device 26.1 on pci0
uhci1: [ITHREAD]
uhci1: LegSup = 0x2f00
usbus1: <Intel 82801I (ICH9) USB controller> on uhci1
ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem
0xfebd9c00-0xfebd9fff irq 22 at device 26.7 on pci0
ehci0: [ITHREAD]
usbus2: EHCI version 1.0
usbus2: <Intel 82801I (ICH9) USB 2.0 controller> on ehci0
hdac0: <Intel 82801I High Definition Audio Controller> mem
0xfebdc000-0xfebdffff irq 16 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
uhci2: <Intel 82801I (ICH9) USB controller> port 0xff80-0xff9f irq 23
at device 29.0 on pci0
uhci2: [ITHREAD]
usbus3: <Intel 82801I (ICH9) USB controller> on uhci2
uhci3: <Intel 82801I (ICH9) USB controller> port 0xff60-0xff7f irq 17
at device 29.1 on pci0
uhci3: [ITHREAD]
usbus4: <Intel 82801I (ICH9) USB controller> on uhci3
uhci4: <Intel 82801I (ICH9) USB controller> port 0xff40-0xff5f irq 18
at device 29.2 on pci0
uhci4: [ITHREAD]
usbus5: <Intel 82801I (ICH9) USB controller> on uhci4
ehci1: <Intel 82801I (ICH9) USB 2.0 controller> mem
0xff980800-0xff980bff irq 23 at device 29.7 on pci0
ehci1: [ITHREAD]
usbus6: EHCI version 1.0
usbus6: <Intel 82801I (ICH9) USB 2.0 controller> on ehci1
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci3: <ACPI PCI bus> on pcib3
atapci1: <SiI 3114 SATA150 controller> port
0xc8e0-0xc8e7,0xc8d8-0xc8db,0xc8e8-0xc8ef,0xc8dc-0xc8df,0xc8f0-0xc8ff
mem 0xf9dffc00-0xf9dfffff irq 16 at device 0.0 on pci3
atapci1: [ITHREAD]
ata4: <ATA channel 0> on atapci1
ata4: [ITHREAD]
ata5: <ATA channel 1> on atapci1
ata5: [ITHREAD]
ata6: <ATA channel 2> on atapci1
ata6: [ITHREAD]
ata7: <ATA channel 3> on atapci1
ata7: [ITHREAD]
pci3: <network, ethernet> at device 2.0 (no driver attached)
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci2: <Intel ICH9 SATA300 controller> port
0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf
mem 0xff970000-0xff9707ff irq 18 at device 31.2 on pci0
atapci2: [ITHREAD]
atapci2: AHCI called from vendor specific driver
atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported
ata8: <ATA channel 0> on atapci2
ata8: [ITHREAD]
ata9: <ATA channel 1> on atapci2
ata9: [ITHREAD]
ata10: <ATA channel 2> on atapci2
ata10: [ITHREAD]
ata11: <ATA channel 3> on atapci2
ata11: [ITHREAD]
ata12: <ATA channel 5> on atapci2
ata12: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
atrtc0: <AT realtime clock> port 0x70-0x7f irq 8 on acpi0
fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq
2 on acpi0
fdc0: [FILTER]
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
orm0: <ISA Option ROMs> at iomem
0xc0000-0xce7ff,0xce800-0xd37ff,0xd3800-0xd57ff,0xd5800-0xd7fff on
isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
est2: <Enhanced SpeedStep Frequency Control> on cpu2
p4tcc2: <CPU Frequency Thermal Control> on cpu2
est3: <Enhanced SpeedStep Frequency Control> on cpu3
p4tcc3: <CPU Frequency Thermal Control> on cpu3
ZFS filesystem version 3
ZFS storage pool version 14
RTC BIOS diagnostic error 11<memory_size>
Timecounters tick every 1.000 msec
vboxdrv: fAsync=0 offMin=0x171 offMax=0x360
ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based
forwarding disabled, default to deny, logging disabled
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched WF2Q+ loaded
load_dn_sched dn_sched FIFO loaded
load_dn_sched dn_sched PRIO loaded
hdac0: HDA Codec #0: Analog Devices AD1984
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 12Mbps Full Speed USB v1.0
usbus5: 12Mbps Full Speed USB v1.0
usbus6: 480Mbps High Speed USB v2.0
pcm0: <HDA Analog Devices AD1984 PCM #0 Analog> at cad 0 nid 1 on hdac0
pcm1: <HDA Analog Devices AD1984 PCM #1 Analog> at cad 0 nid 1 on hdac0
ugen0.1: <Intel> at usbus0
uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <Intel> at usbus1
uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen2.1: <Intel> at usbus2
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
ugen3.1: <Intel> at usbus3
uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
ugen4.1: <Intel> at usbus4
uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus4
ugen5.1: <Intel> at usbus5
uhub5: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5
ugen6.1: <Intel> at usbus6
uhub6: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus6
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub4: 2 ports with 2 removable, self powered
uhub5: 2 ports with 2 removable, self powered
uhub2: 6 ports with 6 removable, self powered
uhub6: 6 ports with 6 removable, self powered
(noperiph:ata7:0:-1:-1): rescan already queued
ugen0.2: <Dell> at usbus0
ukbd0: <Dell Dell USB Keyboard, class 0/0, rev 1.10/3.50, addr 2> on usbus0
kbd2 at ukbd0
ada0 at ata7 bus 0 scbus5 target 0 lun 0
ada0: <WDC WD5000AAVS-00ZTB0 01.01B01> ATA-8 SATA 2.x device
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada1 at ata8 bus 0 scbus6 target 0 lun 0
ada1: <WDC WD5001AALS-00L3B2 01.03B01> ATA-8 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
cd0 at ata10 bus 0 scbus8 target 0 lun 0
cd0: <HL-DT-ST DVD-ROM GDRH20N 0D04> Removable CD-ROM SCSI-0 device
cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
ada2 at ata9 bus 0 scbus7 target 0 lun 0
ada2: <WDC WD5001AALS-00L3B2 01.03B01> ATA-8 SATA 2.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
lapic1: Forcing LINT1 to edge trigger
SMP: AP CPU #1 Launched!
lapic2: Forcing LINT1 to edge trigger
SMP: AP CPU #2 Launched!
lapic3: Forcing LINT1 to edge trigger
SMP: AP CPU #3 Launched!
cd1 at ata11 bus 0 scbus9 target 0 lun 0
cd1: <PBDS DVD+-RW DH-16W1S 2D14> Removable CD-ROM SCSI-0 device
cd1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd1: cd present [1 x 2048 byte records]
ugen0.3: <vendor 0x0461> at usbus0
ums0: <vendor 0x0461 USB Optical Mouse, class 0/0, rev 2.00/2.00, addr
3> on usbus0
ums0: 3 buttons and [XYZ] coordinates ID=0
GEOM_MIRROR: Device mirror/swap launched (2/2).
Trying to mount root from zfs:zroot
vboxnet0: Ethernet address: 0a:00:27:00:00:00
(cd1:ata11:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0
(cd1:ata11:0:0:0): CAM status: SCSI Status Error
(cd1:ata11:0:0:0): SCSI status: Check Condition
(cd1:ata11:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 0 0 done
All buffers synced.
GEOM_MIRROR: Device swap: provider mirror/swap destroyed.
GEOM_MIRROR: Device swap destroyed.
------------------------------
Message: 5
Date: Thu, 8 Apr 2010 10:06:50 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: Brandon Gooch <jamesbra...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID:
<z2o2a41acea1004081006v9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch
<jamesbra...@gmail.com>wrote:
> On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel <jfv...@gmail.com> wrote:
> > Mike, I noticed this connection is only 100Mb, that isn't accidental?
> And,
> > is it possible for
> > you to check a connection at 1Gb and see if the watchdogs don't happen.
> >
> > My test engineer is running this code, and we are having trouble
> repro'ing
> > the issue, so any
> > clues might help. Is the kernel 64 or 32 bit?
> >
> > Jack
> >
>
> Not to butt in or anything...
>
Not butting in :) OK, so this all looks fine or am I missing something?
Jack
>
> 64-bit FreeBSD Stable, 1Gb em(4) connected to Cisco 2960G trunking port.
>
> My dmesg:
>
> Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation.
> FreeBSD 8.0-STABLE #2 r206210:206343MS: Wed Apr 7 16:18:14 CDT 2010
> ro...@bgooch755.se.edu:/usr/obj/usr/src/sys/DELL755 amd64
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.00-MHz K8-class
> CPU)
> Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11
>
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
> AMD Features=0x20100800<SYSCALL,NX,LM>
> AMD Features2=0x1<LAHF>
> TSC: P-state invariant
> real memory = 8589934592 (8192 MB)
> avail memory = 8103940096 (7728 MB)
> ACPI APIC Table: <DELL B9K >
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 4 core(s)
> cpu0 (BSP): APIC ID: 0
> cpu1 (AP): APIC ID: 1
> cpu2 (AP): APIC ID: 2
> cpu3 (AP): APIC ID: 3
> ioapic0: Changing APIC ID to 8
> ioapic0 <Version 2.0> irqs 0-23 on motherboard
> lapic0: Forcing LINT1 to edge trigger
> kbd1 at kbdmux0
> acpi0: <DELL B9K > on motherboard
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> cpu0: <ACPI CPU> on acpi0
> cpu1: <ACPI CPU> on acpi0
> cpu2: <ACPI CPU> on acpi0
> cpu3: <ACPI CPU> on acpi0
> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
> acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 900
> acpi_button0: <Power Button> on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> vgapci0: <VGA-compatible display> port 0xdc80-0xdcff mem
> 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq
> 16 at device 0.0 on pci1
> nvidia0: <GeForce 8400 GS> on vgapci0
> vgapci0: child nvidia0 requested pci_enable_busmaster
> vgapci0: child nvidia0 requested pci_enable_io
> vgapci0: child nvidia0 requested pci_enable_io
> nvidia0: [ITHREAD]
> pci0: <simple comms> at device 3.0 (no driver attached)
> atapci0: <Intel ATA controller> port
> 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff
> irq 18 at device 3.2 on pci0
> atapci0: [ITHREAD]
> ata2: <ATA channel 0> on atapci0
> ata2: [ITHREAD]
> ata3: <ATA channel 1> on atapci0
> ata3: [ITHREAD]
> pci0: <simple comms, UART> at device 3.3 (no driver attached)
> em0: <Intel(R) PRO/1000 Network Connection 7.0.1> port 0xecc0-0xecdf
> mem 0xfebe0000-0xfebfffff,0xfebdb000-0xfebdbfff irq 21 at device 25.0
> on pci0
> em0: Using MSI interrupt
> em0: [FILTER]
> em0: Ethernet address: 00:1e:4f:d5:84:b7
> uhci0: <Intel 82801I (ICH9) USB controller> port 0xff20-0xff3f irq 16
> at device 26.0 on pci0
> uhci0: [ITHREAD]
> uhci0: LegSup = 0x2f00
> usbus0: <Intel 82801I (ICH9) USB controller> on uhci0
> uhci1: <Intel 82801I (ICH9) USB controller> port 0xff00-0xff1f irq 17
> at device 26.1 on pci0
> uhci1: [ITHREAD]
> uhci1: LegSup = 0x2f00
> usbus1: <Intel 82801I (ICH9) USB controller> on uhci1
> ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem
> 0xfebd9c00-0xfebd9fff irq 22 at device 26.7 on pci0
> ehci0: [ITHREAD]
> usbus2: EHCI version 1.0
> usbus2: <Intel 82801I (ICH9) USB 2.0 controller> on ehci0
> hdac0: <Intel 82801I High Definition Audio Controller> mem
> 0xfebdc000-0xfebdffff irq 16 at device 27.0 on pci0
> hdac0: HDA Driver Revision: 20100226_0142
> hdac0: [ITHREAD]
> pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
> pci2: <ACPI PCI bus> on pcib2
> uhci2: <Intel 82801I (ICH9) USB controller> port 0xff80-0xff9f irq 23
> at device 29.0 on pci0
> uhci2: [ITHREAD]
> usbus3: <Intel 82801I (ICH9) USB controller> on uhci2
> uhci3: <Intel 82801I (ICH9) USB controller> port 0xff60-0xff7f irq 17
> at device 29.1 on pci0
> uhci3: [ITHREAD]
> usbus4: <Intel 82801I (ICH9) USB controller> on uhci3
> uhci4: <Intel 82801I (ICH9) USB controller> port 0xff40-0xff5f irq 18
> at device 29.2 on pci0
> uhci4: [ITHREAD]
> usbus5: <Intel 82801I (ICH9) USB controller> on uhci4
> ehci1: <Intel 82801I (ICH9) USB 2.0 controller> mem
> 0xff980800-0xff980bff irq 23 at device 29.7 on pci0
> ehci1: [ITHREAD]
> usbus6: EHCI version 1.0
> usbus6: <Intel 82801I (ICH9) USB 2.0 controller> on ehci1
> pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> pci3: <ACPI PCI bus> on pcib3
> atapci1: <SiI 3114 SATA150 controller> port
> 0xc8e0-0xc8e7,0xc8d8-0xc8db,0xc8e8-0xc8ef,0xc8dc-0xc8df,0xc8f0-0xc8ff
> mem 0xf9dffc00-0xf9dfffff irq 16 at device 0.0 on pci3
> atapci1: [ITHREAD]
> ata4: <ATA channel 0> on atapci1
> ata4: [ITHREAD]
> ata5: <ATA channel 1> on atapci1
> ata5: [ITHREAD]
> ata6: <ATA channel 2> on atapci1
> ata6: [ITHREAD]
> ata7: <ATA channel 3> on atapci1
> ata7: [ITHREAD]
> pci3: <network, ethernet> at device 2.0 (no driver attached)
> isab0: <PCI-ISA bridge> at device 31.0 on pci0
> isa0: <ISA bus> on isab0
> atapci2: <Intel ICH9 SATA300 controller> port
> 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf
> mem 0xff970000-0xff9707ff irq 18 at device 31.2 on pci0
> atapci2: [ITHREAD]
> atapci2: AHCI called from vendor specific driver
> atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported
> ata8: <ATA channel 0> on atapci2
> ata8: [ITHREAD]
> ata9: <ATA channel 1> on atapci2
> ata9: [ITHREAD]
> ata10: <ATA channel 2> on atapci2
> ata10: [ITHREAD]
> ata11: <ATA channel 3> on atapci2
> ata11: [ITHREAD]
> ata12: <ATA channel 5> on atapci2
> ata12: [ITHREAD]
> pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
> atrtc0: <AT realtime clock> port 0x70-0x7f irq 8 on acpi0
> fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq
> 2 on acpi0
> fdc0: [FILTER]
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart0: [FILTER]
> orm0: <ISA Option ROMs> at iomem
> 0xc0000-0xce7ff,0xce800-0xd37ff,0xd3800-0xd57ff,0xd5800-0xd7fff on
> isa0
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> p4tcc1: <CPU Frequency Thermal Control> on cpu1
> est2: <Enhanced SpeedStep Frequency Control> on cpu2
> p4tcc2: <CPU Frequency Thermal Control> on cpu2
> est3: <Enhanced SpeedStep Frequency Control> on cpu3
> p4tcc3: <CPU Frequency Thermal Control> on cpu3
> ZFS filesystem version 3
> ZFS storage pool version 14
> RTC BIOS diagnostic error 11<memory_size>
> Timecounters tick every 1.000 msec
> vboxdrv: fAsync=0 offMin=0x171 offMax=0x360
> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based
> forwarding disabled, default to deny, logging disabled
> load_dn_sched dn_sched QFQ loaded
> load_dn_sched dn_sched RR loaded
> load_dn_sched dn_sched WF2Q+ loaded
> load_dn_sched dn_sched FIFO loaded
> load_dn_sched dn_sched PRIO loaded
> hdac0: HDA Codec #0: Analog Devices AD1984
> usbus0: 12Mbps Full Speed USB v1.0
> usbus1: 12Mbps Full Speed USB v1.0
> usbus2: 480Mbps High Speed USB v2.0
> usbus3: 12Mbps Full Speed USB v1.0
> usbus4: 12Mbps Full Speed USB v1.0
> usbus5: 12Mbps Full Speed USB v1.0
> usbus6: 480Mbps High Speed USB v2.0
> pcm0: <HDA Analog Devices AD1984 PCM #0 Analog> at cad 0 nid 1 on hdac0
> pcm1: <HDA Analog Devices AD1984 PCM #1 Analog> at cad 0 nid 1 on hdac0
> ugen0.1: <Intel> at usbus0
> uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
> ugen1.1: <Intel> at usbus1
> uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
> ugen2.1: <Intel> at usbus2
> uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
> ugen3.1: <Intel> at usbus3
> uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
> ugen4.1: <Intel> at usbus4
> uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus4
> ugen5.1: <Intel> at usbus5
> uhub5: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5
> ugen6.1: <Intel> at usbus6
> uhub6: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus6
> uhub0: 2 ports with 2 removable, self powered
> uhub1: 2 ports with 2 removable, self powered
> uhub3: 2 ports with 2 removable, self powered
> uhub4: 2 ports with 2 removable, self powered
> uhub5: 2 ports with 2 removable, self powered
> uhub2: 6 ports with 6 removable, self powered
> uhub6: 6 ports with 6 removable, self powered
> (noperiph:ata7:0:-1:-1): rescan already queued
> ugen0.2: <Dell> at usbus0
> ukbd0: <Dell Dell USB Keyboard, class 0/0, rev 1.10/3.50, addr 2> on usbus0
> kbd2 at ukbd0
> ada0 at ata7 bus 0 scbus5 target 0 lun 0
> ada0: <WDC WD5000AAVS-00ZTB0 01.01B01> ATA-8 SATA 2.x device
> ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
> ada1 at ata8 bus 0 scbus6 target 0 lun 0
> ada1: <WDC WD5001AALS-00L3B2 01.03B01> ATA-8 SATA 2.x device
> ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
> ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
> cd0 at ata10 bus 0 scbus8 target 0 lun 0
> cd0: <HL-DT-ST DVD-ROM GDRH20N 0D04> Removable CD-ROM SCSI-0 device
> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> ada2 at ata9 bus 0 scbus7 target 0 lun 0
> ada2: <WDC WD5001AALS-00L3B2 01.03B01> ATA-8 SATA 2.x device
> ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
> lapic1: Forcing LINT1 to edge trigger
> SMP: AP CPU #1 Launched!
> lapic2: Forcing LINT1 to edge trigger
> SMP: AP CPU #2 Launched!
> lapic3: Forcing LINT1 to edge trigger
> SMP: AP CPU #3 Launched!
> cd1 at ata11 bus 0 scbus9 target 0 lun 0
> cd1: <PBDS DVD+-RW DH-16W1S 2D14> Removable CD-ROM SCSI-0 device
> cd1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
> cd1: cd present [1 x 2048 byte records]
> ugen0.3: <vendor 0x0461> at usbus0
> ums0: <vendor 0x0461 USB Optical Mouse, class 0/0, rev 2.00/2.00, addr
> 3> on usbus0
> ums0: 3 buttons and [XYZ] coordinates ID=0
> GEOM_MIRROR: Device mirror/swap launched (2/2).
> Trying to mount root from zfs:zroot
> vboxnet0: Ethernet address: 0a:00:27:00:00:00
> (cd1:ata11:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0
> (cd1:ata11:0:0:0): CAM status: SCSI Status Error
> (cd1:ata11:0:0:0): SCSI status: Check Condition
> (cd1:ata11:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in
> CDB)
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> Waiting (max 60 seconds) for system process `syncer' to stop...
> Syncing disks, vnodes remaining...0 0 0 0 0 done
> All buffers synced.
> GEOM_MIRROR: Device swap: provider mirror/swap destroyed.
> GEOM_MIRROR: Device swap destroyed.
>
------------------------------
Message: 6
Date: Thu, 8 Apr 2010 22:15:00 +0530
From: Anoop Kumar Narayanan <anoo...@gmail.com>
Subject: Re: random FreeBSD panics
To: Masoom Shaikh <masoom...@gmail.com>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org, Ivan
Voras <ivo...@freebsd.org>, freebsd-...@freebsd.org
Message-ID:
<w2h7ff5545f1004080945pf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Apr 3, 2010 at 6:21 PM, Masoom Shaikh <masoom...@gmail.com> wrote:
> On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras <ivo...@freebsd.org> wrote:
>> On 28 March 2010 16:42, Masoom Shaikh <masoom...@gmail.com> wrote:
>>
>>> lets assume if this is h/w problem, then how can other OSes overcome
>>> this ? is there a way to make FreeBSD ignore this as well, let it
>>> result in reasonable performance penalty.
>>
>> Very probably, if only we could detect where the problem is.
>> Try adding "options PRINTF_BUFR_SIZE=128" to the kernel
>> configuration file if you can, to see if you can get a less mangled
>> log outout.
>>
>
> ok, after few days of silence I am back with more questions
> this time system feels little better, it is able to sustain for more
> time that what 7.3-RELEASE could
>
> FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1
> 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64
>
> I am using KDE4, and when OS freezes, well it freezes, means I cannot
> change to tty0 and see the panic text, if any it might possibly have
> spit. the stuck frozen GUI keeps staring there. So the question is how
> to I capture that panic text ? unfortunately I am not getting core
> files too, so there is nothing I can pick up hints
>
> is there some option (KDB, DDB), so that on panic system drop to debugger ?
>
> Masoom Shaikh
I am having the very same problem, with my AMD64 running i386 (both
7.3-REL and 8.0-REL) keeps crashing, The best part is, if I disable
ACPI it crashes before it even boots up so is the case with safe-mode
and single-user-mode. With ACPI it boots up but crashes after a while.
I have the vmcore files on the system. Who do I contact on this regard
?
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>
------------------------------
Message: 7
Date: Thu, 8 Apr 2010 12:18:58 -0500
From: Brandon Gooch <jamesbra...@gmail.com>
Subject: Re: em driver regression
To: Jack Vogel <jfv...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID:
<x2k179b97fb1004081018x5...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 12:06 PM, Jack Vogel <jfv...@gmail.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch <jamesbra...@gmail.com>
> wrote:
>>
>> On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel <jfv...@gmail.com> wrote:
>> > Mike, I noticed this connection is only 100Mb, that isn't accidental?
>> > And,
>> > is it possible for
>> > you to check a connection at 1Gb and see if the watchdogs don't happen.
>> >
>> > My test engineer is running this code, and we are having trouble
>> > repro'ing
>> > the issue, so any
>> > clues might help. Is the kernel 64 or 32 bit?
>> >
>> > Jack
>> >
>>
>> Not to butt in or anything...
>
> Not butting in :) OK, so this all looks fine or am I missing something?
>
> Jack
>
This is the dmesg from the system exhibiting the "ip length 328
disagrees with bytes received 332" while attempting to obtain a lease
on the two DHCP-enabled VLANs, and also manifests in the VirtualBox
bridged networking guests.
I can honestly say that other than the output from dhclient and the
VirtualBox issue, I might not have noticed problems otherwise.
For instance, I have a VLAN interface configured to connect to an
"outside" LAN segment and I'm running sshd on that interfaces IP
address (using the new multiple routing table feature as well). I was
able to connect to the sshd instance as usual, and I can make
connections out as in:
# setfib 4 ping google.com
...things seemed OK. Until VirtualBox. Then I started paying attention
to messages scrolling by as my machine booted and saw the dhclient "ip
length" thing (just as Mike Tancsa had) and thought, "It must be the
new em(4) driver".
That's my story :)
I don't know what chip my em(4) device is, how can I check that? Also,
would some type of traffic capture help in this case?
-Brandon
>>
>> 64-bit FreeBSD Stable, 1Gb em(4) connected to Cisco 2960G trunking port.
>>
>> My dmesg:
>>
>> Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 8.0-STABLE #2 r206210:206343MS: Wed Apr 7 16:18:14 CDT 2010
>> ro...@bgooch755.se.edu:/usr/obj/usr/src/sys/DELL755 amd64
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.00-MHz K8-class
>> CPU)
>> Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11
>>
>> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>> Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
>> AMD Features=0x20100800<SYSCALL,NX,LM>
>> AMD Features2=0x1<LAHF>
>> TSC: P-state invariant
>> real memory = 8589934592 (8192 MB)
>> avail memory = 8103940096 (7728 MB)
>> ACPI APIC Table: <DELL B9K >
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>> FreeBSD/SMP: 1 package(s) x 4 core(s)
>> cpu0 (BSP): APIC ID: 0
>> cpu1 (AP): APIC ID: 1
>> cpu2 (AP): APIC ID: 2
>> cpu3 (AP): APIC ID: 3
>> ioapic0: Changing APIC ID to 8
>> ioapic0 <Version 2.0> irqs 0-23 on motherboard
>> lapic0: Forcing LINT1 to edge trigger
>> kbd1 at kbdmux0
>> acpi0: <DELL B9K > on motherboard
>> acpi0: [ITHREAD]
>> acpi0: Power Button (fixed)
>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
>> cpu0: <ACPI CPU> on acpi0
>> cpu1: <ACPI CPU> on acpi0
>> cpu2: <ACPI CPU> on acpi0
>> cpu3: <ACPI CPU> on acpi0
>> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
>> acpi0
>> Timecounter "HPET" frequency 14318180 Hz quality 900
>> acpi_button0: <Power Button> on acpi0
>> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
>> pci0: <ACPI PCI bus> on pcib0
>> pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
>> pci1: <ACPI PCI bus> on pcib1
>> vgapci0: <VGA-compatible display> port 0xdc80-0xdcff mem
>> 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq
>> 16 at device 0.0 on pci1
>> nvidia0: <GeForce 8400 GS> on vgapci0
>> vgapci0: child nvidia0 requested pci_enable_busmaster
>> vgapci0: child nvidia0 requested pci_enable_io
>> vgapci0: child nvidia0 requested pci_enable_io
>> nvidia0: [ITHREAD]
>> pci0: <simple comms> at device 3.0 (no driver attached)
>> atapci0: <Intel ATA controller> port
>> 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff
>> irq 18 at device 3.2 on pci0
>> atapci0: [ITHREAD]
>> ata2: <ATA channel 0> on atapci0
>> ata2: [ITHREAD]
>> ata3: <ATA channel 1> on atapci0
>> ata3: [ITHREAD]
>> pci0: <simple comms, UART> at device 3.3 (no driver attached)
>> em0: <Intel(R) PRO/1000 Network Connection 7.0.1> port 0xecc0-0xecdf
>> mem 0xfebe0000-0xfebfffff,0xfebdb000-0xfebdbfff irq 21 at device 25.0
>> on pci0
>> em0: Using MSI interrupt
>> em0: [FILTER]
>> em0: Ethernet address: 00:1e:4f:d5:84:b7
>> uhci0: <Intel 82801I (ICH9) USB controller> port 0xff20-0xff3f irq 16
>> at device 26.0 on pci0
>> uhci0: [ITHREAD]
>> uhci0: LegSup = 0x2f00
>> usbus0: <Intel 82801I (ICH9) USB controller> on uhci0
>> uhci1: <Intel 82801I (ICH9) USB controller> port 0xff00-0xff1f irq 17
>> at device 26.1 on pci0
>> uhci1: [ITHREAD]
>> uhci1: LegSup = 0x2f00
>> usbus1: <Intel 82801I (ICH9) USB controller> on uhci1
>> ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem
>> 0xfebd9c00-0xfebd9fff irq 22 at device 26.7 on pci0
>> ehci0: [ITHREAD]
>> usbus2: EHCI version 1.0
>> usbus2: <Intel 82801I (ICH9) USB 2.0 controller> on ehci0
>> hdac0: <Intel 82801I High Definition Audio Controller> mem
>> 0xfebdc000-0xfebdffff irq 16 at device 27.0 on pci0
>> hdac0: HDA Driver Revision: 20100226_0142
>> hdac0: [ITHREAD]
>> pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
>> pci2: <ACPI PCI bus> on pcib2
>> uhci2: <Intel 82801I (ICH9) USB controller> port 0xff80-0xff9f irq 23
>> at device 29.0 on pci0
>> uhci2: [ITHREAD]
>> usbus3: <Intel 82801I (ICH9) USB controller> on uhci2
>> uhci3: <Intel 82801I (ICH9) USB controller> port 0xff60-0xff7f irq 17
>> at device 29.1 on pci0
>> uhci3: [ITHREAD]
>> usbus4: <Intel 82801I (ICH9) USB controller> on uhci3
>> uhci4: <Intel 82801I (ICH9) USB controller> port 0xff40-0xff5f irq 18
>> at device 29.2 on pci0
>> uhci4: [ITHREAD]
>> usbus5: <Intel 82801I (ICH9) USB controller> on uhci4
>> ehci1: <Intel 82801I (ICH9) USB 2.0 controller> mem
>> 0xff980800-0xff980bff irq 23 at device 29.7 on pci0
>> ehci1: [ITHREAD]
>> usbus6: EHCI version 1.0
>> usbus6: <Intel 82801I (ICH9) USB 2.0 controller> on ehci1
>> pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
>> pci3: <ACPI PCI bus> on pcib3
>> atapci1: <SiI 3114 SATA150 controller> port
>> 0xc8e0-0xc8e7,0xc8d8-0xc8db,0xc8e8-0xc8ef,0xc8dc-0xc8df,0xc8f0-0xc8ff
>> mem 0xf9dffc00-0xf9dfffff irq 16 at device 0.0 on pci3
>> atapci1: [ITHREAD]
>> ata4: <ATA channel 0> on atapci1
>> ata4: [ITHREAD]
>> ata5: <ATA channel 1> on atapci1
>> ata5: [ITHREAD]
>> ata6: <ATA channel 2> on atapci1
>> ata6: [ITHREAD]
>> ata7: <ATA channel 3> on atapci1
>> ata7: [ITHREAD]
>> pci3: <network, ethernet> at device 2.0 (no driver attached)
>> isab0: <PCI-ISA bridge> at device 31.0 on pci0
>> isa0: <ISA bus> on isab0
>> atapci2: <Intel ICH9 SATA300 controller> port
>> 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf
>> mem 0xff970000-0xff9707ff irq 18 at device 31.2 on pci0
>> atapci2: [ITHREAD]
>> atapci2: AHCI called from vendor specific driver
>> atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported
>> ata8: <ATA channel 0> on atapci2
>> ata8: [ITHREAD]
>> ata9: <ATA channel 1> on atapci2
>> ata9: [ITHREAD]
>> ata10: <ATA channel 2> on atapci2
>> ata10: [ITHREAD]
>> ata11: <ATA channel 3> on atapci2
>> ata11: [ITHREAD]
>> ata12: <ATA channel 5> on atapci2
>> ata12: [ITHREAD]
>> pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
>> atrtc0: <AT realtime clock> port 0x70-0x7f irq 8 on acpi0
>> fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq
>> 2 on acpi0
>> fdc0: [FILTER]
>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
>> uart0: [FILTER]
>> orm0: <ISA Option ROMs> at iomem
>> 0xc0000-0xce7ff,0xce800-0xd37ff,0xd3800-0xd57ff,0xd5800-0xd7fff on
>> isa0
>> sc0: <System console> at flags 0x100 on isa0
>> sc0: VGA <16 virtual consoles, flags=0x300>
>> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
>> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> kbd0 at atkbd0
>> atkbd0: [GIANT-LOCKED]
>> atkbd0: [ITHREAD]
>> est0: <Enhanced SpeedStep Frequency Control> on cpu0
>> p4tcc0: <CPU Frequency Thermal Control> on cpu0
>> est1: <Enhanced SpeedStep Frequency Control> on cpu1
>> p4tcc1: <CPU Frequency Thermal Control> on cpu1
>> est2: <Enhanced SpeedStep Frequency Control> on cpu2
>> p4tcc2: <CPU Frequency Thermal Control> on cpu2
>> est3: <Enhanced SpeedStep Frequency Control> on cpu3
>> p4tcc3: <CPU Frequency Thermal Control> on cpu3
>> ZFS filesystem version 3
>> ZFS storage pool version 14
>> RTC BIOS diagnostic error 11<memory_size>
>> Timecounters tick every 1.000 msec
>> vboxdrv: fAsync=0 offMin=0x171 offMax=0x360
>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based
>> forwarding disabled, default to deny, logging disabled
>> load_dn_sched dn_sched QFQ loaded
>> load_dn_sched dn_sched RR loaded
>> load_dn_sched dn_sched WF2Q+ loaded
>> load_dn_sched dn_sched FIFO loaded
>> load_dn_sched dn_sched PRIO loaded
>> hdac0: HDA Codec #0: Analog Devices AD1984
>> usbus0: 12Mbps Full Speed USB v1.0
>> usbus1: 12Mbps Full Speed USB v1.0
>> usbus2: 480Mbps High Speed USB v2.0
>> usbus3: 12Mbps Full Speed USB v1.0
>> usbus4: 12Mbps Full Speed USB v1.0
>> usbus5: 12Mbps Full Speed USB v1.0
>> usbus6: 480Mbps High Speed USB v2.0
>> pcm0: <HDA Analog Devices AD1984 PCM #0 Analog> at cad 0 nid 1 on hdac0
>> pcm1: <HDA Analog Devices AD1984 PCM #1 Analog> at cad 0 nid 1 on hdac0
>> ugen0.1: <Intel> at usbus0
>> uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
>> ugen1.1: <Intel> at usbus1
>> uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
>> ugen2.1: <Intel> at usbus2
>> uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
>> ugen3.1: <Intel> at usbus3
>> uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
>> ugen4.1: <Intel> at usbus4
>> uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus4
>> ugen5.1: <Intel> at usbus5
>> uhub5: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5
>> ugen6.1: <Intel> at usbus6
>> uhub6: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus6
>> uhub0: 2 ports with 2 removable, self powered
>> uhub1: 2 ports with 2 removable, self powered
>> uhub3: 2 ports with 2 removable, self powered
>> uhub4: 2 ports with 2 removable, self powered
>> uhub5: 2 ports with 2 removable, self powered
>> uhub2: 6 ports with 6 removable, self powered
>> uhub6: 6 ports with 6 removable, self powered
>> (noperiph:ata7:0:-1:-1): rescan already queued
>> ugen0.2: <Dell> at usbus0
>> ukbd0: <Dell Dell USB Keyboard, class 0/0, rev 1.10/3.50, addr 2> on
>> usbus0
>> kbd2 at ukbd0
>> ada0 at ata7 bus 0 scbus5 target 0 lun 0
>> ada0: <WDC WD5000AAVS-00ZTB0 01.01B01> ATA-8 SATA 2.x device
>> ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
>> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
>> ada1 at ata8 bus 0 scbus6 target 0 lun 0
>> ada1: <WDC WD5001AALS-00L3B2 01.03B01> ATA-8 SATA 2.x device
>> ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
>> ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
>> cd0 at ata10 bus 0 scbus8 target 0 lun 0
>> cd0: <HL-DT-ST DVD-ROM GDRH20N 0D04> Removable CD-ROM SCSI-0 device
>> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
>> cd0: Attempt to query device size failed: NOT READY, Medium not present
>> ada2 at ata9 bus 0 scbus7 target 0 lun 0
>> ada2: <WDC WD5001AALS-00L3B2 01.03B01> ATA-8 SATA 2.x device
>> ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
>> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
>> lapic1: Forcing LINT1 to edge trigger
>> SMP: AP CPU #1 Launched!
>> lapic2: Forcing LINT1 to edge trigger
>> SMP: AP CPU #2 Launched!
>> lapic3: Forcing LINT1 to edge trigger
>> SMP: AP CPU #3 Launched!
>> cd1 at ata11 bus 0 scbus9 target 0 lun 0
>> cd1: <PBDS DVD+-RW DH-16W1S 2D14> Removable CD-ROM SCSI-0 device
>> cd1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
>> cd1: cd present [1 x 2048 byte records]
>> ugen0.3: <vendor 0x0461> at usbus0
>> ums0: <vendor 0x0461 USB Optical Mouse, class 0/0, rev 2.00/2.00, addr
>> 3> on usbus0
>> ums0: 3 buttons and [XYZ] coordinates ID=0
>> GEOM_MIRROR: Device mirror/swap launched (2/2).
>> Trying to mount root from zfs:zroot
>> vboxnet0: Ethernet address: 0a:00:27:00:00:00
>> (cd1:ata11:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0
>> (cd1:ata11:0:0:0): CAM status: SCSI Status Error
>> (cd1:ata11:0:0:0): SCSI status: Check Condition
>> (cd1:ata11:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in
>> CDB)
>> Waiting (max 60 seconds) for system process `vnlru' to stop...done
>> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
>> Waiting (max 60 seconds) for system process `syncer' to stop...
>> Syncing disks, vnodes remaining...0 0 0 0 0 done
>> All buffers synced.
>> GEOM_MIRROR: Device swap: provider mirror/swap destroyed.
>> GEOM_MIRROR: Device swap destroyed.
>
------------------------------
Message: 8
Date: Thu, 8 Apr 2010 10:23:32 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: Brandon Gooch <jamesbra...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID:
<o2r2a41acea1004081023ia...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 10:18 AM, Brandon Gooch
<jamesbra...@gmail.com>wrote:
> On Thu, Apr 8, 2010 at 12:06 PM, Jack Vogel <jfv...@gmail.com> wrote:
> >
> >
> > On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch <
> jamesbra...@gmail.com>
> > wrote:
> >>
> >> On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel <jfv...@gmail.com> wrote:
> >> > Mike, I noticed this connection is only 100Mb, that isn't accidental?
> >> > And,
> >> > is it possible for
> >> > you to check a connection at 1Gb and see if the watchdogs don't
> happen.
> >> >
> >> > My test engineer is running this code, and we are having trouble
> >> > repro'ing
> >> > the issue, so any
> >> > clues might help. Is the kernel 64 or 32 bit?
> >> >
> >> > Jack
> >> >
> >>
> >> Not to butt in or anything...
> >
> > Not butting in :) OK, so this all looks fine or am I missing something?
> >
> > Jack
> >
>
> This is the dmesg from the system exhibiting the "ip length 328
> disagrees with bytes received 332" while attempting to obtain a lease
> on the two DHCP-enabled VLANs, and also manifests in the VirtualBox
> bridged networking guests.
>
> I can honestly say that other than the output from dhclient and the
> VirtualBox issue, I might not have noticed problems otherwise.
>
> For instance, I have a VLAN interface configured to connect to an
> "outside" LAN segment and I'm running sshd on that interfaces IP
> address (using the new multiple routing table feature as well). I was
> able to connect to the sshd instance as usual, and I can make
> connections out as in:
>
> # setfib 4 ping google.com
>
> ...things seemed OK. Until VirtualBox. Then I started paying attention
> to messages scrolling by as my machine booted and saw the dhclient "ip
> length" thing (just as Mike Tancsa had) and thought, "It must be the
> new em(4) driver".
>
> That's my story :)
>
> I don't know what chip my em(4) device is, how can I check that? Also,
> would some type of traffic capture help in this case?
>
> -Brandon
>
>
pciconf -l will show us. my tester is having trouble reproducing this,
but I dont think he is using vlans, that must be the missing ingredient.
The disagreement in size is 4 bytes, just the size of the CRC
coincidentally, but I dont have it set to strip, hmmmm. I may have
some code for you to try shortly, stay tuned.
Jack
------------------------------
Message: 9
Date: Thu, 08 Apr 2010 13:46:35 -0400
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: em driver regression
To: Jack Vogel <jfv...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <201004081746....@lava.sentex.ca>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 12:52 PM 4/8/2010, Jack Vogel wrote:
>Mike, I noticed this connection is only 100Mb, that isn't
>accidental? And, is it possible for
>you to check a connection at 1Gb and see if the watchdogs don't happen.
>
>My test engineer is running this code, and we are having trouble
>repro'ing the issue, so any
>clues might help. Is the kernel 64 or 32 bit?
It is a 32 bit kernel (see the attached dmesg from the first email)
in a cisco 10/100 switch. I just tried and the dhclient issue happens
at gig speeds as well.
Apr 8 13:34:29 ich10 dhclient[1480]: DHCPREQUEST on em0 to
255.255.255.255 port 67
Apr 8 13:34:35 ich10 dhclient[1480]: DHCPREQUEST on em0 to
255.255.255.255 port 67
Apr 8 13:34:48 ich10 dhclient[1480]: DHCPDISCOVER on em0 to
255.255.255.255 port 67 interval 5
Apr 8 13:34:48 ich10 dhclient[1480]: ip length 328 disagrees with
bytes received 332.
Apr 8 13:34:48 ich10 dhclient[1480]: accepting packet with data
after udp payload.
0(ich10)# ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=399b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:1c:c0:95:0d:0d
inet 192.168.xx.219 netmask 0xffffff00 broadcast 192.168.xx.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
0(ich10)#
... As for the watchdog issue, it just seems to show up. I am not
able to reproduce it on demand. However, the dhclient issue happens
all the time. I will give it a whirl on a gigabit for a day and see.
Its not that frequent
Apr 7 02:19:05 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 03:46:51 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 08:04:03 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 10:39:40 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 11:12:34 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 13:25:26 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 14:01:36 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 17:19:53 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 21:16:45 ich10 kernel: em0: Watchdog timeout -- resetting
Apr 7 22:09:10 ich10 kernel: em0: Watchdog timeout -- resetting
But it should in theory show up at least once in 24hrs if its not a
port speed issue.
A potential 3rd issue I also noticed is that this morning I could not
login to the box-- but I could ping it, but no SSH banner. ie no 3way
handshake completing. I was able to 'fix' the issue by logging onto
the console, initiating some outbound tcp traffic (ie. ssh out from
the box) and then I could login again. Perhaps a TSO issue ? I now
have a firewire console hooked up so I can login out of band. If this
issue comes up again, how can I best narrow down what/where this 3rd issue is ?
---Mike
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
------------------------------
Message: 10
Date: Thu, 8 Apr 2010 17:46:55 +0000
From: Masoom Shaikh <masoom...@gmail.com>
Subject: Re: random FreeBSD panics
To: Anoop Kumar Narayanan <anoo...@gmail.com>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org, Ivan
Voras <ivo...@freebsd.org>, freebsd-...@freebsd.org
Message-ID:
<m2kb10011eb1004081046oe...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 4:45 PM, Anoop Kumar Narayanan
<anoo...@gmail.com> wrote:
> On Sat, Apr 3, 2010 at 6:21 PM, Masoom Shaikh <masoom...@gmail.com> wrote:
>> On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras <ivo...@freebsd.org> wrote:
>>> On 28 March 2010 16:42, Masoom Shaikh <masoom...@gmail.com> wrote:
>>>
>>>> lets assume if this is h/w problem, then how can other OSes overcome
>>>> this ? is there a way to make FreeBSD ignore this as well, let it
>>>> result in reasonable performance penalty.
>>>
>>> Very probably, if only we could detect where the problem is.
>>> Try adding "options PRINTF_BUFR_SIZE=128" to the kernel
>>> configuration file if you can, to see if you can get a less mangled
>>> log outout.
>>>
>>
>> ok, after few days of silence I am back with more questions
>> this time system feels little better, it is able to sustain for more
>> time that what 7.3-RELEASE could
>>
>> FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1
>> 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64
>>
>> I am using KDE4, and when OS freezes, well it freezes, means I cannot
>> change to tty0 and see the panic text, if any it might possibly have
>> spit. the stuck frozen GUI keeps staring there. So the question is how
>> to I capture that panic text ? unfortunately I am not getting core
>> files too, so there is nothing I can pick up hints
>>
>> is there some option (KDB, DDB), so that on panic system drop to debugger ?
>>
>> Masoom Shaikh
>
> I am having the very same problem, with my AMD64 running i386 (both
> 7.3-REL and 8.0-REL) keeps crashing, The best part is, if I disable
> ACPI it crashes before it even boots up so is the case with safe-mode
> and single-user-mode. With ACPI it boots up but crashes after a while.
> I have the vmcore files on the system. Who do I contact on this regard
> ?
>
>> _______________________________________________
>> freebsd-...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>>
>
can u load that file in kgdb in get backtrace ?
------------------------------
Message: 11
Date: Thu, 8 Apr 2010 11:17:41 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: em driver regression
To: Mike Tancsa <mi...@sentex.net>
Cc: freebsd...@freebsd.org, jfv...@gmail.com
Message-ID: <2010040818...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"
On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
>
> OK, some more data... It seems dhclient is getting upset as well
> since the updated driver
>
> Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> 255.255.255.255 port 67 interval 6
> Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
> bytes received 332.
> Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data
> after udp payload.
> Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
> Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
> 255.255.255.255 port 67
> Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with
> bytes received 332.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Try this patch. It should fix the issue. It seems Jack forgot to
strip CRC bytes as old em(4) didn't strip it, probably to
workaround silicon bug of old em(4) controllers.
It seems there are also TX issues here. The system load is too high
and sometimes system is not responsive while TX is in progress.
Because I initiated TCP bulk transfers, TSO should reduce CPU load
a lot but it didn't so I guess it could also be related watchdog
timeouts you've seen. I'll see what can be done.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: em.crc.patch
Type: text/x-diff
Size: 802 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100408/28137632/em.crc-0001.bin
------------------------------
Message: 12
Date: Thu, 8 Apr 2010 11:18:48 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: Mike Tancsa <mi...@sentex.net>, Brandon Gooch
<jamesbra...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID:
<w2g2a41acea1004081118ja...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Both of you try something for me:
Assuming you are using the latest code in HEAD, at line 4042 please make
this insert:
/* Strip the CRC */
rctl |= E1000_RCTL_SECRC;
And try things again, I think this will solve at least the DHCP thing. I
hope.
Jack
On Thu, Apr 8, 2010 at 10:46 AM, Mike Tancsa <mi...@sentex.net> wrote:
> At 12:52 PM 4/8/2010, Jack Vogel wrote:
>
>> Mike, I noticed this connection is only 100Mb, that isn't accidental? And,
>> is it possible for
>> you to check a connection at 1Gb and see if the watchdogs don't happen.
>>
>> My test engineer is running this code, and we are having trouble repro'ing
>> the issue, so any
>> clues might help. Is the kernel 64 or 32 bit?
>>
>
> It is a 32 bit kernel (see the attached dmesg from the first email) in a
> cisco 10/100 switch. I just tried and the dhclient issue happens at gig
> speeds as well.
>
> Apr 8 13:34:29 ich10 dhclient[1480]: DHCPREQUEST on em0 to 255.255.255.255
> port 67
> Apr 8 13:34:35 ich10 dhclient[1480]: DHCPREQUEST on em0 to 255.255.255.255
> port 67
> Apr 8 13:34:48 ich10 dhclient[1480]: DHCPDISCOVER on em0 to
> 255.255.255.255 port 67 interval 5
> Apr 8 13:34:48 ich10 dhclient[1480]: ip length 328 disagrees with bytes
> received 332.
> Apr 8 13:34:48 ich10 dhclient[1480]: accepting packet with data after udp
> payload.
>
> 0(ich10)# ifconfig em0
>
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>
> options=399b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
> ether 00:1c:c0:95:0d:0d
> inet 192.168.xx.219 netmask 0xffffff00 broadcast 192.168.xx.255
> media: Ethernet autoselect (1000baseT <full-duplex>)
> status: active
> 0(ich10)#
>
>
> ... As for the watchdog issue, it just seems to show up. I am not able to
> reproduce it on demand. However, the dhclient issue happens all the time. I
> will give it a whirl on a gigabit for a day and see.
>
> Its not that frequent
>
>
> Apr 7 02:19:05 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 03:46:51 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 08:04:03 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 10:39:40 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 11:12:34 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 13:25:26 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 14:01:36 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 17:19:53 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 21:16:45 ich10 kernel: em0: Watchdog timeout -- resetting
> Apr 7 22:09:10 ich10 kernel: em0: Watchdog timeout -- resetting
>
> But it should in theory show up at least once in 24hrs if its not a port
> speed issue.
>
> A potential 3rd issue I also noticed is that this morning I could not login
> to the box-- but I could ping it, but no SSH banner. ie no 3way handshake
> completing. I was able to 'fix' the issue by logging onto the console,
> initiating some outbound tcp traffic (ie. ssh out from the box) and then I
> could login again. Perhaps a TSO issue ? I now have a firewire console
> hooked up so I can login out of band. If this issue comes up again, how can
> I best narrow down what/where this 3rd issue is ?
>
> ---Mike
>
>
>
> --------------------------------------------------------------------
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, mi...@sentex.net
> Providing Internet since 1994 www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
>
------------------------------
Message: 13
Date: Thu, 8 Apr 2010 11:20:35 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org
Message-ID:
<j2v2a41acea1004081120uf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
LOL, what timing :)
On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
> >
> > OK, some more data... It seems dhclient is getting upset as well
> > since the updated driver
> >
> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> > 255.255.255.255 port 67 interval 6
> > Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
> > bytes received 332.
> > Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data
> > after udp payload.
> > Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
> > 255.255.255.255 port 67
> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with
> > bytes received 332.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Try this patch. It should fix the issue. It seems Jack forgot to
> strip CRC bytes as old em(4) didn't strip it, probably to
> workaround silicon bug of old em(4) controllers.
>
> It seems there are also TX issues here. The system load is too high
> and sometimes system is not responsive while TX is in progress.
> Because I initiated TCP bulk transfers, TSO should reduce CPU load
> a lot but it didn't so I guess it could also be related watchdog
> timeouts you've seen. I'll see what can be done.
>
------------------------------
Message: 14
Date: Thu, 8 Apr 2010 11:22:34 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org
Message-ID:
<g2q2a41acea1004081122nd...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
> >
> > OK, some more data... It seems dhclient is getting upset as well
> > since the updated driver
> >
> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> > 255.255.255.255 port 67 interval 6
> > Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
> > bytes received 332.
> > Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data
> > after udp payload.
> > Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
> > 255.255.255.255 port 67
> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with
> > bytes received 332.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Try this patch. It should fix the issue. It seems Jack forgot to
> strip CRC bytes as old em(4) didn't strip it, probably to
> workaround silicon bug of old em(4) controllers.
>
>
Actually it did strip it, but its buried in the code in an obscure way,
that's
what I just realized by looking at the old code. having the hardware strip
will be easier I think.
> It seems there are also TX issues here. The system load is too high
> and sometimes system is not responsive while TX is in progress.
> Because I initiated TCP bulk transfers, TSO should reduce CPU load
> a lot but it didn't so I guess it could also be related watchdog
> timeouts you've seen. I'll see what can be done.
>
Will look at that as well.
Thanks!
Jack
------------------------------
Message: 15
Date: Thu, 8 Apr 2010 11:27:10 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org
Message-ID:
<s2h2a41acea1004081127qa...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
You know, I'm wondering if the so-called ALTQ fix, which makes the TX
start always queue is causing the problem on that side?
Jack
On Thu, Apr 8, 2010 at 11:22 AM, Jack Vogel <jfv...@gmail.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
>
>> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
>> >
>> > OK, some more data... It seems dhclient is getting upset as well
>> > since the updated driver
>> >
>> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
>> > 255.255.255.255 port 67 interval 6
>> > Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
>> > bytes received 332.
>> > Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data
>> > after udp payload.
>> > Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
>> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
>> > 255.255.255.255 port 67
>> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with
>> > bytes received 332.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Try this patch. It should fix the issue. It seems Jack forgot to
>> strip CRC bytes as old em(4) didn't strip it, probably to
>> workaround silicon bug of old em(4) controllers.
>>
>>
> Actually it did strip it, but its buried in the code in an obscure way,
> that's
> what I just realized by looking at the old code. having the hardware strip
> will be easier I think.
>
>
>> It seems there are also TX issues here. The system load is too high
>> and sometimes system is not responsive while TX is in progress.
>> Because I initiated TCP bulk transfers, TSO should reduce CPU load
>> a lot but it didn't so I guess it could also be related watchdog
>> timeouts you've seen. I'll see what can be done.
>>
>
> Will look at that as well.
>
> Thanks!
>
> Jack
>
>
------------------------------
Message: 16
Date: Thu, 08 Apr 2010 14:31:18 -0400
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: em driver regression
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org, jfv...@gmail.com
Message-ID: <201004081831....@lava.sentex.ca>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
>Try this patch. It should fix the issue. It seems Jack forgot to
>strip CRC bytes as old em(4) didn't strip it, probably to
>workaround silicon bug of old em(4) controllers.
Thanks! The attached patch does indeed fix the dhclient issue.
>It seems there are also TX issues here. The system load is too high
>and sometimes system is not responsive while TX is in progress.
>Because I initiated TCP bulk transfers, TSO should reduce CPU load
>a lot but it didn't so I guess it could also be related watchdog
>timeouts you've seen. I'll see what can be done.
Thanks for looking into that as well!!
---Mike
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
------------------------------
Message: 17
Date: Thu, 8 Apr 2010 11:36:05 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: Mike Tancsa <mi...@sentex.net>
Cc: pyu...@gmail.com, freebsd...@freebsd.org
Message-ID:
<k2o2a41acea1004081136gb...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Bigger question is will it fix Brandon's VirtualBox issue??
Jack
On Thu, Apr 8, 2010 at 11:31 AM, Mike Tancsa <mi...@sentex.net> wrote:
> At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
>
> Try this patch. It should fix the issue. It seems Jack forgot to
>> strip CRC bytes as old em(4) didn't strip it, probably to
>> workaround silicon bug of old em(4) controllers.
>>
>
> Thanks! The attached patch does indeed fix the dhclient issue.
>
>
>
> It seems there are also TX issues here. The system load is too high
>> and sometimes system is not responsive while TX is in progress.
>> Because I initiated TCP bulk transfers, TSO should reduce CPU load
>> a lot but it didn't so I guess it could also be related watchdog
>> timeouts you've seen. I'll see what can be done.
>>
>
> Thanks for looking into that as well!!
>
>
> ---Mike
>
>
>
>
> --------------------------------------------------------------------
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, mi...@sentex.net
> Providing Internet since 1994 www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
>
------------------------------
Message: 18
Date: Thu, 8 Apr 2010 11:39:00 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: em driver regression
To: Jack Vogel <jfv...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <2010040818...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote:
> You know, I'm wondering if the so-called ALTQ fix, which makes the TX
> start always queue is causing the problem on that side?
>
I'm not sure because I didn't configure ALTQ so it might be NOP for
non-ALTQ case.
> Jack
>
>
> On Thu, Apr 8, 2010 at 11:22 AM, Jack Vogel <jfv...@gmail.com> wrote:
>
> >
> >
> > On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> >
> >> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
> >> >
> >> > OK, some more data... It seems dhclient is getting upset as well
> >> > since the updated driver
> >> >
> >> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> >> > 255.255.255.255 port 67 interval 6
> >> > Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
> >> > bytes received 332.
> >> > Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data
> >> > after udp payload.
> >> > Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
> >> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
> >> > 255.255.255.255 port 67
> >> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with
> >> > bytes received 332.
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>
> >> Try this patch. It should fix the issue. It seems Jack forgot to
> >> strip CRC bytes as old em(4) didn't strip it, probably to
> >> workaround silicon bug of old em(4) controllers.
> >>
> >>
> > Actually it did strip it, but its buried in the code in an obscure way,
> > that's
> > what I just realized by looking at the old code. having the hardware strip
> > will be easier I think.
> >
> >
> >> It seems there are also TX issues here. The system load is too high
> >> and sometimes system is not responsive while TX is in progress.
> >> Because I initiated TCP bulk transfers, TSO should reduce CPU load
> >> a lot but it didn't so I guess it could also be related watchdog
> >> timeouts you've seen. I'll see what can be done.
> >>
> >
> > Will look at that as well.
> >
> > Thanks!
> >
> > Jack
> >
> >
------------------------------
End of freebsd-stable Digest, Vol 351, Issue 7
**********************************************