igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
I have 3 boxes, each with two nics. One nic for the private network and one for the public network. The private network is all on the same vlan. All 6 nics are on the same switch. All connections are 1000tx Full Duplex. I will call the servers Box A, Box B, and Box C. When i FTP data between Box A B i get abou 25MB/sec. When i FTP data from Box C to Box A or B, i get about 20MB/sec. When i FTP data from Box A to C i get 10MB/sec When i FTP data from Box B to C i get 200KB/sec... Can anyone suggest why i might only be getting 200KB when transfering data from Box B to C but not when transferring data from Box A to C? I tried installing ubuntu to see if the problem was still there and it is not. I can FTP data from Box A or B to box C at 10MB/sec, still not the gigabit speeds i should be seeing but not the 200KB/sec i am getting with freebsd. I logged into my switch and it reports that the ports are 1000tx full duplex, the same as what freebsd is reporting. The switch freebsd also report no errors. I really dont know what to do. Nothing anywhere reports showing a problem but obviously there is a problem somewhere. I've tried drivers 1.9.5, 1.8.4, and 1.7.3. If i use 1.8.4 or 1.7.3 i get 50KB/sec transferring data from box B whereas if i use 1.9.5 i get 200-300KB sec. I should be getting like 50MB/sec ;( Any help would be grateful. Or, maybe someone could put me in touch with the person responsible for the intel nic drivers and i can work with them on resolving this issue? Thanks in advance. NameMtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll igb0 1500 Link#1 00:30:48:9f:11:0425853 0 0 18340 0 0 igb0 1500 216.105.91.14 216.105.91.145 19040 - - 18343 - - igb1* 1500 Link#2 00:30:48:9f:11:050 0 0 0 0 0 lo0 16384 Link#3 72 0 0 72 0 0 lo0 16384 127.0.0.0/8 127.0.0.1 72 - - 72 - - Sysctl info for igb0/1 dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.8.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x15d9 subdevice=0x0100 class=0x02 dev.igb.0.%parent: pci1 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.low_latency: 128 dev.igb.0.ave_latency: 450 dev.igb.0.bulk_latency: 1200 dev.igb.0.rx_processing_limit: 100 Debug info for igb0 May 8 09:17:57 debbie kernel: igb0: TX(1) Packets sent = 1295 May 8 09:17:57 debbie kernel: igb0: Queue(2) tdh = 106, tdt = 106 May 8 09:17:57 debbie kernel: igb0: TX(2) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(2) MSIX IRQ Handled = 5353 May 8 09:17:57 debbie kernel: igb0: TX(2) Packets sent = 5450 May 8 09:17:57 debbie kernel: igb0: Queue(3) tdh = 1687, tdt = 1687 May 8 09:17:57 debbie kernel: igb0: TX(3) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(3) MSIX IRQ Handled = 1335 May 8 09:17:57 debbie kernel: igb0: TX(3) Packets sent = 1354 May 8 09:17:57 debbie kernel: igb0: Queue(0) rdh = 425, rdt = 424 May 8 09:17:57 debbie kernel: igb0: RX(0) Packets received = 16809 May 8 09:17:57 debbie kernel: igb0: RX(0) Split Packets = 12262 May 8 09:17:57 debbie kernel: igb0: RX(0) Byte count = 25894129 May 8 09:17:57 debbie kernel: igb0: RX(0) MSIX IRQ Handled = 43428 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Queued= 13601 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Flushed= 9966 May 8 09:17:57 debbie kernel: igb0: Queue(1) rdh = 1700, rdt = 1699 May 8 09:17:57 debbie kernel: igb0: RX(1) Packets received = 1700 May 8 09:17:57 debbie kernel: igb0: RX(1) Split Packets = 937 May 8 09:17:57 debbie kernel: igb0: RX(1) Byte count = 1392691 May 8 09:17:57 debbie kernel: igb0: RX(1) MSIX IRQ Handled = 31888 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Queued= 1362 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Flushed= 1351 May 8 09:17:57 debbie kernel: igb0: Queue(2) rdh = 33, rdt = 32 May 8 09:17:57 debbie kernel: igb0: RX(2) Packets received = 6177 May 8 09:17:57 debbie kernel: igb0: RX(2) Split Packets = 1442 May 8 09:17:57 debbie kernel: igb0: RX(2) Byte count = 2518498 May 8 09:17:57 debbie kernel: igb0: RX(2) MSIX IRQ Handled = 36258 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Queued= 5794 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Flushed= 5673 May 8 09:17:57 debbie kernel: igb0: Queue(3) rdh = 1418, rdt = 1417 May 8 09:17:57 debbie kernel: igb0: RX(3) Packets received = 1418 May 8 09:17:57 debbie kernel: igb0: RX(3) Split Packets = 939 May 8 09:17:57 debbie kernel: igb0: RX(3) Byte count = 1700710 May 8 09:17:57 debbie kernel: igb0: RX(3) MSIX IRQ Handled = 31399 May 8 09:17:57 debbie kernel: igb0: RX(3) LRO Queued= 1102 May 8 09:17:57 debbie kernel: igb0: RX(3) LRO Flushed= 882 May 8
weekly whatis database and readonly /usr mount
Hello List, I've installed a testing system with readonly /usr filesystem. And I was surprised by following weekly report (BTW locate database rebuilded just fine): - Rebuilding whatis database: makewhatis: /usr/share/man/whatis.tmp: Read-only file system makewhatis: /usr/share/openssl/man/whatis.tmp: Read-only file system - Is there any reason for using /usr filesystem istead of /tmp, /var/tmp? -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On 05/08/2010 05:08 AM, joe wrote: I have 3 boxes, each with two nics. One nic for the private network and one for the public network. The private network is all on the same vlan. All 6 nics are on the same switch. All connections are 1000tx Full Duplex. I will call the servers Box A, Box B, and Box C. When i FTP data between Box A B i get abou 25MB/sec. When i FTP data from Box C to Box A or B, i get about 20MB/sec. When i FTP data from Box A to C i get 10MB/sec When i FTP data from Box B to C i get 200KB/sec... Can anyone suggest why i might only be getting 200KB when transfering data from Box B to C but not when transferring data from Box A to C? I tried installing ubuntu to see if the problem was still there and it is not. I can FTP data from Box A or B to box C at 10MB/sec, still not the gigabit speeds i should be seeing but not the 200KB/sec i am getting with freebsd. I logged into my switch and it reports that the ports are 1000tx full duplex, the same as what freebsd is reporting. The switch freebsd also report no errors. I really dont know what to do. Nothing anywhere reports showing a problem but obviously there is a problem somewhere. I've tried drivers 1.9.5, 1.8.4, and 1.7.3. If i use 1.8.4 or 1.7.3 i get 50KB/sec transferring data from box B whereas if i use 1.9.5 i get 200-300KB sec. I should be getting like 50MB/sec ;( Any help would be grateful. Or, maybe someone could put me in touch with the person responsible for the intel nic drivers and i can work with them on resolving this issue? Thanks in advance. NameMtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll igb0 1500 Link#1 00:30:48:9f:11:0425853 0 0 18340 0 0 igb0 1500 216.105.91.14 216.105.91.145 19040 - - 18343 - - igb1* 1500 Link#2 00:30:48:9f:11:050 0 00 0 0 lo0 16384 Link#3 72 0 0 72 0 0 lo0 16384 127.0.0.0/8 127.0.0.1 72 - - 72 - - Sysctl info for igb0/1 dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.8.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x15d9 subdevice=0x0100 class=0x02 dev.igb.0.%parent: pci1 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.low_latency: 128 dev.igb.0.ave_latency: 450 dev.igb.0.bulk_latency: 1200 dev.igb.0.rx_processing_limit: 100 Debug info for igb0 May 8 09:17:57 debbie kernel: igb0: TX(1) Packets sent = 1295 May 8 09:17:57 debbie kernel: igb0: Queue(2) tdh = 106, tdt = 106 May 8 09:17:57 debbie kernel: igb0: TX(2) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(2) MSIX IRQ Handled = 5353 May 8 09:17:57 debbie kernel: igb0: TX(2) Packets sent = 5450 May 8 09:17:57 debbie kernel: igb0: Queue(3) tdh = 1687, tdt = 1687 May 8 09:17:57 debbie kernel: igb0: TX(3) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(3) MSIX IRQ Handled = 1335 May 8 09:17:57 debbie kernel: igb0: TX(3) Packets sent = 1354 May 8 09:17:57 debbie kernel: igb0: Queue(0) rdh = 425, rdt = 424 May 8 09:17:57 debbie kernel: igb0: RX(0) Packets received = 16809 May 8 09:17:57 debbie kernel: igb0: RX(0) Split Packets = 12262 May 8 09:17:57 debbie kernel: igb0: RX(0) Byte count = 25894129 May 8 09:17:57 debbie kernel: igb0: RX(0) MSIX IRQ Handled = 43428 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Queued= 13601 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Flushed= 9966 May 8 09:17:57 debbie kernel: igb0: Queue(1) rdh = 1700, rdt = 1699 May 8 09:17:57 debbie kernel: igb0: RX(1) Packets received = 1700 May 8 09:17:57 debbie kernel: igb0: RX(1) Split Packets = 937 May 8 09:17:57 debbie kernel: igb0: RX(1) Byte count = 1392691 May 8 09:17:57 debbie kernel: igb0: RX(1) MSIX IRQ Handled = 31888 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Queued= 1362 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Flushed= 1351 May 8 09:17:57 debbie kernel: igb0: Queue(2) rdh = 33, rdt = 32 May 8 09:17:57 debbie kernel: igb0: RX(2) Packets received = 6177 May 8 09:17:57 debbie kernel: igb0: RX(2) Split Packets = 1442 May 8 09:17:57 debbie kernel: igb0: RX(2) Byte count = 2518498 May 8 09:17:57 debbie kernel: igb0: RX(2) MSIX IRQ Handled = 36258 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Queued= 5794 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Flushed= 5673 May 8 09:17:57 debbie kernel: igb0: Queue(3) rdh = 1418, rdt = 1417 May 8 09:17:57 debbie kernel: igb0: RX(3) Packets received = 1418 May 8 09:17:57 debbie kernel: igb0: RX(3) Split Packets = 939 May 8 09:17:57 debbie kernel: igb0: RX(3) Byte count = 1700710 May 8 09:17:57 debbie kernel: igb0: RX(3) MSIX IRQ Handled = 31399 May 8 09:17:57 debbie kernel: igb0: RX(3) LRO Queued= 1102 May 8 09:17:57 debbie kernel: igb0:
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On 05/08/2010 05:54 AM, Fabien Thomas wrote: Have you tried to disable TSO / LRO? Fabien I have 3 boxes, each with two nics. One nic for the private network and one for the public network. The private network is all on the same vlan. All 6 nics are on the same switch. All connections are 1000tx Full Duplex. I will call the servers Box A, Box B, and Box C. When i FTP data between Box A B i get abou 25MB/sec. When i FTP data from Box C to Box A or B, i get about 20MB/sec. When i FTP data from Box A to C i get 10MB/sec When i FTP data from Box B to C i get 200KB/sec... Can anyone suggest why i might only be getting 200KB when transfering data from Box B to C but not when transferring data from Box A to C? I tried installing ubuntu to see if the problem was still there and it is not. I can FTP data from Box A or B to box C at 10MB/sec, still not the gigabit speeds i should be seeing but not the 200KB/sec i am getting with freebsd. I logged into my switch and it reports that the ports are 1000tx full duplex, the same as what freebsd is reporting. The switch freebsd also report no errors. I really dont know what to do. Nothing anywhere reports showing a problem but obviously there is a problem somewhere. I've tried drivers 1.9.5, 1.8.4, and 1.7.3. If i use 1.8.4 or 1.7.3 i get 50KB/sec transferring data from box B whereas if i use 1.9.5 i get 200-300KB sec. I should be getting like 50MB/sec ;( Any help would be grateful. Or, maybe someone could put me in touch with the person responsible for the intel nic drivers and i can work with them on resolving this issue? Thanks in advance. NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll igb0 1500Link#1 00:30:48:9f:11:0425853 0 018340 0 0 igb0 1500 216.105.91.14 216.105.91.145 19040 - -18343 - - igb1* 1500Link#2 00:30:48:9f:11:050 0 00 0 0 lo0 16384Link#3 72 0 0 72 0 0 lo0 16384 127.0.0.0/8 127.0.0.1 72 - - 72 - - Sysctl info for igb0/1 dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.8.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x15d9 subdevice=0x0100 class=0x02 dev.igb.0.%parent: pci1 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.low_latency: 128 dev.igb.0.ave_latency: 450 dev.igb.0.bulk_latency: 1200 dev.igb.0.rx_processing_limit: 100 Debug info for igb0 May 8 09:17:57 debbie kernel: igb0: TX(1) Packets sent = 1295 May 8 09:17:57 debbie kernel: igb0: Queue(2) tdh = 106, tdt = 106 May 8 09:17:57 debbie kernel: igb0: TX(2) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(2) MSIX IRQ Handled = 5353 May 8 09:17:57 debbie kernel: igb0: TX(2) Packets sent = 5450 May 8 09:17:57 debbie kernel: igb0: Queue(3) tdh = 1687, tdt = 1687 May 8 09:17:57 debbie kernel: igb0: TX(3) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(3) MSIX IRQ Handled = 1335 May 8 09:17:57 debbie kernel: igb0: TX(3) Packets sent = 1354 May 8 09:17:57 debbie kernel: igb0: Queue(0) rdh = 425, rdt = 424 May 8 09:17:57 debbie kernel: igb0: RX(0) Packets received = 16809 May 8 09:17:57 debbie kernel: igb0: RX(0) Split Packets = 12262 May 8 09:17:57 debbie kernel: igb0: RX(0) Byte count = 25894129 May 8 09:17:57 debbie kernel: igb0: RX(0) MSIX IRQ Handled = 43428 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Queued= 13601 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Flushed= 9966 May 8 09:17:57 debbie kernel: igb0: Queue(1) rdh = 1700, rdt = 1699 May 8 09:17:57 debbie kernel: igb0: RX(1) Packets received = 1700 May 8 09:17:57 debbie kernel: igb0: RX(1) Split Packets = 937 May 8 09:17:57 debbie kernel: igb0: RX(1) Byte count = 1392691 May 8 09:17:57 debbie kernel: igb0: RX(1) MSIX IRQ Handled = 31888 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Queued= 1362 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Flushed= 1351 May 8 09:17:57 debbie kernel: igb0: Queue(2) rdh = 33, rdt = 32 May 8 09:17:57 debbie kernel: igb0: RX(2) Packets received = 6177 May 8 09:17:57 debbie kernel: igb0: RX(2) Split Packets = 1442 May 8 09:17:57 debbie kernel: igb0: RX(2) Byte count = 2518498 May 8 09:17:57 debbie kernel: igb0: RX(2) MSIX IRQ Handled = 36258 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Queued= 5794 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Flushed= 5673 May 8 09:17:57 debbie kernel: igb0: Queue(3) rdh = 1418, rdt = 1417 May 8 09:17:57 debbie kernel: igb0: RX(3) Packets received = 1418 May 8 09:17:57 debbie kernel: igb0: RX(3) Split Packets = 939 May 8 09:17:57 debbie kernel: igb0: RX(3) Byte count = 1700710 May 8 09:17:57 debbie kernel: igb0: RX(3) MSIX IRQ Handled = 31399 May 8 09:17:57 debbie kernel: igb0: RX(3) LRO
LOR: acpi_dock vs sysctl
Hi, just turned on WITNESS as my laptop freezes from time to time and among the many LORs, here's a new one: lock order reversal: 1st 0xc09f3484 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysctl.c:1521 2nd 0xc0eed504 ACPI Docking Station (ACPI Docking Station) @ /usr/src/sys/modules/acpi/acpi_dock/../../../dev/acpica/acpi_dock.c:423 KDB: stack backtrace: db_trace_self_wrapper(c09394fe,fb807aac,c062e515,c061e8ab,c093c4d8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061e8ab,c093c4d8,c4188da8,c418ae28,fb807b08,...) at kdb_backtrace+0x29 _witness_debugger(c093c4d8,c0eed504,c0eec1cb,c418ae28,c0eec15e,...) at _witness_debugger+0x25 witness_checkorder(c0eed504,9,c0eec15e,1a7,0,...) at witness_checkorder+0x839 _sx_xlock(c0eed504,0,c0eec15e,1a7,0,...) at _sx_xlock+0x85 acpi_dock_status_sysctl(c44c20c0,c42d0e80,0,fb807ba4,fb807ba4,...) at acpi_dock_status_sysctl+0x49 sysctl_root(fb807ba4,0,c0936c1e,5f1,c47bb000,...) at sysctl_root+0x187 userland_sysctl(c47bb000,fb807c10,4,0,bfbfdc40,...) at userland_sysctl+0x17c __sysctl(c47bb000,fb807cf8,c0972725,c093d30d,c47ead48,...) at __sysctl+0x94 syscall(fb807d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2818cc1b, esp = 0xbfbfdb4c, ebp = 0xbfbfdb78 --- btw, my laptop freezes sometimes when docking/undocking, not sure if this is related then. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR: ufs vs bufwait
This LOR also is not yet listed on the LOR page, so I guess it's rather new. I do use SUJ. lock order reversal: 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c09394fe,fb817308,c062e515,c061e8ab,c093c4f1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061e8ab,c093c4f1,c418b168,c418ef28,fb817364,...) at kdb_backtrace+0x29 _witness_debugger(c093c4f1,c49e56b8,c092e785,c418ef28,c094369d,...) at _witness_debugger+0x25 witness_checkorder(c49e56b8,9,c094369d,82b,0,...) at witness_checkorder+0x839 __lockmgr_args(c49e56b8,80100,c49e56d8,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(fb817488,c062e2bb,c0942b3f,80100,c49e5660,...) at ffs_lock+0x82 VOP_LOCK1_APV(c09bd600,fb817488,c4827cd4,c09d62a0,c49e5660,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c49e5660,80100,c094369d,82b,4,...) at _vn_lock+0x5e vget(c49e5660,80100,c4827c30,50,0,...) at vget+0xb9 vfs_hash_get(c47bea20,b803,8,c4827c30,fb8175d8,...) at vfs_hash_get+0xe6 ffs_vgetf(c47bea20,b803,8,fb8175d8,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c4838880,0,c0962957,144,0,...) at softdep_sync_metadata+0xc82 ffs_syncvnode(c4838880,1,c4827c30,fb817698,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c4838880,200,0,880,c41fb480,...) at ffs_truncate+0x862 ufs_direnter(c4838880,c49e5660,fb81794c,fb817bd4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(fb817bd4,0,fb817b30,fb817a94,c08e4cf5,...) at ufs_makeinode+0x517 ufs_create(fb817b30,fb817b48,0,0,fb817ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c09bd600,fb817b30,2,fb817ac0,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(fb817ba8,fb817c5c,1a4,0,c41fb480,...) at vn_open_cred+0x1de vn_open(fb817ba8,fb817c5c,1a4,c47e2428,0,...) at vn_open+0x3b kern_openat(c4827c30,ff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c4827c30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c4827c30,fb817cf8,c0972725,c091f062,c47ea2a8,...) at open+0x30 syscall(fb817d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817bf33, esp = 0xbfbfec4c, ebp = 0xbfbfecb8 --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
I have 3 boxes, each with two nics. One nic for the private network and one for the public network. The private network is all on the same vlan. All 6 nics are on the same switch. All connections are 1000tx Full Duplex. I will call the servers Box A, Box B, and Box C. When i FTP data between Box A B i get abou 25MB/sec. When i FTP data from Box C to Box A or B, i get about 20MB/sec. When i FTP data from Box A to C i get 10MB/sec When i FTP data from Box B to C i get 200KB/sec... Can anyone suggest why i might only be getting 200KB when transfering data from Box B to C but not when transferring data from Box A to C? I tried installing ubuntu to see if the problem was still there and it is not. I can FTP data from Box A or B to box C at 10MB/sec, still not the gigabit speeds i should be seeing but not the 200KB/sec i am getting with freebsd. I logged into my switch and it reports that the ports are 1000tx full duplex, the same as what freebsd is reporting. The switch freebsd also report no errors. I really dont know what to do. Nothing anywhere reports showing a problem but obviously there is a problem somewhere. I've tried drivers 1.9.5, 1.8.4, and 1.7.3. If i use 1.8.4 or 1.7.3 i get 50KB/sec transferring data from box B whereas if i use 1.9.5 i get 200-300KB sec. I should be getting like 50MB/sec ;( Any help would be grateful. Or, maybe someone could put me in touch with the person responsible for the intel nic drivers and i can work with them on resolving this issue? Thanks in advance. NameMtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll igb0 1500 Link#1 00:30:48:9f:11:0425853 0 0 18340 0 0 igb0 1500 216.105.91.14 216.105.91.145 19040 - - 18343 - - igb1* 1500 Link#2 00:30:48:9f:11:050 0 0 0 0 0 lo0 16384 Link#3 72 0 0 72 0 0 lo0 16384 127.0.0.0/8 127.0.0.1 72 - - 72 - - Sysctl info for igb0/1 dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.8.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x15d9 subdevice=0x0100 class=0x02 dev.igb.0.%parent: pci1 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.low_latency: 128 dev.igb.0.ave_latency: 450 dev.igb.0.bulk_latency: 1200 dev.igb.0.rx_processing_limit: 100 Debug info for igb0 May 8 09:17:57 debbie kernel: igb0: TX(1) Packets sent = 1295 May 8 09:17:57 debbie kernel: igb0: Queue(2) tdh = 106, tdt = 106 May 8 09:17:57 debbie kernel: igb0: TX(2) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(2) MSIX IRQ Handled = 5353 May 8 09:17:57 debbie kernel: igb0: TX(2) Packets sent = 5450 May 8 09:17:57 debbie kernel: igb0: Queue(3) tdh = 1687, tdt = 1687 May 8 09:17:57 debbie kernel: igb0: TX(3) no descriptors avail event = 0 May 8 09:17:57 debbie kernel: igb0: TX(3) MSIX IRQ Handled = 1335 May 8 09:17:57 debbie kernel: igb0: TX(3) Packets sent = 1354 May 8 09:17:57 debbie kernel: igb0: Queue(0) rdh = 425, rdt = 424 May 8 09:17:57 debbie kernel: igb0: RX(0) Packets received = 16809 May 8 09:17:57 debbie kernel: igb0: RX(0) Split Packets = 12262 May 8 09:17:57 debbie kernel: igb0: RX(0) Byte count = 25894129 May 8 09:17:57 debbie kernel: igb0: RX(0) MSIX IRQ Handled = 43428 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Queued= 13601 May 8 09:17:57 debbie kernel: igb0: RX(0) LRO Flushed= 9966 May 8 09:17:57 debbie kernel: igb0: Queue(1) rdh = 1700, rdt = 1699 May 8 09:17:57 debbie kernel: igb0: RX(1) Packets received = 1700 May 8 09:17:57 debbie kernel: igb0: RX(1) Split Packets = 937 May 8 09:17:57 debbie kernel: igb0: RX(1) Byte count = 1392691 May 8 09:17:57 debbie kernel: igb0: RX(1) MSIX IRQ Handled = 31888 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Queued= 1362 May 8 09:17:57 debbie kernel: igb0: RX(1) LRO Flushed= 1351 May 8 09:17:57 debbie kernel: igb0: Queue(2) rdh = 33, rdt = 32 May 8 09:17:57 debbie kernel: igb0: RX(2) Packets received = 6177 May 8 09:17:57 debbie kernel: igb0: RX(2) Split Packets = 1442 May 8 09:17:57 debbie kernel: igb0: RX(2) Byte count = 2518498 May 8 09:17:57 debbie kernel: igb0: RX(2) MSIX IRQ Handled = 36258 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Queued= 5794 May 8 09:17:57 debbie kernel: igb0: RX(2) LRO Flushed= 5673 May 8 09:17:57 debbie kernel: igb0: Queue(3) rdh = 1418, rdt = 1417 May 8 09:17:57 debbie kernel: igb0: RX(3) Packets received = 1418 May 8 09:17:57 debbie kernel: igb0: RX(3) Split Packets = 939 May 8 09:17:57 debbie kernel: igb0: RX(3) Byte count = 1700710 May 8 09:17:57 debbie kernel: igb0: RX(3) MSIX IRQ Handled = 31399 May 8 09:17:57 debbie kernel: igb0: RX(3) LRO Queued= 1102 May 8 09:17:57 debbie kernel: igb0: RX(3) LRO Flushed= 882 May 8
Re: PT_ATTACH resumes suspended process
On Fri, 7 May 2010 13:52:15 -0700 Ben Widawsky widaw...@gmail.com wrote: If a debugger attaches to a suspended process, the process will be resumed, and backgrounded. This seems like the incorrect behavior to me based what I read in the man page. The tracing process will see the newly-traced process stop and may then control it as if it had been traced all along. The behavior exhibited in FreeBSD is that the process is resumed, and we will not reach ptracestop() until the next debugger command comes in. [snip] Looking at the sendsig label in sys_process.c:kern_ptrace() makes it clear what's happening - in your testing the process was already stopped so the code sets td_xsig to SIGSTOP and wakes it up to send it the signal. But td_xsig doesn't seem to be used anywhere to set pending signals. Maybe I missed the place where that happens. The assumption seems to be that a process being traced will only be stopped if the debugger is already attached and that any signals being sent to it are coming from the debugger itself. This assumption is wrong if the process being attached to was already stopped. It seems to me that checking for req == PT_ATTACH when the process is already stopped and doing a break; in that case might be a solution. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. Ian -- Ian Freislich I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) These are the only two nics the local computer store has in stock. Anyone know if the TP LINK is supported? I couldnt find anything to suggest it is on google. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR: ufs vs bufwait
On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Spörlein wrote: This LOR also is not yet listed on the LOR page, so I guess it's rather new. I do use SUJ. lock order reversal: 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c09394fe,fb817308,c062e515,c061e8ab,c093c4f1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061e8ab,c093c4f1,c418b168,c418ef28,fb817364,...) at kdb_backtrace+0x29 _witness_debugger(c093c4f1,c49e56b8,c092e785,c418ef28,c094369d,...) at _witness_debugger+0x25 witness_checkorder(c49e56b8,9,c094369d,82b,0,...) at witness_checkorder+0x839 __lockmgr_args(c49e56b8,80100,c49e56d8,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(fb817488,c062e2bb,c0942b3f,80100,c49e5660,...) at ffs_lock+0x82 VOP_LOCK1_APV(c09bd600,fb817488,c4827cd4,c09d62a0,c49e5660,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c49e5660,80100,c094369d,82b,4,...) at _vn_lock+0x5e vget(c49e5660,80100,c4827c30,50,0,...) at vget+0xb9 vfs_hash_get(c47bea20,b803,8,c4827c30,fb8175d8,...) at vfs_hash_get+0xe6 ffs_vgetf(c47bea20,b803,8,fb8175d8,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c4838880,0,c0962957,144,0,...) at softdep_sync_metadata+0xc82 ffs_syncvnode(c4838880,1,c4827c30,fb817698,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c4838880,200,0,880,c41fb480,...) at ffs_truncate+0x862 ufs_direnter(c4838880,c49e5660,fb81794c,fb817bd4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(fb817bd4,0,fb817b30,fb817a94,c08e4cf5,...) at ufs_makeinode+0x517 ufs_create(fb817b30,fb817b48,0,0,fb817ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c09bd600,fb817b30,2,fb817ac0,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(fb817ba8,fb817c5c,1a4,0,c41fb480,...) at vn_open_cred+0x1de vn_open(fb817ba8,fb817c5c,1a4,c47e2428,0,...) at vn_open+0x3b kern_openat(c4827c30,ff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c4827c30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c4827c30,fb817cf8,c0972725,c091f062,c47ea2a8,...) at open+0x30 syscall(fb817d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817bf33, esp = 0xbfbfec4c, ebp = 0xbfbfecb8 --- And now the system is hanging again. While I can still ping and receive dmesg updates (eg. USB ports appearing), I/O is frozen solid. This is during portupgrade, when the configure script runs and usually takes 1-2 minutes to provoke. This part looks supsicious to me: db show alllocks Process 28014 (mkdir) thread 0xc691ac30 (100152) exclusive lockmgr bufwait (bufwait) r = 0 (0xec2bdaf0) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:10684 exclusive lockmgr ufs (ufs) r = 0 (0xc6bcd5a8) locked @ /usr/src/sys/kern/vfs_subr.c:2091 exclusive lockmgr bufwait (bufwait) r = 0 (0xec2983f4) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 exclusive lockmgr ufs (ufs) r = 0 (0xc6d976b8) locked @ /usr/src/sys/kern/vfs_lookup.c:502 Process 1990 (sshd) thread 0xc5462750 (100117) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc546e08c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 12 (intr) thread 0xc41f4750 (14) exclusive sleep mutex ttymtx (ttymtx) r = 0 (0xc425ae04) locked @ /usr/src/sys/dev/dcons/dcons_os.c:232 db Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SC_PIXEL_MODE in GENERIC on i386/amd64?
- jfbterm - boot splash - apps that use libvgl (e.g. mplayer) - other uses for graphic modes Is there a way to avoid recompiling kernel just to use them? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On 05/08/2010 11:17 AM, Ian FREISLICH wrote: joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich I bought those two cards anyways, im in a rush to figure out this problem. That being said i am still encountering the exact same problem regardless on which network card i am running. I am at a complete loss. I am about to try a raid card to see if the problem might lay within the onboard sata ports. I did pull the server and brought it home so that i can test more things quicker. I am going to try using a raid card instead of the onboard sata ports and see if i still encounter the same problem. I would love any suggestions you may have on where to go from here to figure out where the problem might be. joe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
Looks like something to do with system C, you might isolate it, and try a back to back connection with its NICs, change cables, look at BIOS settings, change the slot the nic is in... All just off the top of my head. Jack On Sat, May 8, 2010 at 9:41 AM, joe j...@hostedcontent.com wrote: On 05/08/2010 11:17 AM, Ian FREISLICH wrote: joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich I bought those two cards anyways, im in a rush to figure out this problem. That being said i am still encountering the exact same problem regardless on which network card i am running. I am at a complete loss. I am about to try a raid card to see if the problem might lay within the onboard sata ports. I did pull the server and brought it home so that i can test more things quicker. I am going to try using a raid card instead of the onboard sata ports and see if i still encounter the same problem. I would love any suggestions you may have on where to go from here to figure out where the problem might be. joe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On 05/08/2010 01:31 PM, Jack Vogel wrote: Looks like something to do with system C, you might isolate it, and try a back to back connection with its NICs, change cables, look at BIOS settings, change the slot the nic is in... All just off the top of my head. Jack On Sat, May 8, 2010 at 9:41 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 11:17 AM, Ian FREISLICH wrote: joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich I bought those two cards anyways, im in a rush to figure out this problem. That being said i am still encountering the exact same problem regardless on which network card i am running. I am at a complete loss. I am about to try a raid card to see if the problem might lay within the onboard sata ports. I did pull the server and brought it home so that i can test more things quicker. I am going to try using a raid card instead of the onboard sata ports and see if i still encounter the same problem. I would love any suggestions you may have on where to go from here to figure out where the problem might be. joe ___ freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org I think it might have something to so with the nics / switch, and their features. I brought the box home, plugged into my gb switch, and i am able to FTP data to the server at around 35MB/sec. I dont know what would cause this other than some sort of issue with the the 3 different types of nics and the switch i am using. Any suggestions? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR: ufs vs bufwait
On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote: 2010/5/8 Ulrich Spörlein u...@spoerlein.net: On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Spörlein wrote: This LOR also is not yet listed on the LOR page, so I guess it's rather new. I do use SUJ. lock order reversal: 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c09394fe,fb817308,c062e515,c061e8ab,c093c4f1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061e8ab,c093c4f1,c418b168,c418ef28,fb817364,...) at kdb_backtrace+0x29 _witness_debugger(c093c4f1,c49e56b8,c092e785,c418ef28,c094369d,...) at _witness_debugger+0x25 witness_checkorder(c49e56b8,9,c094369d,82b,0,...) at witness_checkorder+0x839 __lockmgr_args(c49e56b8,80100,c49e56d8,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(fb817488,c062e2bb,c0942b3f,80100,c49e5660,...) at ffs_lock+0x82 VOP_LOCK1_APV(c09bd600,fb817488,c4827cd4,c09d62a0,c49e5660,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c49e5660,80100,c094369d,82b,4,...) at _vn_lock+0x5e vget(c49e5660,80100,c4827c30,50,0,...) at vget+0xb9 vfs_hash_get(c47bea20,b803,8,c4827c30,fb8175d8,...) at vfs_hash_get+0xe6 ffs_vgetf(c47bea20,b803,8,fb8175d8,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c4838880,0,c0962957,144,0,...) at softdep_sync_metadata+0xc82 ffs_syncvnode(c4838880,1,c4827c30,fb817698,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c4838880,200,0,880,c41fb480,...) at ffs_truncate+0x862 ufs_direnter(c4838880,c49e5660,fb81794c,fb817bd4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(fb817bd4,0,fb817b30,fb817a94,c08e4cf5,...) at ufs_makeinode+0x517 ufs_create(fb817b30,fb817b48,0,0,fb817ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c09bd600,fb817b30,2,fb817ac0,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(fb817ba8,fb817c5c,1a4,0,c41fb480,...) at vn_open_cred+0x1de vn_open(fb817ba8,fb817c5c,1a4,c47e2428,0,...) at vn_open+0x3b kern_openat(c4827c30,ff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c4827c30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c4827c30,fb817cf8,c0972725,c091f062,c47ea2a8,...) at open+0x30 syscall(fb817d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817bf33, esp = 0xbfbfec4c, ebp = 0xbfbfecb8 --- And now the system is hanging again. While I can still ping and receive dmesg updates (eg. USB ports appearing), I/O is frozen solid. This is during portupgrade, when the configure script runs and usually takes 1-2 minutes to provoke. This part looks supsicious to me: db show alllocks Process 28014 (mkdir) thread 0xc691ac30 (100152) exclusive lockmgr bufwait (bufwait) r = 0 (0xec2bdaf0) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:10684 exclusive lockmgr ufs (ufs) r = 0 (0xc6bcd5a8) locked @ /usr/src/sys/kern/vfs_subr.c:2091 exclusive lockmgr bufwait (bufwait) r = 0 (0xec2983f4) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 exclusive lockmgr ufs (ufs) r = 0 (0xc6d976b8) locked @ /usr/src/sys/kern/vfs_lookup.c:502 Process 1990 (sshd) thread 0xc5462750 (100117) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc546e08c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 12 (intr) thread 0xc41f4750 (14) exclusive sleep mutex ttymtx (ttymtx) r = 0 (0xc425ae04) locked @ /usr/src/sys/dev/dcons/dcons_os.c:232 db Along with show alllocks may you also get the following from DDB: ps, show pcpu, alltrace, lockedvnods. 1. a kernel before SUJ went in is running fine with SU only 2. the following is on a recent -CURRENT that has SUJ, *but* i've disabled it, so it is running with soft-updates only (I hope) I ran a portupgrade and the first configure script triggered the I/O hang db ps pid ppid pgrp uid state wmesg wchancmd 13467 13444 12937 0 R+ mkdir 13444 13204 12937 0 S+ wait 0xc54352a8 sh 13204 13035 12937 0 S+ wait 0xc5436000 sh 13035 12937 12937 0 S+ wait 0xc4ffad48 sh 12937 12936 12937 0 Ss+ wait 0xc4ff9d48 make 12936 3722 3722 0 R+ script 3722 2021 3722 0 S+ (threaded) ruby18 100132 S wait 0xc4ffa7f8 ruby18 2404 2007 2404 1000 Ss+ ttyin0xc4d74870 zsh 2325 2015 2325 1000 R+ top 2021 2009 2021 0 S+ pause0xc4ff9058 csh 2015 2007 2015 1000 Ss+ pause0xc4ffa058 zsh 2009 2007 2009 1000 Ss+ pause0xc4d4e850 zsh 2007 2006 2007 1000 Rs screen 2006 1991 2006 1000 R+ screen 2005 2001 2005 0 R+ systat 2001 1976 2001 0 S+ pause0xc3d52058 csh 2000 1
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
I still am not clear on this system, how many ports are on it, and its an 82576? Sounds to me like you've proven its not on the box if you can do fine when its on its own. So change ports in the switch, as I said, change cables, must be something in that environment. Jack On Sat, May 8, 2010 at 10:04 AM, joe j...@hostedcontent.com wrote: On 05/08/2010 01:31 PM, Jack Vogel wrote: Looks like something to do with system C, you might isolate it, and try a back to back connection with its NICs, change cables, look at BIOS settings, change the slot the nic is in... All just off the top of my head. Jack On Sat, May 8, 2010 at 9:41 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 11:17 AM, Ian FREISLICH wrote: joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich I bought those two cards anyways, im in a rush to figure out this problem. That being said i am still encountering the exact same problem regardless on which network card i am running. I am at a complete loss. I am about to try a raid card to see if the problem might lay within the onboard sata ports. I did pull the server and brought it home so that i can test more things quicker. I am going to try using a raid card instead of the onboard sata ports and see if i still encounter the same problem. I would love any suggestions you may have on where to go from here to figure out where the problem might be. joe ___ freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org I think it might have something to so with the nics / switch, and their features. I brought the box home, plugged into my gb switch, and i am able to FTP data to the server at around 35MB/sec. I dont know what would cause this other than some sort of issue with the the 3 different types of nics and the switch i am using. Any suggestions? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR: ufs vs bufwait
2010/5/8 Ulrich Spörlein u...@spoerlein.net: On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote: 2010/5/8 Ulrich Spörlein u...@spoerlein.net: On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Spörlein wrote: This LOR also is not yet listed on the LOR page, so I guess it's rather new. I do use SUJ. lock order reversal: 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c09394fe,fb817308,c062e515,c061e8ab,c093c4f1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061e8ab,c093c4f1,c418b168,c418ef28,fb817364,...) at kdb_backtrace+0x29 _witness_debugger(c093c4f1,c49e56b8,c092e785,c418ef28,c094369d,...) at _witness_debugger+0x25 witness_checkorder(c49e56b8,9,c094369d,82b,0,...) at witness_checkorder+0x839 __lockmgr_args(c49e56b8,80100,c49e56d8,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(fb817488,c062e2bb,c0942b3f,80100,c49e5660,...) at ffs_lock+0x82 VOP_LOCK1_APV(c09bd600,fb817488,c4827cd4,c09d62a0,c49e5660,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c49e5660,80100,c094369d,82b,4,...) at _vn_lock+0x5e vget(c49e5660,80100,c4827c30,50,0,...) at vget+0xb9 vfs_hash_get(c47bea20,b803,8,c4827c30,fb8175d8,...) at vfs_hash_get+0xe6 ffs_vgetf(c47bea20,b803,8,fb8175d8,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c4838880,0,c0962957,144,0,...) at softdep_sync_metadata+0xc82 ffs_syncvnode(c4838880,1,c4827c30,fb817698,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c4838880,200,0,880,c41fb480,...) at ffs_truncate+0x862 ufs_direnter(c4838880,c49e5660,fb81794c,fb817bd4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(fb817bd4,0,fb817b30,fb817a94,c08e4cf5,...) at ufs_makeinode+0x517 ufs_create(fb817b30,fb817b48,0,0,fb817ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c09bd600,fb817b30,2,fb817ac0,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(fb817ba8,fb817c5c,1a4,0,c41fb480,...) at vn_open_cred+0x1de vn_open(fb817ba8,fb817c5c,1a4,c47e2428,0,...) at vn_open+0x3b kern_openat(c4827c30,ff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c4827c30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c4827c30,fb817cf8,c0972725,c091f062,c47ea2a8,...) at open+0x30 syscall(fb817d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817bf33, esp = 0xbfbfec4c, ebp = 0xbfbfecb8 --- And now the system is hanging again. While I can still ping and receive dmesg updates (eg. USB ports appearing), I/O is frozen solid. This is during portupgrade, when the configure script runs and usually takes 1-2 minutes to provoke. This part looks supsicious to me: db show alllocks Process 28014 (mkdir) thread 0xc691ac30 (100152) exclusive lockmgr bufwait (bufwait) r = 0 (0xec2bdaf0) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:10684 exclusive lockmgr ufs (ufs) r = 0 (0xc6bcd5a8) locked @ /usr/src/sys/kern/vfs_subr.c:2091 exclusive lockmgr bufwait (bufwait) r = 0 (0xec2983f4) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 exclusive lockmgr ufs (ufs) r = 0 (0xc6d976b8) locked @ /usr/src/sys/kern/vfs_lookup.c:502 Process 1990 (sshd) thread 0xc5462750 (100117) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc546e08c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 12 (intr) thread 0xc41f4750 (14) exclusive sleep mutex ttymtx (ttymtx) r = 0 (0xc425ae04) locked @ /usr/src/sys/dev/dcons/dcons_os.c:232 db Along with show alllocks may you also get the following from DDB: ps, show pcpu, alltrace, lockedvnods. 1. a kernel before SUJ went in is running fine with SU only 2. the following is on a recent -CURRENT that has SUJ, *but* i've disabled it, so it is running with soft-updates only (I hope) I ran a portupgrade and the first configure script triggered the I/O hang db ps pid ppid pgrp uid state wmesg wchan cmd 13467 13444 12937 0 R+ mkdir 13444 13204 12937 0 S+ wait 0xc54352a8 sh 13204 13035 12937 0 S+ wait 0xc5436000 sh 13035 12937 12937 0 S+ wait 0xc4ffad48 sh 12937 12936 12937 0 Ss+ wait 0xc4ff9d48 make 12936 3722 3722 0 R+ script 3722 2021 3722 0 S+ (threaded) ruby18 100132 S wait 0xc4ffa7f8 ruby18 2404 2007 2404 1000 Ss+ ttyin 0xc4d74870 zsh 2325 2015 2325 1000 R+ top 2021 2009 2021 0 S+ pause 0xc4ff9058 csh 2015 2007 2015 1000 Ss+ pause 0xc4ffa058 zsh 2009 2007 2009 1000 Ss+ pause 0xc4d4e850 zsh 2007 2006 2007 1000 Rs screen 2006 1991 2006 1000 R+ screen 2005 2001 2005 0 R+ systat
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On 05/08/2010 01:53 PM, Jack Vogel wrote: I still am not clear on this system, how many ports are on it, and its an 82576? Sounds to me like you've proven its not on the box if you can do fine when its on its own. So change ports in the switch, as I said, change cables, must be something in that environment. Jack On Sat, May 8, 2010 at 10:04 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 01:31 PM, Jack Vogel wrote: Looks like something to do with system C, you might isolate it, and try a back to back connection with its NICs, change cables, look at BIOS settings, change the slot the nic is in... All just off the top of my head. Jack On Sat, May 8, 2010 at 9:41 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 11:17 AM, Ian FREISLICH wrote: joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich I bought those two cards anyways, im in a rush to figure out this problem. That being said i am still encountering the exact same problem regardless on which network card i am running. I am at a complete loss. I am about to try a raid card to see if the problem might lay within the onboard sata ports. I did pull the server and brought it home so that i can test more things quicker. I am going to try using a raid card instead of the onboard sata ports and see if i still encounter the same problem. I would love any suggestions you may have on where to go from here to figure out where the problem might be. joe ___ freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org I think it might have something to so with the nics / switch, and their features. I brought the box home, plugged into my gb switch, and i am able to FTP data to the server at around 35MB/sec. I dont know what would cause this other than some sort of issue with the the 3 different types of nics and the switch i am using. Any suggestions?
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
The cable, its a simple thing but make SURE you try that, a slightly damaged one can do weird things and its quick to check, don't overlook it. Jack On Sat, May 8, 2010 at 10:22 AM, joe j...@hostedcontent.com wrote: On 05/08/2010 01:53 PM, Jack Vogel wrote: I still am not clear on this system, how many ports are on it, and its an 82576? Sounds to me like you've proven its not on the box if you can do fine when its on its own. So change ports in the switch, as I said, change cables, must be something in that environment. Jack On Sat, May 8, 2010 at 10:04 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 01:31 PM, Jack Vogel wrote: Looks like something to do with system C, you might isolate it, and try a back to back connection with its NICs, change cables, look at BIOS settings, change the slot the nic is in... All just off the top of my head. Jack On Sat, May 8, 2010 at 9:41 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 11:17 AM, Ian FREISLICH wrote: joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich I bought those two cards anyways, im in a rush to figure out this problem. That being said i am still encountering the exact same problem regardless on which network card i am running. I am at a complete loss. I am about to try a raid card to see if the problem might lay within the onboard sata ports. I did pull the server and brought it home so that i can test more things quicker. I am going to try using a raid card instead of the onboard sata ports and see if i still encounter the same problem. I would love any suggestions you may have on where to go from here to figure out where the problem might be. joe ___ freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org I think it might have something to so with the nics / switch, and their features. I brought the box home, plugged into my gb
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On 05/08/2010 02:21 PM, Jack Vogel wrote: The cable, its a simple thing but make SURE you try that, a slightly damaged one can do weird things and its quick to check, don't overlook it. Jack On Sat, May 8, 2010 at 10:22 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 01:53 PM, Jack Vogel wrote: I still am not clear on this system, how many ports are on it, and its an 82576? Sounds to me like you've proven its not on the box if you can do fine when its on its own. So change ports in the switch, as I said, change cables, must be something in that environment. Jack On Sat, May 8, 2010 at 10:04 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 01:31 PM, Jack Vogel wrote: Looks like something to do with system C, you might isolate it, and try a back to back connection with its NICs, change cables, look at BIOS settings, change the slot the nic is in... All just off the top of my head. Jack On Sat, May 8, 2010 at 9:41 AM, joe j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com mailto:j...@hostedcontent.com wrote: On 05/08/2010 11:17 AM, Ian FREISLICH wrote: joe wrote: On 05/08/2010 06:55 AM, Ian FREISLICH wrote: joe wrote: I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. I will grab a new nic today and try...my options are limited though. Here are the nics i can get my hands on TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich I bought those two cards anyways, im in a rush to figure out this problem. That being said i am still encountering the exact same problem regardless on which network card i am running. I am at a complete loss. I am about to try a raid card to see if the problem might lay within the onboard sata ports. I did
a panic on uart_z8530_class?
Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 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 = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- db call doadump Physical memory: 3916 MB Dumping 1239 MB: 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete = 0 db reset [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote: Hello Gustau, I'm so sorry for belated response that I had no time to read and work email and wireless stuffs. Could you please test this symptom with attached patch? It looks in CURRENT it missed to initialize a ratectl when it associates with AP. The patch made the machine to panic. I think it happened when launching the supplicant. In fact, right now it works by putting the RF switch to OFF. As soon as I change it to ON the machine panics. It get a trap 12, with two reasons : page fault and bufwrite, buffer is not busy? I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). Do you want me to test anything else ? Please give me some time to prepare another patch. My machine encountered another problem which looks related with serial console so I can not test my patch due to kernel panic. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Thu, May 06, 2010 at 10:27:31PM +0200, Attilio Rao wrote: 2010/5/6 Weongyo Jeong weongyo.je...@gmail.com: On Sun, Apr 25, 2010 at 10:42:16PM +0200, Gustau P?rez wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been testing the driver for a few time with AMD64/CURRENT. A few time ago I started to see messages like : bwn0: unsupported rate 0 I've checked the code and I found it seems to fail when trying to check the TX rate at if_bw.c:9561 (in bwn_ieeerate2hwrate routine the rate parameter is 0). I checked where bwn_ieeerate2hwrate is called, to see how 'rate' is calculated. This is where I got lost :( My AP is FreeBSD 8.0 box with an atheros card. My hostapd works with both WPA2-PSK and WPA2-EAP (although I thinks this is not the problem) but with default values for rates and friends. I then forced my hostapd to use only a subset of transmit rates (with supported_rates and basic_rates) with no luck. My laptop is a DELL D630 with a BCM4310 UART adapter. Any need info will be provided and any help will be appreciated. First I think we need to know that where rate == 0 comes from. ??Rate information on TX could be got from the following points: ?? ?? tp-mgmtrate ?? ?? tp-mcastrate ?? ?? tp-ucastrate ?? ?? ni-ni_txrate ?? Added some device_printf to test those values. This is what I got : bwn0: tp-mgmtrate : 2 bwn0: tp-mcastrate : 2 bwn0: tp-ucastrate : 255 bwn0: ni-ni_txrate : 0 ?? ??I didn't have time to follow the code to find out why it has a 0 value. If you need more info let me know. Hello Gustau, I'm so sorry for belated response that I had no time to read and work email and wireless stuffs. Could you please test this symptom with attached patch? ??It looks in CURRENT it missed to initialize a ratectl when it associates with AP. Hello, I have another problem where the bwn is fully recognized and wlan0 is created but the interface doesn't scan at all: # netstat -nil Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll bwn0 2290 Link#1 00:26:5e:64:be:750 0 0 0 0 0 # ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:26:5e:64:be:75 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 wme bintval 0 # kldstat Id Refs AddressSize Name 14 0x8010 90b9a8 kernel 21 0x80c22000 28a9abwn_v4_ucode.ko doing ifconfig wlan0 list scan ends up immediately without further output. The dmesg is here: http://www.freebsd.org/~attilio/dmesg-bwn0.diff Sorry for not digging further. It looks the interface isn't scanning. Could you please try to UP the device manually as the below after boot? # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 ssid something # ifconfig wlan0 up after some seconds # ifconfig wlan0 list scan regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: a panic on uart_z8530_class?
On Sat, 8 May 2010, Weongyo Jeong wrote: Hello, Anyone encountered this panic on recent CURRENT kernel? db bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- I haven't seen that particular panic, but I have seen uart_z8530_class (or something superficially similar to it) in stack traces that I can't see touching a uart device. [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q I have seen this behavior from kgdb --- it doesn't seem to be able to handle coredumps I've made recently. At first I thought that I managed to trash either my kernel image or kgdb binary with all the unclean shutdowns I've been having, but if you're seeing kgdb failures, maybe it's not just my local system. Yet I am assuming that this is not broken for *everyone*, or we would have heard more noise about it. I'm running a current snapshot from April 4th; maybe I will try updating to a new snapshot tonight and see if kgdb behaves better after everything is rebuilt. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. Is the coast clear yet? :) I have been holding off on updating -current due to the SUJ stuff, but that seems to have mostly settled down now, so I'm hoping that the work on the VM won't prevent me from running nvidia-driver. Thanks, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: a panic on uart_z8530_class?
On Sat, May 08, 2010 at 01:00:32PM -0700, Weongyo Jeong wrote: Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 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 = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 uartXXX there is collateral, actual panic happen in the ifc_simple_create(). ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- db call doadump Physical memory: 3916 MB Dumping 1239 MB: 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete = 0 db reset [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org pgp4CisxNoGtU.pgp Description: PGP signature
Re: a panic on uart_z8530_class?
On May 8, 2010, at 1:00 PM, Weongyo Jeong wrote: Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 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 = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- I think what you have is a simple NULL function pointer dereference (i.e. calling a function pointer that's NULL). The uart_z8530_class shows first in the backtrace because that symbol has address 0 (it's weak and you typically don't have the Z8530 SCC driver on amd64), so it's being returned when DDB looks up symbols at address 0. This then implies that ifc_simple_create() called a NULL function pointer. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. Is the coast clear yet? :) I have been holding off on updating -current due to the SUJ stuff, but that seems to have mostly settled down now, so I'm hoping that the work on the VM won't prevent me from running nvidia-driver. No, it's still in a state of flux. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. Is the coast clear yet? :) I have been holding off on updating -current due to the SUJ stuff, but that seems to have mostly settled down now, so I'm hoping that the work on the VM won't prevent me from running nvidia-driver. No, it's still in a state of flux. Ok, thanks for the info. I'm not going to pretend I understand what you're doing, but it sure _looks_ exciting. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: a panic on uart_z8530_class?
On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q I have seen this behavior from kgdb --- it doesn't seem to be able to handle coredumps I've made recently. At first I thought that I managed to trash either my kernel image or kgdb binary with all the unclean shutdowns I've been having, but if you're seeing kgdb failures, maybe it's not just my local system. Yet I am assuming that this is not broken for *everyone*, or we would have heard more noise about it. I'm running a current snapshot from April 4th; maybe I will try updating to a new snapshot tonight and see if kgdb behaves better after everything is rebuilt. Same here, for the last couple months maybe. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: a panic on uart_z8530_class?
On Sat, 8 May 2010, Weongyo Jeong wrote: Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 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 = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 can you give me l *ifc_simple_create+0x89 l *if_clone_createif+0x64 l *ifioctl+0x685 -- Bjoern A. Zeeb (from 21) Micky Rosa: But as we've all said, this game is about the past and the future, and tonight we forget about the past. We just focus on the future. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. What performance differences, if any, can we expect on uniprocessors from the vm page lock-related changes? Kip's original post on -arch mentioned some performance improvements and no significant regressions, but on a dual 4-core machine. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
Doug Barton wrote: On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. Is the coast clear yet? :) I have been holding off on updating -current due to the SUJ stuff, but that seems to have mostly settled down now, so I'm hoping that the work on the VM won't prevent me from running nvidia-driver. No, it's still in a state of flux. Ok, thanks for the info. I'm not going to pretend I understand what you're doing, but it sure _looks_ exciting. :) I should probably be explicit about one thing. Anyone using nothing but in-tree drivers, shouldn't be worried about updating. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
On Sat, May 8, 2010 at 4:20 PM, b. f. bf1...@googlemail.com wrote: On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. What performance differences, if any, can we expect on uniprocessors from the vm page lock-related changes? Kip's original post on -arch mentioned some performance improvements and no significant regressions, but on a dual 4-core machine. Alan (or Kip): Is there a document available that describes the work being done on the VM system? I would like to -- or like make and attempt to -- read such a document... Hey b. f., to which post on -arch are you referring? -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
On 08.05.2010 22:30 (UTC+1), Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. Is the coast clear yet? :) I have been holding off on updating -current due to the SUJ stuff, but that seems to have mostly settled down now, so I'm hoping that the work on the VM won't prevent me from running nvidia-driver. Hope I do not misunderstand the item. I updated current (amd64) today and it seems all is fine with newest nvidia driver at the moment, Rainer Thanks, Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
On Sat, May 8, 2010 at 2:39 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Sat, May 8, 2010 at 4:20 PM, b. f. bf1...@googlemail.com wrote: On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. What performance differences, if any, can we expect on uniprocessors from the vm page lock-related changes? Kip's original post on -arch mentioned some performance improvements and no significant regressions, but on a dual 4-core machine. Alan (or Kip): Is there a document available that describes the work being done on the VM system? I would like to -- or like make and attempt to -- read such a document... Hey b. f., to which post on -arch are you referring? there is no document. The basic idea is straightforward, but there are some unpleasant edges to cope with. http://www.mavetju.org/mail/view_message.php?list=freebsd-archid=3155260thread=no -Kip ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent sys/vm/ changes and nvidia-driver
On 5/8/10, Kip Macy kip.m...@gmail.com wrote: On Sat, May 8, 2010 at 2:39 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Sat, May 8, 2010 at 4:20 PM, b. f. bf1...@googlemail.com wrote: On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. What performance differences, if any, can we expect on uniprocessors from the vm page lock-related changes? Kip's original post on -arch mentioned some performance improvements and no significant regressions, but on a dual 4-core machine. Alan (or Kip): Is there a document available that describes the work being done on the VM system? I would like to -- or like make and attempt to -- read such a document... Hey b. f., to which post on -arch are you referring? I was referring to the message listed in Kip's link below. there is no document. The basic idea is straightforward, but there are some unpleasant edges to cope with. http://www.mavetju.org/mail/view_message.php?list=freebsd-archid=3155260thread=no -Kip ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR: ufs vs bufwait
On Sat, 8 May 2010, Ulrich Sp?rlein wrote: On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote: 2010/5/8 Ulrich Sp?rlein u...@spoerlein.net: On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Sp?rlein wrote: This LOR also is not yet listed on the LOR page, so I guess it's rather new. I do use SUJ. lock order reversal: 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c09394fe,fb817308,c062e515,c061e8ab,c093c4f1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061e8ab,c093c4f1,c418b168,c418ef28,fb817364,...) at kdb_backtrace+0x29 _witness_debugger(c093c4f1,c49e56b8,c092e785,c418ef28,c094369d,...) at _witness_debugger+0x25 witness_checkorder(c49e56b8,9,c094369d,82b,0,...) at witness_checkorder+0x839 __lockmgr_args(c49e56b8,80100,c49e56d8,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(fb817488,c062e2bb,c0942b3f,80100,c49e5660,...) at ffs_lock+0x82 VOP_LOCK1_APV(c09bd600,fb817488,c4827cd4,c09d62a0,c49e5660,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c49e5660,80100,c094369d,82b,4,...) at _vn_lock+0x5e vget(c49e5660,80100,c4827c30,50,0,...) at vget+0xb9 vfs_hash_get(c47bea20,b803,8,c4827c30,fb8175d8,...) at vfs_hash_get+0xe6 ffs_vgetf(c47bea20,b803,8,fb8175d8,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c4838880,0,c0962957,144,0,...) at softdep_sync_metadata+0xc82 ffs_syncvnode(c4838880,1,c4827c30,fb817698,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c4838880,200,0,880,c41fb480,...) at ffs_truncate+0x862 ufs_direnter(c4838880,c49e5660,fb81794c,fb817bd4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(fb817bd4,0,fb817b30,fb817a94,c08e4cf5,...) at ufs_makeinode+0x517 ufs_create(fb817b30,fb817b48,0,0,fb817ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c09bd600,fb817b30,2,fb817ac0,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(fb817ba8,fb817c5c,1a4,0,c41fb480,...) at vn_open_cred+0x1de vn_open(fb817ba8,fb817c5c,1a4,c47e2428,0,...) at vn_open+0x3b kern_openat(c4827c30,ff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c4827c30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c4827c30,fb817cf8,c0972725,c091f062,c47ea2a8,...) at open+0x30 syscall(fb817d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817bf33, esp = 0xbfbfec4c, ebp = 0xbfbfecb8 --- And now the system is hanging again. While I can still ping and receive dmesg updates (eg. USB ports appearing), I/O is frozen solid. This is during portupgrade, when the configure script runs and usually takes 1-2 minutes to provoke. This part looks supsicious to me: db show alllocks Process 28014 (mkdir) thread 0xc691ac30 (100152) exclusive lockmgr bufwait (bufwait) r = 0 (0xec2bdaf0) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:10684 exclusive lockmgr ufs (ufs) r = 0 (0xc6bcd5a8) locked @ /usr/src/sys/kern/vfs_subr.c:2091 exclusive lockmgr bufwait (bufwait) r = 0 (0xec2983f4) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 exclusive lockmgr ufs (ufs) r = 0 (0xc6d976b8) locked @ /usr/src/sys/kern/vfs_lookup.c:502 Process 1990 (sshd) thread 0xc5462750 (100117) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc546e08c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 12 (intr) thread 0xc41f4750 (14) exclusive sleep mutex ttymtx (ttymtx) r = 0 (0xc425ae04) locked @ /usr/src/sys/dev/dcons/dcons_os.c:232 db Along with show alllocks may you also get the following from DDB: ps, show pcpu, alltrace, lockedvnods. 1. a kernel before SUJ went in is running fine with SU only 2. the following is on a recent -CURRENT that has SUJ, *but* i've disabled it, so it is running with soft-updates only (I hope) I ran a portupgrade and the first configure script triggered the I/O hang db ps pid ppid pgrp uid state wmesg wchancmd 13467 13444 12937 0 R+ mkdir 13444 13204 12937 0 S+ wait 0xc54352a8 sh 13204 13035 12937 0 S+ wait 0xc5436000 sh 13035 12937 12937 0 S+ wait 0xc4ffad48 sh 12937 12936 12937 0 Ss+ wait 0xc4ff9d48 make 12936 3722 3722 0 R+ script 3722 2021 3722 0 S+ (threaded) ruby18 100132 S wait 0xc4ffa7f8 ruby18 2404 2007 2404 1000 Ss+ ttyin0xc4d74870 zsh 2325 2015 2325 1000 R+ top 2021 2009 2021 0 S+ pause0xc4ff9058 csh 2015 2007 2015 1000 Ss+ pause0xc4ffa058 zsh 2009 2007 2009 1000 Ss+ pause0xc4d4e850 zsh 2007 2006 2007 1000 Rs screen 2006 1991 2006 1000 R+ screen 2005 2001 2005 0 R+ systat 2001 1976 2001 0 S+ pause0xc3d52058 csh 2000 1 2000 0 Ss select 0xc3d5b1a4 ssh-agent 1991 1990 1991 1000 Ss+ pause0xc3d52850 zsh
Re: Recent sys/vm/ changes and nvidia-driver
On Sat, May 8, 2010 at 2:20 PM, b. f. bf1...@googlemail.com wrote: On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days. This round of changes are not yet complete. What performance differences, if any, can we expect on uniprocessors from the vm page lock-related changes? Kip's original post on -arch mentioned some performance improvements and no significant regressions, but on a dual 4-core machine. I wouldn't actually worry about UP since the overhead can largely be disabled by building without SMP. I think we need to be looking at how a dual-core system performs, trading off any regressions there against current processor trends of ever higher core and thread count. Cheers, Kip ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR: ufs vs bufwait
2010/5/9 Jeff Roberson jrober...@jroberson.net: On Sat, 8 May 2010, Ulrich Sp?rlein wrote: On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote: 2010/5/8 Ulrich Sp?rlein u...@spoerlein.net: On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Sp?rlein wrote: This LOR also is not yet listed on the LOR page, so I guess it's rather new. I do use SUJ. lock order reversal: 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c09394fe,fb817308,c062e515,c061e8ab,c093c4f1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061e8ab,c093c4f1,c418b168,c418ef28,fb817364,...) at kdb_backtrace+0x29 _witness_debugger(c093c4f1,c49e56b8,c092e785,c418ef28,c094369d,...) at _witness_debugger+0x25 witness_checkorder(c49e56b8,9,c094369d,82b,0,...) at witness_checkorder+0x839 __lockmgr_args(c49e56b8,80100,c49e56d8,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(fb817488,c062e2bb,c0942b3f,80100,c49e5660,...) at ffs_lock+0x82 VOP_LOCK1_APV(c09bd600,fb817488,c4827cd4,c09d62a0,c49e5660,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c49e5660,80100,c094369d,82b,4,...) at _vn_lock+0x5e vget(c49e5660,80100,c4827c30,50,0,...) at vget+0xb9 vfs_hash_get(c47bea20,b803,8,c4827c30,fb8175d8,...) at vfs_hash_get+0xe6 ffs_vgetf(c47bea20,b803,8,fb8175d8,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c4838880,0,c0962957,144,0,...) at softdep_sync_metadata+0xc82 ffs_syncvnode(c4838880,1,c4827c30,fb817698,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c4838880,200,0,880,c41fb480,...) at ffs_truncate+0x862 ufs_direnter(c4838880,c49e5660,fb81794c,fb817bd4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(fb817bd4,0,fb817b30,fb817a94,c08e4cf5,...) at ufs_makeinode+0x517 ufs_create(fb817b30,fb817b48,0,0,fb817ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c09bd600,fb817b30,2,fb817ac0,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(fb817ba8,fb817c5c,1a4,0,c41fb480,...) at vn_open_cred+0x1de vn_open(fb817ba8,fb817c5c,1a4,c47e2428,0,...) at vn_open+0x3b kern_openat(c4827c30,ff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c4827c30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c4827c30,fb817cf8,c0972725,c091f062,c47ea2a8,...) at open+0x30 syscall(fb817d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817bf33, esp = 0xbfbfec4c, ebp = 0xbfbfecb8 --- And now the system is hanging again. While I can still ping and receive dmesg updates (eg. USB ports appearing), I/O is frozen solid. This is during portupgrade, when the configure script runs and usually takes 1-2 minutes to provoke. This part looks supsicious to me: db show alllocks Process 28014 (mkdir) thread 0xc691ac30 (100152) exclusive lockmgr bufwait (bufwait) r = 0 (0xec2bdaf0) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:10684 exclusive lockmgr ufs (ufs) r = 0 (0xc6bcd5a8) locked @ /usr/src/sys/kern/vfs_subr.c:2091 exclusive lockmgr bufwait (bufwait) r = 0 (0xec2983f4) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 exclusive lockmgr ufs (ufs) r = 0 (0xc6d976b8) locked @ /usr/src/sys/kern/vfs_lookup.c:502 Process 1990 (sshd) thread 0xc5462750 (100117) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc546e08c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 12 (intr) thread 0xc41f4750 (14) exclusive sleep mutex ttymtx (ttymtx) r = 0 (0xc425ae04) locked @ /usr/src/sys/dev/dcons/dcons_os.c:232 db Along with show alllocks may you also get the following from DDB: ps, show pcpu, alltrace, lockedvnods. 1. a kernel before SUJ went in is running fine with SU only 2. the following is on a recent -CURRENT that has SUJ, *but* i've disabled it, so it is running with soft-updates only (I hope) I ran a portupgrade and the first configure script triggered the I/O hang db ps pid ppid pgrp uid state wmesg wchan cmd 13467 13444 12937 0 R+ mkdir 13444 13204 12937 0 S+ wait 0xc54352a8 sh 13204 13035 12937 0 S+ wait 0xc5436000 sh 13035 12937 12937 0 S+ wait 0xc4ffad48 sh 12937 12936 12937 0 Ss+ wait 0xc4ff9d48 make 12936 3722 3722 0 R+ script 3722 2021 3722 0 S+ (threaded) ruby18 100132 S wait 0xc4ffa7f8 ruby18 2404 2007 2404 1000 Ss+ ttyin 0xc4d74870 zsh 2325 2015 2325 1000 R+ top 2021 2009 2021 0 S+ pause 0xc4ff9058 csh 2015 2007 2015 1000 Ss+ pause 0xc4ffa058 zsh 2009 2007 2009 1000 Ss+ pause 0xc4d4e850 zsh 2007 2006 2007 1000 Rs screen 2006 1991 2006 1000 R+ screen 2005 2001 2005 0 R+ systat 2001 1976 2001 0 S+ pause
Re: amdtemp(4) issue
Hi jkim. On Wed, 5 May 2010 13:51:10 -0400 Jung-uk Kim j...@freebsd.org wrote: 11 - 0x01 = +10C 11 - 0x18 = -13C 11 - 0x3f = -52C [*] http://support.amd.com/us/Processor_TechDocs/31116.pdf AMD keeps flipping the sign from core to core. :-( Please see AMDTEMP_FLAG_DO_SIGN for Family 0Fh, for example. In fact, Linux driver (k10temp) does not care about the DiodeOffset at all. Instead, they just say input temperature. Oh my god... OK, I see. I got following thermal related registers in amdtemp_gettemp function: May 5 15:06:53 nadesico kernel: amdtemp0: F3x64 Hardware Thermal Control(HTC) Register = 0x3a4c0005 May 5 15:06:53 nadesico kernel: amdtemp0: F3x68 Software Thermal Control(STC) Register = 0x1000 May 5 15:06:53 nadesico kernel: amdtemp0: F3xA4 Reported Temperature Control Register = 0x000c1880 May 5 15:06:53 nadesico kernel: amdtemp0: F3xE4 Thermtrip Status Register = 0x1cc01830 May 5 15:06:53 nadesico kernel: amdtemp0: F3xE8 Northbridge Capabilities Register = 0x0207df19 But I don't have any idea to fix register's paraemters. Do you have any idea? Sorry, I don't. You may find Linux k10temp driver (drivers/hwmon/k10temp.c) useful, though. Thank you, I'll compare other implementations. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: a panic on uart_z8530_class?
On Sat, May 8, 2010 at 3:35 PM, ben wilber b...@desync.com wrote: On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q I have seen this behavior from kgdb --- it doesn't seem to be able to handle coredumps I've made recently. At first I thought that I managed to trash either my kernel image or kgdb binary with all the unclean shutdowns I've been having, but if you're seeing kgdb failures, maybe it's not just my local system. Yet I am assuming that this is not broken for *everyone*, or we would have heard more noise about it. I'm running a current snapshot from April 4th; maybe I will try updating to a new snapshot tonight and see if kgdb behaves better after everything is rebuilt. Same here, for the last couple months maybe. I'll chime in here with a me too. Since at early April, I've been trying to figure out why my laptop locks up overnight (something about the CPUs going into C3). I can nearly always get it to coredump, but the vmcore files I generate are unusable... -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: a panic on uart_z8530_class?
On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: On Sat, May 8, 2010 at 3:35 PM, ben wilber b...@desync.com wrote: On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q I have seen this behavior from kgdb --- it doesn't seem to be able to handle coredumps I've made recently. At first I thought that I managed to trash either my kernel image or kgdb binary with all the unclean shutdowns I've been having, but if you're seeing kgdb failures, maybe it's not just my local system. Yet I am assuming that this is not broken for *everyone*, or we would have heard more noise about it. I'm running a current snapshot from April 4th; maybe I will try updating to a new snapshot tonight and see if kgdb behaves better after everything is rebuilt. Same here, for the last couple months maybe. I'll chime in here with a me too. Since at early April, I've been trying to figure out why my laptop locks up overnight (something about the CPUs going into C3). I can nearly always get it to coredump, but the vmcore files I generate are unusable... -Brandon Just another me too. May be we have something common in our setup? (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI IXP700 AHCI SATA controller). Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). Yuri ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
