Re: Crashes on X7SPE-HF with em
Philipp Wuensche wrote:
>
> It just now started running the kernel without IPSEC and ALTQ.
Here we go again, this time it crashed with IPSEC and ALTQ disabled,
crashdump looks different this time though.
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x80400bc58038
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808a41ae
stack pointer = 0x28:0xff8e69a0
frame pointer = 0x28:0xff8e69b0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (em1 taskq)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 23h30m3s
Physical memory: 4079 MB
Dumping 1907 MB: 1892 1876em1: Watchdog timeout -- resetting
1860 1844 1828 1812 1796 1780 1764 1748 1732 1716 1700 1684 1668 1652
1636 1620 1604 1588 1572 1556 1540 1524 1508 1492 1476 1460 1444 1428
1412 1396 1380 1364 1348 1332 1316 1300 1284 1268 1252 1236 1220 1204
1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964
948 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676
660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388
372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100
84 68 52 36 20 4
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from
/boot/kernel/geom_stripe.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_stripe.ko
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from
/boot/kernel/coretemp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/ahci.ko...Reading symbols from
/boot/kernel/ahci.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ahci.ko
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from
/boot/kernel/ipmi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipmi.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from
/boot/kernel/smbus.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
#0 doadump () at pcpu.h:224
224 __asm("movq %%gs:0,%0" : "=r" (td));
(kgdb) list *0x808a41ae
0x808a41ae is in pmap_kextract
(/usr/src/sys/amd64/amd64/pmap.c:1172).
1167vm_paddr_t pa;
1168
1169if (va >= DMAP_MIN_ADDRESS && va < DMAP_MAX_ADDRESS) {
1170pa = DMAP_TO_PHYS(va);
1171} else {
1172pde = *vtopde(va);
1173if (pde & PG_PS) {
1174pa = (pde & PG_PS_FRAME) | (va & PDRMASK);
1175} else {
1176/*
(kgdb) backtrace
#0 doadump () at pcpu.h:224
#1 0x805b2b5e in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:416
#2 0x805b2f6c in panic (fmt=0x0)
at /usr/src/sys/kern/kern_shutdown.c:590
#3 0x808ac70d in trap_fatal (frame=0x80c5cc60,
eva=Variable "eva" is not available.
)
at /usr/src/sys/amd64/amd64/trap.c:777
#4 0x808acacf in trap_pfault (frame=0xff8e68f0, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:693
#5 0x808ad2e2 in trap (frame=0xff8e68f0)
at /usr/src/sys/amd64/amd64/trap.c:451
#6 0x808923b4 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:224
#7 0x808a41ae in pmap_kextract (va=51771551252551)
at /usr/src/sys/amd64/amd64/pmap.c:1172
#8 0x80890f83 in bus_dmamap_load_mbuf_sg (dmat=0xff0002727c00,
map=0x80c99d40, m0=Variable "m0" is not available.
)
at /usr/src/sys/amd64/amd64/busdma_machdep.c:659
#9 0x8032f8fc in em_refresh_mbufs (rxr=0xff0002712600,
limit=975)
at /usr/src/sys/dev/e1000/if_em.c:3691
#10 0x8032ff3c in em_
Re: 8.1-PRERELEASE: CPU packages not detected correctly
Oops, the patch had a small mistake. I've put it here now, just in case I'll want to fix/cleanup anything else: http://people.freebsd.org/~avg/intel-cpu-topo.diff on 28/08/2010 23:22 Andriy Gapon said the following: > So, here is my take on the problem. > The attached patch is against sources in FreeBSD tree, it should be applied > either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > on the desired architecture. > > The patch is substantially based on the Junk-uk's patch, but with some changes > and additions: > - topo_probo_0x4() is rewritten so that it does APIC ID matching against masks > as described in the Intel article. The code still heavily depends on the > assumption of the uniform topology, it discovers number of cores in BSP > package > and number of threads in BSP core and extrapolates that to global topology. > The difference with current code and Junk-uk's patch is that actual APIC ID > matching is done as opposed to deriving counts purely from max. values. > > - added a few comments that describe uniformity assumption, plus couple other > useful things. > > - changed "final fallback" code, so that each logical CPU is considered to be > in > its own physical package as opposed to current code placing all logical CPUs > as > cores of a single package. > > The rest is Junk-uk's work. > > Concerns: > - about my code: ilog2_round_pow2 name is ugly; looking for suggestions on a > better name or re-arranging/writing that code, so that the function is not > needed. > - about current code: logical_cpus variable (don't confuse with cpu_logical) > doesn't seem to be consistently used; e.g. it is not set at all by > topo_probo_0xb(); also, the method of using it for setting logical_cpus_mask > doesn't seem to be reliable - BSP may be missed. > > Reviews, comments and test reports are very welcome! > Please test the patch if you have any problems with how CPU topology is > reported > by the current code. Please test even if everything is OK, to avoid > regressions. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
on 28/08/2010 01:02 Andriy Gapon said the following:
> BTW, it may be not that hard.
> It seems that 0x4 topology building involves knowing the masks and we already
> have that data (just interpreted differently), and APIC IDs of the CPUs and it
> seems that we also have that. We don't need to bind to CPUs to learn their
> IDs,
> we can just iterate over cpu_apic_ids[].
>
> The only problem is that currently topo_probe() is called before
> assign_cpu_ids() which populates cpu_apic_ids.
> assign_cpu_ids depends on topo_probe to know hyperthreading_cpus value.
> So, either cpu_apic_ids could be split out or alternatively we could use
> cpu_info[] similarly to how it's done in topo_probe_0xb (skipping !cpu_present
> and cpu_disabled entries).
So, here is my take on the problem.
The attached patch is against sources in FreeBSD tree, it should be applied
either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending
on the desired architecture.
The patch is substantially based on the Junk-uk's patch, but with some changes
and additions:
- topo_probo_0x4() is rewritten so that it does APIC ID matching against masks
as described in the Intel article. The code still heavily depends on the
assumption of the uniform topology, it discovers number of cores in BSP package
and number of threads in BSP core and extrapolates that to global topology.
The difference with current code and Junk-uk's patch is that actual APIC ID
matching is done as opposed to deriving counts purely from max. values.
- added a few comments that describe uniformity assumption, plus couple other
useful things.
- changed "final fallback" code, so that each logical CPU is considered to be in
its own physical package as opposed to current code placing all logical CPUs as
cores of a single package.
The rest is Junk-uk's work.
Concerns:
- about my code: ilog2_round_pow2 name is ugly; looking for suggestions on a
better name or re-arranging/writing that code, so that the function is not
needed.
- about current code: logical_cpus variable (don't confuse with cpu_logical)
doesn't seem to be consistently used; e.g. it is not set at all by
topo_probo_0xb(); also, the method of using it for setting logical_cpus_mask
doesn't seem to be reliable - BSP may be missed.
Reviews, comments and test reports are very welcome!
Please test the patch if you have any problems with how CPU topology is reported
by the current code. Please test even if everything is OK, to avoid
regressions.
Thanks!
--
Andriy Gapon
diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index e2f82ec..47a5c0b 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -177,24 +177,101 @@ mem_range_AP_init(void)
}
static void
+topo_probe_amd(void)
+{
+
+ /* AMD processors do not support HTT. */
+ cpu_cores = (amd_feature2 & AMDID2_CMP) != 0 ?
+ (cpu_procinfo2 & AMDID_CMP_CORES) + 1 : 1;
+ cpu_logical = 1;
+}
+
+/*
+ * Round up to the next power of two, if necessary, and then
+ * take log2.
+ */
+static __inline int
+ilog2_round_pow2(u_int x)
+{
+
+ return fls(x << (1 - powerof2(x)));
+}
+
+static void
+topo_probe_0x4(void)
+{
+ u_int p[4];
+ int core_id_bits;
+ int smt_id_bits;
+ int max_cores;
+ int max_logical;
+ int id;
+
+ max_logical = (cpu_feature & CPUID_HTT) != 0 ?
+ (cpu_procinfo & CPUID_HTT_CORES) >> 16 : 1;
+ if (max_logical == 1)
+ return;
+
+ /*
+* Because of uniformity assumption we examine only
+* those logical processors that belong to the same
+* package as BSP. Further, we count number of
+* logical processors that belong to the same core
+* as BSP thus deducing number of threads per core.
+*/
+ cpuid_count(0x04, 0, p);
+ max_cores = ((p[0] >> 26) & 0x3f) + 1;
+ smt_id_bits = ilog2_round_pow2(max_logical/max_cores) - 1;
+ if (smt_id_bits < 0)
+ return;
+ core_id_bits = smt_id_bits + fls(max_cores) - 1;
+
+ for (id = 0; id <= MAX_APIC_ID; id++) {
+ if (!cpu_info[id].cpu_present || cpu_info[id].cpu_disabled)
+ continue;
+ if ((id >> core_id_bits) != (boot_cpu_id >> core_id_bits))
+ continue;
+ cpu_cores++;
+ if ((id >> smt_id_bits) == (boot_cpu_id >> smt_id_bits))
+ cpu_logical++;
+ }
+
+ cpu_cores /= cpu_logical;
+ if (cpu_logical > 1)
+ hyperthreading_cpus = logical_cpus = cpu_logical;
+}
+
+static void
topo_probe_0xb(void)
{
- int logical;
- int p[4];
+ u_int p[4];
int bits;
- int type;
int cnt;
int i;
+ int logical;
+ int type;
int x;
- /* We only support two levels for now. */
+ /* We only support three levels for now. */
for (i = 0; i < 3; i++) {
-
ACPI Warning: Optional field Pm2ControlBlock has zero address
This this something to be concerned about: ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x/0x1 (20100331/tbfadt-655) -- Dan Langille - http://langille.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ACPI Warning: Optional field Pm2ControlBlock has zero address
On Sat, Aug 28, 2010 at 04:35:58PM -0400, Dan Langille wrote: > This this something to be concerned about: > > ACPI Warning: Optional field Pm2ControlBlock has zero address or > length: 0x/0x1 (20100331/tbfadt-655) CC'ing freebsd-acpi. OS version is unknown. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ACPI Warning: Optional field Pm2ControlBlock has zero address
On 8/28/2010 8:30 PM, Jeremy Chadwick wrote: On Sat, Aug 28, 2010 at 04:35:58PM -0400, Dan Langille wrote: This this something to be concerned about: ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x/0x1 (20100331/tbfadt-655) CC'ing freebsd-acpi. OS version is unknown. FreeBSD-Stable 8.1 -- Dan Langille - http://langille.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why is NFSv4 so slow?
Hi. I'm still having problems with NFSv4 being very laggy on one client. When the NFSv4 server is at 50% idle CPU and the disks are < 1% busy, I am getting horrible throughput on an idle client. Using dd(1) with 1 MB block size, when I try to read a > 100 MB file from the client, I'm getting around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s with the same test (on a different file). On the broken client: # uname -mv FreeBSD 8.1-STABLE #5 r211534M: Sat Aug 28 15:53:10 CDT 2010 u...@example.com:/usr/obj/usr/src/sys/GENERIC i386 # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:e0:4c:xx:yy:zz inet xx.yy.zz.3 netmask 0xff00 broadcast xx.yy.zz.255 media: Ethernet autoselect (1000baseT ) status: active # netstat -m 267/768/1035 mbufs in use (current/cache/total) 263/389/652/25600 mbuf clusters in use (current/cache/total/max) 263/377 mbuf+clusters out of packet secondary zone in use (current/cache) 0/20/20/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 592K/1050K/1642K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines # netstat -idn NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll Drop re01500 00:e0:4c:xx:yy:zz 232135 0 068984 0 00 re01500 xx.yy.zz.0/2 xx.yy.zz.3 232127 - -68979 - -- nfe0* 1500 00:22:15:xx:yy:zz0 0 00 0 00 plip0 15000 0 00 0 00 lo0 16384 42 0 0 42 0 00 lo0 16384 fe80:4::1/64 fe80:4::10 - -0 - -- lo0 16384 ::1/128 ::1 0 - -0 - -- lo0 16384 127.0.0.0/8 127.0.0.1 42 - - 42 - -- # sysctl kern.ipc.maxsockbuf kern.ipc.maxsockbuf: 1048576 # sysctl net.inet.tcp.sendbuf_max net.inet.tcp.sendbuf_max: 16777216 # sysctl net.inet.tcp.recvbuf_max net.inet.tcp.recvbuf_max: 16777216 # sysctl net.inet.tcp.sendspace net.inet.tcp.sendspace: 65536 # sysctl net.inet.tcp.recvspace net.inet.tcp.recvspace: 131072 # sysctl hw.pci | grep msi hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 # vmstat -i interrupt total rate irq14: ata0 47 0 irq16: re0219278191 irq21: ohci0+ 5939 5 irq22: vgapci0+77990 67 cpu0: timer 2294451 1998 irq256: hdac0 44069 38 cpu1: timer 2293983 1998 Total4935757 4299 Any ideas? -- Rick C. Petty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
