patch for topology detection of Intel CPUs
[Reposted from stable@; edited] The below 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: http://people.freebsd.org/~avg/intel-cpu-topo.diff The patch is substantially based on the Junk-uk's patch, but with some changes and additions: - topo_prob_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. - topo_prob_0x4() is invoked for 1 = cpu_high 4 case as well as for 4 = cpu_high 11 case as done in the current code, but unlike Junk-uk's patch. The code should be able to properly handle that class of CPUs and either detect hyperthreading topology or fallback to one processor per package topology. - 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 ___ 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
syncache errors
After upgrading to a recent STABLE, I have been seeing the following sporadic errors Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: Socket create failed due to limits or memory shortage this is with FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 and the previous kernel was from July 20th. The odd thing is that the error is triggered from a RELENG_6 host only it would seem. I noticed there are a number of syncache and tcp updates to RELENG_8, is it possible this is related ? I dont have any specific tweaks in /etc/sysctl.conf other than net.inet.tcp.log_in_vain: 1 net.inet.udp.log_in_vain: 1 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: Since other client(s) are working well, that seems to suggest that it is a network related problem and not a bug in the NFS code. First off, the obvious question: How does this client differ from the one that performs much better? Do they both use the same re network interface for the NFS traffic? (If the answer is no, I'd be suspicious that the re hardware or device driver is the culprit.) Things that I might try in an effort to isolate the problem: - switch the NFS traffic to use the nfe0 net interface. - put a net interface identical to the one on the client that works well in the machine and use that for the NFS traffic. - turn off TXCSUM and RXCSUM on re0 - reduce the read/write data size, using rsize=N,wsize=N on the mount. (It will default to MAXBSIZE and some net interfaces don't handle large bursts of received data well. If you drop it to rsize=8192,wszie=8192 and things improve, then increase N until it screws up.) - check the port configuration on the switch end, to make sure it is also 1000bps-full duplex. - move the client to a different net port on the switch or even a different switch (and change the cable, while you're at it). - Look at netstat -s and see if there are a lot of retransmits going on in TCP. If none of the above seems to help, you could look at a packet trace and see what is going on. Look for TCP reconnects (SYN, SYN-ACK...) or places where there is a large time delay/retransmit of a TCP segment. Hopefully others who are more familiar with the networking side can suggest other things to try, rick ___ 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: syncache errors
On 29.08.2010 16:09, Mike Tancsa wrote: After upgrading to a recent STABLE, I have been seeing the following sporadic errors Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: Socket create failed due to limits or memory shortage this is with FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 and the previous kernel was from July 20th. The odd thing is that the error is triggered from a RELENG_6 host only it would seem. I noticed there are a number of syncache and tcp updates to RELENG_8, is it possible this is related ? I dont have any specific tweaks in /etc/sysctl.conf other than net.inet.tcp.log_in_vain: 1 net.inet.udp.log_in_vain: 1 The log_in_vain sysctl would cause the logging of syncache errors as well (net.inet.tcp.log_debug). This was a POLA violation and I've separated them on August 27 on 8-stable. So if you update you won't see them anymore. That doesn't change the fact that the socket create failed though. If it only happens from a RELENG_6 box it probably is a problem with port re-usage by RELENG_6. The difficulty is that sonewconn() fails and doesn't return an error code. Hence it may be one of listen queue limits reached, memory shortage or a problem with inserting the inpcb into the hash lists. -- Andre ___ 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: syncache errors
At 11:33 AM 8/29/2010, Andre Oppermann wrote: On 29.08.2010 16:09, Mike Tancsa wrote: After upgrading to a recent STABLE, I have been seeing the following sporadic errors Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: Socket create failed due to limits or memory shortage this is with FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 and the previous kernel was from July 20th. The odd thing is that the error is triggered from a RELENG_6 host only it would seem. I noticed there are a number of syncache and tcp updates to RELENG_8, is it possible this is related ? I dont have any specific tweaks in /etc/sysctl.conf other than net.inet.tcp.log_in_vain: 1 net.inet.udp.log_in_vain: 1 The log_in_vain sysctl would cause the logging of syncache errors as well (net.inet.tcp.log_debug). This was a POLA violation and I've separated them on August 27 on 8-stable. So if you update you won't see them anymore. That doesn't change the fact that the socket create failed though. If it only happens from a RELENG_6 box it probably is a problem with port re-usage by RELENG_6. The difficulty is that sonewconn() fails and doesn't return an error code. Hence it may be one of listen queue limits reached, memory shortage or a problem with inserting the inpcb into the hash lists. Actually, I think I might have found the issue. I was focusing on the memory part not the limits. The 'RELENG_6 only' is just a fluke as thats a box that sends a lot of email to this particular server. It turns out, sendmail was rate limiting the server sm-mta[25923]: deferring connections on daemon IPv4: 8 per second and somehow syncache is aware/logs this now where as it did not before ? ---Mike -- Andre Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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
igb related(?) panics on 7.3-STABLE
I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, with two igb nics in use. Previously the machine was fine, running earlier versions of 7-STABLE, although the load on the network has increased due to additional machines being added to the network (the machine functions as a fileserver, serving files to compute machines via NFS(v3)). Any advice is much appreciated. System info is below. -greg Machine: === FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 r...@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 Kernel was csup'd earlier in the day on 25 August, immediately prior to the build. Panic: == Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0x8052f40c stack pointer = 0x10:0xff82056819d0 frame pointer = 0x10:0xff82056819f0 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 = 65 (igb1 que) trap number = 9 panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x294 trap() at trap+0x106 calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8052f40c, rsp = 0xff82056819d0, rbp = 0xff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c uma_zfree_arg() at uma_zfree_arg+0x41 m_freem() at m_freem+0x54 ether_demux() at ether_demux+0x85 ether_input() at ether_input+0x1bb igb_rxeof() at igb_rxeof+0x29d igb_handle_que() at igb_handle_que+0x9a taskqueue_run() at taskqueue_run+0xac taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x122 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8205681d30, rbp = 0 --- Uptime: 11h57m6s Physical memory: 18411 MB Dumping 3770 MB: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x80 fault code = supervisor write data, page not present instruction pointer = 0x8:0x80188b5f stack pointer = 0x10:0xff82056811f0 frame pointer = 0x10:0xff82056812f0 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 = 65 (igb1 que) trap number = 12 pciconf: === i...@pci0:10:0:0: class=0x02 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet i...@pci0:10:0:1: class=0x02 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet dmesg: = igb0: Intel(R) PRO/1000 Network Connection version - 1.9.5 port 0xe880-0xe89f mem 0xfbe6-0xfbe 7,0xfbe4-0xfbe5,0xfbeb8000-0xfbebbfff irq 16 at device 0.0 on pci10 igb0: Using MSIX interrupts with 10 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:30:48:ca:cd:72 igb1: Intel(R) PRO/1000 Network Connection version - 1.9.5 port 0xec00-0xec1f mem 0xfbee-0xfbe f,0xfbec-0xfbed,0xfbebc000-0xfbeb irq 17 at device 0.1 on pci10 igb1: Using MSIX interrupts with 10 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:30:48:ca:cd:73 -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: syncache errors
On 29.08.2010 19:16, Mike Tancsa wrote: At 11:33 AM 8/29/2010, Andre Oppermann wrote: On 29.08.2010 16:09, Mike Tancsa wrote: After upgrading to a recent STABLE, I have been seeing the following sporadic errors Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: Socket create failed due to limits or memory shortage this is with FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 and the previous kernel was from July 20th. The odd thing is that the error is triggered from a RELENG_6 host only it would seem. I noticed there are a number of syncache and tcp updates to RELENG_8, is it possible this is related ? I dont have any specific tweaks in /etc/sysctl.conf other than net.inet.tcp.log_in_vain: 1 net.inet.udp.log_in_vain: 1 The log_in_vain sysctl would cause the logging of syncache errors as well (net.inet.tcp.log_debug). This was a POLA violation and I've separated them on August 27 on 8-stable. So if you update you won't see them anymore. That doesn't change the fact that the socket create failed though. If it only happens from a RELENG_6 box it probably is a problem with port re-usage by RELENG_6. The difficulty is that sonewconn() fails and doesn't return an error code. Hence it may be one of listen queue limits reached, memory shortage or a problem with inserting the inpcb into the hash lists. Actually, I think I might have found the issue. I was focusing on the memory part not the limits. The 'RELENG_6 only' is just a fluke as thats a box that sends a lot of email to this particular server. It turns out, sendmail was rate limiting the server sm-mta[25923]: deferring connections on daemon IPv4: 8 per second and somehow syncache is aware/logs this now where as it did not before ? When sendmail is deferring the connections it should not show up in the syncache logs. The accept() by sendmail is much later than when the socket for a new connection is created in syncache. Here it points to the limits in the listen queue. Maybe sendmail is getting behind in accepting new connections and the listen queue is overflowing. -- Andre ___ 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
Broadcom 4315 not working
Hi. WiFi BCM4315 not working. Please help me. --- = 1 --- # uname -a FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r211965: Sun Aug 29 22:18:05 MSD 2010 root@:/usr/obj/usr/src/sys/GENERIC i386 # cd /usr/src/sys/modules/siba_bwn make make install # cat /boot/loader.conf if_bwn_load=YES # pciconf -lvbc siba_b...@pci0:3:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' class = network bar [10] = type Memory, range 64, base 0xd420, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) # reboot # kldstat Id Refs AddressSize Name 18 0xc040 bc14f4 kernel 21 0xc0fc2000 37248if_bwn.ko 32 0xc0ffa000 a1dc siba_bwn.ko # ifconfig bwn0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier --- = 2 --- # kldload bwn_v4_lp_ucode.ko # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 up # ifconfig bwn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ... wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid channel 4 (2427 MHz 11g) country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 in series ifconfig can see: ... channel 4 (2427 MHz 11g) ... ... channel 5 (2432 MHz 11g) ... ... channel 9 (2452 MHz 11g) ... ... channel 12 (2467 MHz 11g) ... ... channel 14 (2484 MHz 11g) ... ... channel 1 (2412 MHz 11g) ... ... # cat /var/log/messages Aug 30 00:11:19 kernel: wlan0: Ethernet address: 0c:ee:e6:a1:50:cc Aug 30 00:11:41 kernel: bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) Aug 30 00:11:42 kernel: wlan0: ieee80211_new_state_locked: pending INIT - SCAN transition lost Aug 30 00:12:09 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:09 kernel: bwn0: please turns on the RF switch Aug 30 00:12:10 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:17 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:17 kernel: bwn0: please turns on the RF switch Aug 30 00:12:19 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:21 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:21 kernel: bwn0: please turns on the RF switch Aug 30 00:12:25 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:33 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:33 kernel: bwn0: please turns on the RF switch Aug 30 00:12:34 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:35 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:35 kernel: bwn0: please turns on the RF switch Aug 30 00:12:36 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:13:49 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:13:49 kernel: bwn0: please turns on the RF switch Aug 30 00:13:50 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:14:39 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:14:39 kernel: bwn0: please turns on the RF switch Aug 30 00:14:40 kernel: bwn0: status of RF switch is changed to ON ___ 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: syncache errors
At 03:10 PM 8/29/2010, Andre Oppermann wrote: On 29.08.2010 19:16, Mike Tancsa wrote: At 11:33 AM 8/29/2010, Andre Oppermann wrote: On 29.08.2010 16:09, Mike Tancsa wrote: After upgrading to a recent STABLE, I have been seeing the following sporadic errors Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: Socket create failed due to limits or memory shortage this is with FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 and the previous kernel was from July 20th. When sendmail is deferring the connections it should not show up in the syncache logs. The accept() by sendmail is much later than when the socket for a new connection is created in syncache. Here it points to the limits in the listen queue. Maybe sendmail is getting behind in accepting new connections and the listen queue is overflowing. How would I track that down to confirm it ? ---Mike ___ 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: Crashes on X7SPE-HF with em
On Sat, Aug 28, 2010 at 04:19:07PM +0200, Philipp Wuensche wrote:
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).
1167 vm_paddr_t pa;
1168
1169 if (va = DMAP_MIN_ADDRESS va DMAP_MAX_ADDRESS) {
1170 pa = DMAP_TO_PHYS(va);
1171 } else {
1172 pde = *vtopde(va);
1173 if (pde PG_PS) {
1174 pa = (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
hwpmc(4) driver / compiler warnings
I have received the following warnings about enumerated values for enum pmc_event on stable/8 i386. I am not sure how long this has been going on because I do not really use the PMC, therefore its not built into the kernel. This is just a heads up because though this warning has no effect on my machines it may in other area's. WARNING: hwpmc_amd.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_core.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_intel.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_logging.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_mod.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_pentium.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_piv.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_ppro.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_tsc.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_uncore.c: enum pmc_event has too many values: 1121 1023 WARNING: hwpmc_x86.c: enum pmc_event has too many values: 1121 1023 Regards, -- jhell,v ___ 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
