Problem detecting Sil3124 SATA controllers off of Sandy Bridge northbridge-connected PCIe slots
Hi, We're having some trouble with detection of a couple of Sil3124 SATA controller cards on newer motherboard and processor combos. Specifically, we're running a Supermicro X9SCM-F motherboard (latest BIOS) and Intel E3-1220v2 CPU. What we're seeing: - Syba Sil3124 PCIe cards are only being detected when installed in PCIe Slot 4 -- The motherboard documentation shows that this is the only slot connected to the Intel C202/204 chipset on the motherboard -- Slots 5, 6, and 7 are connected to the integrated northbridge on the Ivy Bridge CPU (there is no slot 1, 2, or 3) FreeBSD won't detect even a single Sil3124 card installed in PCIe slot 5, 6, or 7. If we put an Intel Dual-port NIC in either of one of these slots, it is detected just fine. I've attached a verbose dmesg.boot from this box running FreeBSD 9.0-RELEASE. We've also tried 8.1-RELEASE, 8.2-RELEASE, and 9.1-BETA1 with the same results. Booting with ACPI disabled results in a kernel panic during the boot process. I'd greatly appreciate any help or suggestions on this matter. We've already tried just about every BIOS option on the board. Steve Polyack Table 'FACP' at 0xddfb5290 Table 'APIC' at 0xddfb5388 APIC: Found table at 0xddfb5388 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 3: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 4: enabled SMP: Added CPU 6 (AP) Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Table 'FACP' at 0xddfb5290 Table 'APIC' at 0xddfb5388 Table 'FPDT' at 0xddfb5400 Table 'MCFG' at 0xddfb5448 Table 'HPET' at 0xddfb5488 Table 'SSDT' at 0xddfb54c0 Table 'SPMI' at 0xddfb5830 Table 'SSDT' at 0xddfb5870 Table 'SPCR' at 0xddfb62f8 Table 'EINJ' at 0xddfb6348 Table 'ERST' at 0xddfb6478 Table 'HEST' at 0xddfb6688 Table 'BERT' at 0xddfb6730 Table 'BGRT' at 0xddfb6760 ACPI: No SRAT table found Preloaded elf kernel /boot/kernel/kernel at 0x813cf000. Calibrating TSC clock ... TSC clock: 3100091416 Hz CPU: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz (3100.09-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x77bae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,AVX,F16C,b30 AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) Physical memory chunk(s): 0x1000 - 0x00094fff, 606208 bytes (148 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x0140b000 - 0xdddecfff, 3701350400 bytes (903650 pages) 0xdf056000 - 0xdf056fff, 4096 bytes (1 pages) 0xdf09a000 - 0xdf7f, 7757824 bytes (1894 pages) 0x0001 - 0x000400fa7fff, 12901318656 bytes (3149736 pages) avail memory = 16506712064 (15742 MB) Event timer LAPIC quality 600 ACPI APIC Table: SUPERM SMCI--MB INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff8000246000 x86bios: EBDA 0x098000-0x09 at 0xfe098000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 lapic0: CMCI unmasked ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf0490 00024 (v02 SUPERM) ACPI: XSDT 0xddfaa088 00094 (v01 SUPERM SMCI--MB 0001 AMI 00010013) ACPI: FACP 0xddfb5290 000F4 (v04 SUPERM SMCI--MB 0001 AMI 00010013) ACPI: DSDT 0xddfaa1b8 0B0D7 (v02 SUPERM SMCI--MB INTL 20051117) ACPI: FACS 0xddfb8f80 00040 ACPI: APIC 0xddfb5388 00072 (v03 SUPERM SMCI--MB 0001 AMI 00010013) ACPI: FPDT 0xddfb5400 00044 (v01 SUPERM SMCI--MB 0001 AMI 00010013) ACPI: MCFG 0xddfb5448 0003C (v01 SUPERM SMCI--MB 0001 MSFT 0097) ACPI: HPET 0xddfb5488 00038 (v01 SUPERM SMCI--MB 0001 AMI. 0005) ACPI: SSDT 0xddfb54c0 0036D (v01 SataRe SataTabl 1000 INTL 20091112) ACPI: SPMI 0xddfb5830 00040 (v05 A M I OEMSPMI
Re: Problem detecting Sil3124 SATA controllers off of Sandy Bridge northbridge-connected PCIe slots
On 08/02/2012 01:58 PM, John Baldwin wrote: On Thursday, August 02, 2012 10:21:20 am Steve Polyack wrote: Hi, We're having some trouble with detection of a couple of Sil3124 SATA controller cards on newer motherboard and processor combos. Specifically, we're running a Supermicro X9SCM-F motherboard (latest BIOS) and Intel E3-1220v2 CPU. What we're seeing: - Syba Sil3124 PCIe cards are only being detected when installed in PCIe Slot 4 -- The motherboard documentation shows that this is the only slot connected to the Intel C202/204 chipset on the motherboard -- Slots 5, 6, and 7 are connected to the integrated northbridge on the Ivy Bridge CPU (there is no slot 1, 2, or 3) FreeBSD won't detect even a single Sil3124 card installed in PCIe slot 5, 6, or 7. If we put an Intel Dual-port NIC in either of one of these slots, it is detected just fine. I've attached a verbose dmesg.boot from this box running FreeBSD 9.0-RELEASE. We've also tried 8.1-RELEASE, 8.2-RELEASE, and 9.1-BETA1 with the same results. Booting with ACPI disabled results in a kernel panic during the boot process. I'd greatly appreciate any help or suggestions on this matter. We've already tried just about every BIOS option on the board. Does the device show up in pciconf -l output? The device itself does NOT show up in pciconf -l output. However, I ran pciconf on two different boots, once with and once without the card installed in one of the non-probed slots. I noticed that the following Ivy Bridge PCI Express Root Port showed up when the card was installed: +pcib2@pci0:0:1:1:class=0x060400 card=0x062415d9 chip=0x01558086 rev=0x09 hdr=0x01 +vendor = 'Intel Corporation' +device = 'Ivy Bridge PCI Express Root Port' +class = bridge +subclass = PCI-PCI +cap 0d[88] = PCI Bridge card=0x062415d9 +cap 01[80] = powerspec 3 supports D0 D3 current D0 +cap 05[90] = MSI supports 1 message +cap 10[a0] = PCI-Express 2 root port max data 128(128) link x1(x8) +ecap 0002[100] = VC 1 max VC0 +ecap 0005[140] = unknown 1 +ecap 0019[d94] = unknown 1 The previous Ivy Bridge Root Port still shows up, and shows the following change: -cap 10[a0] = PCI-Express 2 root port max data 256(256) link x1(x8) +cap 10[a0] = PCI-Express 2 root port max data 256(256) link x0(x8) I also meant to note in my initial email that the Option ROM (RAID setup, drive probing, etc.) shows up for the Sil3124 SATA card in any slot. Even when the OS is unable to discover the card. Thanks for the response, Steve hostb0@pci0:0:0:0: class=0x06 card=0x062415d9 chip=0x01588086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Ivy Bridge DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 pcib1@pci0:0:1:0: class=0x060400 card=0x062415d9 chip=0x01518086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'Ivy Bridge PCI Express Root Port' class = bridge subclass = PCI-PCI cap 0d[88] = PCI Bridge card=0x062415d9 cap 01[80] = powerspec 3 supports D0 D3 current D0 cap 05[90] = MSI supports 1 message cap 10[a0] = PCI-Express 2 root port max data 256(256) link x0(x8) ecap 0002[100] = VC 1 max VC0 ecap 0005[140] = unknown 1 ecap 0019[d94] = unknown 1 pcib2@pci0:0:1:1: class=0x060400 card=0x062415d9 chip=0x01558086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'Ivy Bridge PCI Express Root Port' class = bridge subclass = PCI-PCI cap 0d[88] = PCI Bridge card=0x062415d9 cap 01[80] = powerspec 3 supports D0 D3 current D0 cap 05[90] = MSI supports 1 message cap 10[a0] = PCI-Express 2 root port max data 128(128) link x1(x8) ecap 0002[100] = VC 1 max VC0 ecap 0005[140] = unknown 1 ecap 0019[d94] = unknown 1 em0@pci0:0:25:0:class=0x02 card=0x150215d9 chip=0x15028086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82579LM Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf7b0, size 131072, enabled bar [14] = type Memory, range 32, base 0xf7b25000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xf020, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:0: class=0x0c0320 card=0x062415d9 chip=0x1c2d8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xf7b24000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13
Re: Usling vlan(4) without an actual lan behind it
On 09/21/2011 01:34 PM, Mike Andrews wrote: On Mon, 19 Sep 2011, Pete French wrote: Does it specifically have to be a vlan(4), or can you perhaps add another address to lo(4), or perhaps create a lo1 in addition to the lo0? It can be anything really - I was looking for a generic interface I can configure with IP addresses. But adding real addresses to loopback interfaces can cause problems can it not ? The issue I am trying to address is that I have a whole bunch of IPv6 addresse on a /64, which are oly used as endpoints for a set of websites - they don't exist on a real ethernet anywhere, and don't need to. I just want them on an interface on a machine wwhen I can run up a load balancer to listeon on those addresses and forward them to the approrpiate actual machines serving the requests. Sounds like DSR-type load balancing (or in Linux LVS land, DR mode), where the load balancer just rewrites the target MAC address in the header instead of doing full-blown NAT or proxying. Putting the IP's on lo0 is the way to go here. We've been doing that for many, many years (well, months for v6, years for v4) and it works great. With the IP's on lo0, the load balancers are the only thing that can ARP (or NDP) for those addresses... which is what you'd want. I'll second that this works just fine (at least on the IPv4 side). We've always used lo1 to separate things, but that doesn't functionally change anything. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Networking - CARP interfaces
On 06/14/2011 01:00 PM, Damien Fleuriot wrote: I can confirm that this scenario causes problems, see below: ### ON FIREWALL 1 , carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2 , carp backup for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 carp: BACKUP vhid 234 advbase 1 advskew 100 Now, I add a dummy IP to carp2 on FIREWALL 2, which is supposedly backup: ifconfig carp2 inet 192.168.234.207 alias Result: ### ON FIREWALL 1, carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2, carp backup for carp0, carp1, but no longer carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 inet 192.168.234.207 netmask 0xff00 carp: MASTER vhid 234 advbase 1 advskew 100 After I remove the extraneous IP, the interface becomes backup again: # This was a long time ago carp0: MASTER - BACKUP (more frequent advertisement received) carp0: link state changed to DOWN carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN carp1: MASTER - BACKUP (more frequent advertisement received) carp1: link state changed to DOWN carp2: link state changed to DOWN # This was when I ran my tests carp2: INIT - MASTER (preempting) carp2: link state changed to UP carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN Did you give this enough time to reasonably settle? Sometimes when the interfaces initially come up, they will become MASTER for a bit before backing down. This entails that hosts in a given carp vhid must have the exact same IP addresses configured on that interface. While this is perfectly understandable in a master-backup scenario, this is a bit more annoying for us in a master-backup + backup-backup scenario with 2 datacenters. I'll just have to adapt and ensure they have the same IP addresses then. I have a suspicion that the important part may be the number of IP addresses on the CARP interface. If CARP sends an advertisement from each IP alias on a CARP interface, then I think that would explain what you are seeing - and also possibly give you a workaround by adding two more bogus IPs on your primary datacenter firewalls (where IPs W and Z are normally missing). - Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Networking - CARP interfaces
On 06/14/2011 04:51 PM, Damien Fleuriot wrote: On 14 Jun 2011, at 19:33, Steve Polyackkor...@comcast.net wrote: On 06/14/2011 01:00 PM, Damien Fleuriot wrote: I can confirm that this scenario causes problems, see below: ### ON FIREWALL 1 , carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2 , carp backup for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 carp: BACKUP vhid 234 advbase 1 advskew 100 Now, I add a dummy IP to carp2 on FIREWALL 2, which is supposedly backup: ifconfig carp2 inet 192.168.234.207 alias Result: ### ON FIREWALL 1, carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2, carp backup for carp0, carp1, but no longer carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 inet 192.168.234.207 netmask 0xff00 carp: MASTER vhid 234 advbase 1 advskew 100 After I remove the extraneous IP, the interface becomes backup again: # This was a long time ago carp0: MASTER - BACKUP (more frequent advertisement received) carp0: link state changed to DOWN carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN carp1: MASTER - BACKUP (more frequent advertisement received) carp1: link state changed to DOWN carp2: link state changed to DOWN # This was when I ran my tests carp2: INIT - MASTER (preempting) carp2: link state changed to UP carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN Did you give this enough time to reasonably settle? Sometimes when the interfaces initially come up, they will become MASTER for a bit before backing down. I think I did but I can do try again tomorrow evening just to make sure. Oh god, if only dmesg entries were timestamped... This entails that hosts in a given carp vhid must have the exact same IP addresses configured on that interface. While this is perfectly understandable in a master-backup scenario, this is a bit more annoying for us in a master-backup + backup-backup scenario with 2 datacenters. I'll just have to adapt and ensure they have the same IP addresses then. I have a suspicion that the important part may be the number of IP addresses on the CARP interface. If CARP sends an advertisement from each IP alias on a CARP interface, then I think that would explain what you are seeing - and also possibly give you a workaround by adding two more bogus IPs on your primary datacenter firewalls (where IPs W and Z are normally missing). - Steve I'll give it a try, although I think in a scenario where the carp interfaces have the same number of IPs and these IPs differ, both interfaces will claim mastership. Will post results. Now that I look at the spec, it looks like both the count and the addresses themselves are provided in VRRP packets. CARP likely does the same. I can't speak for whether these things are considered along with the VHID and password, but it's worth a shot. I think you are correct, though. http://www.networksorcery.com/enp/protocol/vrrp.htm - Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FBSD 8.2R does not probe sound card
On 03/17/11 10:25, Gua Chung Lim wrote: Hi all, I have been using FBSD since mid 2005 without any problems. Recently, I installed 8.2R from DVD on my new machine. (HP Pavilion p6276l Home PC) FBSD 8.2R does not probe my sound card. # kldload snd_driver ppc0: parallel port not found. ppc0: parallel port not found. ppc0: parallel port not found. ppc0: parallel port not found. hdac0:NVidia MCP61 High Definition Audio Controller mem 0xfbdf8000-0xfbdfbfff irq 23 at device 5.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 hdac1:ATI RV730 High Definition Audio Controller mem 0xfbeec000-0xfbee irq 17 at device 0.1 on pci2 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI R6xx HDMI pcm0:HDA Realtek ALC662 PCM #0 Analog at cad 0 nid 1 on hdac0 pcm1:HDA ATI R6xx HDMI PCM #0 HDMI at cad 0 nid 1 on hdac1 ppc0: parallel port not found. ppc0: parallel port not found. I check sound card properties with Win7 (on another partition/slice). It says ``High Definition Audio Device'' and nothing else. So I try again. # kldload snd_hda hdac0:NVidia MCP61 High Definition Audio Controller mem 0xfbdf8000-0xfbdfbfff irq 23 at device 5.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 hdac1:ATI RV730 High Definition Audio Controller mem 0xfbeec000-0xfbee irq 17 at device 0.1 on pci2 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI R6xx HDMI pcm0:HDA Realtek ALC662 PCM #0 Analog at cad 0 nid 1 on hdac0 pcm1:HDA ATI R6xx HDMI PCM #0 HDMI at cad 0 nid 1 on hdac1 Both cases the speakers are still quiet. Anyone who has a clue or experieces this problem, please point me out. It looks like your card is getting probed in both cases, unless you have an additional device that is not being listed. The pcm0 device above looks to be from onboard sound on your nvidia motherboard, while the pcm1 device is the HDMI audio output on your graphics card. My only suggestion here is to play with the sysctl hw.snd.default_unit: $ sysctl -d hw.snd.default_unit hw.snd.default_unit: default sound device It defaults to 0, try 1-5 and see if there is any improvement, as you have multiple sound output devices. What programs are you using to test the sound output? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MAC address / per-proto ARP caching in 8.1-RELEASE
On 03/15/11 14:26, Jeremy Chadwick wrote: On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote: Is anyone aware of some sort of facility in either FreeBSD 8.1-RELEASE or the em(4) driver which would cause it to cache MAC addresses / ARP entries for hosts on a per-protocol basis? [snipping remaining details; readers can read it here instead:] [http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/061908.html] The only thing I can think of would be flowtable, but I'm not sure if it's enabled by default on 8.1-RELEASE-p2. You can try the following sysctl to disable it (I would recommend setting this in sysctl.conf and rebooting; I don't know what happens in the case you set it on a live system that's already experiencing the MAC issue you describe). net.inet.flowtable.enable=0 Details: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf I gave this a shot again this morning. It's definitely related to the flowtable: [spolyack@web01 ~]$ time host web00.lab00 ; sudo sysctl net.inet.flowtable.enable=0 ; time host web00.lab00 ;; connection timed out; no servers could be reached real0m10.017s user0m0.000s sys0m0.008s net.inet.flowtable.enable: 1 - 0 web00.lab00 has address 10.0.1.129 real0m0.069s user0m0.000s sys0m0.003s I'm still curious as to why this is only breaking new outgoing UDP traffic. New TCP connections aren't affected in the same way at all. There also does not seem to be any relevant changes to flowtable code between 8.1-RELEASE and 8.2-RELEASE or 8-STABLE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
MAC address / per-proto ARP caching in 8.1-RELEASE
Is anyone aware of some sort of facility in either FreeBSD 8.1-RELEASE or the em(4) driver which would cause it to cache MAC addresses / ARP entries for hosts on a per-protocol basis? We've been doing some testing with new routers, and almost every time we switch them in or out our FreeBSD machines get stuck sending UDP DNS requests to the MAC address of the old default gateway in complete disregard for the current contents of the ARP table. New TCP connections do not seem to be affected: [spolyack@web01 ~]$ uname -a FreeBSD web01 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #3: Mon Dec 6 08:58:21 EST 2010 root@web01:/usr/obj/usr/src/sys/WEB-AMD64 amd64 Current ARP table after the router replacement, the default gateway is 10.0.1.254, which it has the correct new MAC address for already: [spolyack@web01 ~]$ arp -an ? (10.0.1.17) at 00:0c:29:47:74:3a on em2 permanent [ethernet] ? (10.0.1.130) at 00:0c:29:47:74:26 on em0 permanent [ethernet] ? (10.0.1.254) at 00:a0:c9:00:01:01 on em0 expires in 915 seconds [ethernet] ? (10.0.0.17) at 00:0c:29:47:74:30 on em1 permanent [ethernet] ? (10.0.0.15) at 00:0c:29:47:74:30 on em1 permanent [ethernet] ? (10.0.0.11) at 00:0c:29:47:74:30 on em1 permanent [ethernet] ? (10.0.0.2) at 00:1f:a0:10:28:70 on em1 expires in 1162 seconds [ethernet] ? (10.0.0.1) at 00:1f:a0:10:28:70 on em1 expires in 943 seconds [ethernet] tcpdump shows the DNS requests heading to the *old* router's MAC address despite the contents of the ARP table: [spolyack@web01 ~]$ sudo tcpdump -i em0 -s 256 -vvv -e -n -ttt 'port 53' tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 256 bytes 00:00:00.00 00:0c:29:47:74:26 54:75:d0:a3:7c:8c, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 64, id 55590, offset 0, flags [none], proto UDP (17), length 72) 10.0.1.130.52419 10.0.2.80.53: [bad udp cksum fdc5!] 52051+ A? db-testing-lab. (44) [spolyack@web01 ~]$ arp -an | grep 54:75:d0 [spolyack@web01 ~]$ Using telnet to form a TCP connection to port 53 on the same DNS server which the above UDP requests are headed to works just fine: [spolyack@web01 ~]$ telnet 10.0.2.80 53 Trying 10.0.2.80... Connected to 10.0.2.80. Escape character is '^]'. 00:03:43.272134 00:0c:29:47:74:26 00:a0:c9:00:01:01, ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl 64, id 24383, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.130.20130 10.0.2.80.53: Flags [S], cksum 0x0353 (incorrect - 0xf74d), seq 2674341615, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 60433610 ecr 0], length ... Even after the above, standard UDP DNS requests are still headed to the old default gateway MAC address. tcpdumping and looking at ARP requests/responses doesn't show any traces of the old MAC address either. The switch which connects the server and router doesn't have any entries referencing the old router's MAC address anywhere either. I'm assuming this isn't related to the new flowtable features included in 8.x, since they appear to function on a 4-tuple of src addr, src port, dst addr, and dst port, which isn't going to match for new DNS requests. If anyone has any ideas or suggestions on what additional data I can grab, I'd be happy to investigate further, but I've run out of ideas here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MAC address / per-proto ARP caching in 8.1-RELEASE
On 03/15/11 14:26, Jeremy Chadwick wrote: On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote: Is anyone aware of some sort of facility in either FreeBSD 8.1-RELEASE or the em(4) driver which would cause it to cache MAC addresses / ARP entries for hosts on a per-protocol basis? [snipping remaining details; readers can read it here instead:] [http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/061908.html] The only thing I can think of would be flowtable, but I'm not sure if it's enabled by default on 8.1-RELEASE-p2. You can try the following sysctl to disable it (I would recommend setting this in sysctl.conf and rebooting; I don't know what happens in the case you set it on a live system that's already experiencing the MAC issue you describe). net.inet.flowtable.enable=0 Details: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf It looks like it is enabled by default on 8.1-RELEASE. Here's the net.inet.flowtable tree from the box in question: [spolyack@web00 ~]$ sysctl net.inet.flowtable net.inet.flowtable.stats: table name: ipv4 collisions: 1 allocated: 0 misses: 20013 max_depth: 0 free_checks: 377953 frees: 19993 hits: 69519580 lookups: 69539593 net.inet.flowtable.nmbflows: 50176 net.inet.flowtable.tcp_expire: 86400 net.inet.flowtable.fin_wait_expire: 600 net.inet.flowtable.udp_expire: 300 net.inet.flowtable.syn_expire: 300 net.inet.flowtable.enable: 1 net.inet.flowtable.debug: 0 I'm planning on setting net.inet.flowtable.debug=1 next time we see this behavior, but from looking at the code, it looks like we might have to rebuild with -DFLOWTABLE_DEBUG to get really useful information. It's too bad that there is not yet a method to dump the contents of the flowtable. Thanks for the suggestion. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Keyboard repeat issues with Dell Optiplex 980s
On 01/19/11 08:48, Steve Polyack wrote: On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, enter) for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Try adding the following to /boot/loader.conf then reboot and see if the excessive repeat behaviour changes: hint.kbdmux.0.disabled=1 It would also help if you would state exactly what brand/model of keyboard is used. Yes, believe it or not, it matters. dmesg output would be helpful in this case. The keyboard is also a Dell model - model KB1421, or listed as Dell QuiteKey Keyboard under dmesg. The same keyboard does not exhibit the strange behavior when used with the older model of tower (Optiplex 960). I'll reboot today with the loader.conf hint you provided. I'll let you guys know if it helps. Thanks! I forgot to attach my dmesg - here it is! Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RC2 #1: Mon Jan 17 12:10:53 EST 2011 root@galvatron:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2660.02-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4082315264 (3893 MB) ACPI APIC Table: DELL B11K FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: DELL B11Kon motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge irq 16 at device 3.0 on pci0 pci1: PCI bus on pcib1 vgapci0: VGA-compatible display port 0xdc80-0xdcff mem 0xf600-0xf6ff,0xe000-0xefff,0xf000-0xf1ff irq 16 at device 0.0 on pci1 nvidia0: GeForce GT 330 on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] hdac0: NVidia (Unknown) High Definition Audio Controller mem 0xf7dfc000-0xf7df irq 17 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pci0: base peripheral at device 8.0 (no driver attached) pci0: base peripheral at device 8.1 (no driver attached) pci0: base peripheral at device 8.2 (no driver attached) pci0: base peripheral at device 16.0 (no driver attached) pci0
Re: Keyboard repeat issues with Dell Optiplex 980s
On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, enter) for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Try adding the following to /boot/loader.conf then reboot and see if the excessive repeat behaviour changes: hint.kbdmux.0.disabled=1 It would also help if you would state exactly what brand/model of keyboard is used. Yes, believe it or not, it matters. dmesg output would be helpful in this case. The keyboard is also a Dell model - model KB1421, or listed as Dell QuiteKey Keyboard under dmesg. The same keyboard does not exhibit the strange behavior when used with the older model of tower (Optiplex 960). I'll reboot today with the loader.conf hint you provided. I'll let you guys know if it helps. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Keyboard repeat issues with Dell Optiplex 980s
On 01/19/11 08:48, Steve Polyack wrote: On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, enter) for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Try adding the following to /boot/loader.conf then reboot and see if the excessive repeat behaviour changes: hint.kbdmux.0.disabled=1 It would also help if you would state exactly what brand/model of keyboard is used. Yes, believe it or not, it matters. dmesg output would be helpful in this case. The keyboard is also a Dell model - model KB1421, or listed as Dell QuiteKey Keyboard under dmesg. The same keyboard does not exhibit the strange behavior when used with the older model of tower (Optiplex 960). I'll reboot today with the loader.conf hint you provided. I'll let you guys know if it helps. Thanks! The problem still exists with the kbdmux.0.disabled hint. It definitely took effect, as there is no longer a /dev/kbdmux0, and dmesg lists the refusal to register the kbdmux module. Any other ideas? We've tried playing with the hw.usb.ehci.lostinrbug and hw.usb.ehci.no_hs sysctls, but they don't make a difference either. Looking at the ehci(4) man page, this sticks out at me: BUGS The driver is not finished and is quite buggy. There is currently no support for isochronous transfers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Keyboard repeat issues with Dell Optiplex 980s
We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, enter) for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: out of HDD space - zfs degraded
On 10/2/2010 10:04 PM, Dan Langille wrote: On 10/2/2010 7:50 PM, Jeremy Chadwick wrote: On Sat, Oct 02, 2010 at 07:23:16PM -0400, Dan Langille wrote: On 10/2/2010 6:36 PM, Jeremy Chadwick wrote: On Sat, Oct 02, 2010 at 06:09:25PM -0400, Dan Langille wrote: On 10/2/2010 10:19 AM, Jeremy Chadwick wrote: On Sat, Oct 02, 2010 at 09:43:30AM -0400, Dan Langille wrote: Overnight I was running a zfs send | zfs receive (both within the same system / zpool). The system ran out of space, a drive went off line, and the system is degraded. This is a raidz2 array running on FreeBSD 8.1-STABLE #0: Sat Sep 18 23:43:48 EDT 2010. The following logs are also available at http://www.langille.org/tmp/zfs-space.txt- no line wrapping This is what was running: # time zfs send storage/bac...@transfer | mbuffer | zfs receive storage/compressed/bacula-mbuffer in @ 0.0 kB/s, out @ 0.0 kB/s, 3670 GB total, buffer 100% fullcannot receive new filesystem stream: out of space mbuffer: error: outputThread: error writing tostdoutat offset 0x395917c4000: Broken pipe summary: 3670 GByte in 10 h 40 min 97.8 MB/s mbuffer: warning: error during output tostdout: Broken pipe warning: cannot send 'storage/bac...@transfer': Broken pipe real640m48.423s user8m52.660s sys 211m40.862s Looking in the logs, I see this: Oct 2 00:50:53 kraken kernel: (ada0:siisch0:0:0:0): lost device Oct 2 00:50:54 kraken kernel: siisch0: Timeout on slot 30 Oct 2 00:50:54 kraken kernel: siisch0: siis_timeout is 0004 ss 4000 rs 4000 es sts 801f0040 serr Oct 2 00:50:54 kraken kernel: siisch0: Error while READ LOG EXT Oct 2 00:50:55 kraken kernel: siisch0: Timeout on slot 30 Oct 2 00:50:55 kraken kernel: siisch0: siis_timeout is 0004 ss 4000 rs 4000 es sts 801f0040 serr Oct 2 00:50:55 kraken kernel: siisch0: Error while READ LOG EXT Oct 2 00:50:56 kraken kernel: siisch0: Timeout on slot 30 Oct 2 00:50:56 kraken kernel: siisch0: siis_timeout is 0004 ss 4000 rs 4000 es sts 801f0040 serr Oct 2 00:50:56 kraken kernel: siisch0: Error while READ LOG EXT Oct 2 00:50:57 kraken kernel: siisch0: Timeout on slot 30 Oct 2 00:50:57 kraken kernel: siisch0: siis_timeout is 0004 ss 4000 rs 4000 es sts 801f0040 serr Oct 2 00:50:57 kraken kernel: siisch0: Error while READ LOG EXT Oct 2 00:50:58 kraken kernel: siisch0: Timeout on slot 30 Oct 2 00:50:58 kraken kernel: siisch0: siis_timeout is 0004 ss 4000 rs 4000 es sts 801f0040 serr Oct 2 00:50:58 kraken kernel: siisch0: Error while READ LOG EXT Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage path=/dev/gpt/disk06-live offset=270336 size=8192 error=6 Oct 2 00:50:59 kraken kernel: (ada0:siisch0:0:0:0): Synchronize cache failed Oct 2 00:50:59 kraken kernel: (ada0:siisch0:0:0:0): removing device entry Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage path=/dev/gpt/disk06-live offset=2000187564032 size=8192 error=6 Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage path=/dev/gpt/disk06-live offset=2000187826176 size=8192 error=6 $ zpool status pool: storage state: DEGRADED scrub: scrub in progress for 5h32m, 17.16% done, 26h44m to go config: NAME STATE READ WRITE CKSUM storage DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 gpt/disk01-live ONLINE 0 0 0 gpt/disk02-live ONLINE 0 0 0 gpt/disk03-live ONLINE 0 0 0 gpt/disk04-live ONLINE 0 0 0 gpt/disk05-live ONLINE 0 0 0 gpt/disk06-live REMOVED 0 0 0 gpt/disk07-live ONLINE 0 0 0 $ zfs list NAMEUSED AVAIL REFER MOUNTPOINT storage6.97T 1.91T 1.75G /storage storage/bacula 4.72T 1.91T 4.29T /storage/bacula storage/compressed 2.25T 1.91T 46.9K /storage/compressed storage/compressed/bacula 2.25T 1.91T 42.7K /storage/compressed/bacula storage/pgsql 5.50G 1.91T 5.50G /storage/pgsql $ sudo camcontrol devlist Password: Hitachi HDS722020ALA330 JKAOA28A at scbus2 target 0 lun 0 (pass1,ada1) Hitachi HDS722020ALA330 JKAOA28A at scbus3 target 0 lun 0 (pass2,ada2) Hitachi HDS722020ALA330 JKAOA28A at scbus4 target 0 lun 0 (pass3,ada3) Hitachi HDS722020ALA330 JKAOA28A at scbus5 target 0 lun 0 (pass4,ada4) Hitachi HDS722020ALA330 JKAOA28A at scbus6 target 0 lun 0 (pass5,ada5) Hitachi HDS722020ALA330 JKAOA28A at scbus7 target 0 lun 0 (pass6,ada6) ST380815AS 4.AABat scbus8 target 0 lun 0 (pass7,ada7) TSSTcorp CDDVDW SH-S223C SB01 at scbus9 target 0 lun 0 (cd0,pass8) WDC WD1600AAJS-75M0A0 02.03E02 at scbus10 target 0 lun 0
Re: NFS 75 second stall
On 07/01/10 15:23, Garrett Cooper wrote: On Thu, Jul 1, 2010 at 11:51 AM, alan bryanalan.br...@yahoo.com wrote: --- On Thu, 7/1/10, Garrett Cooperyanef...@gmail.com wrote: From: Garrett Cooperyanef...@gmail.com Subject: Re: NFS 75 second stall To: alan bryanalan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 11:13 AM On Thu, Jul 1, 2010 at 11:01 AM, alan bryanalan.br...@yahoo.com wrote: Setup: server - FreeBSD 8-stable from today. 2 UFS dirs exported via NFS. client - FreeBSD 8.0-Release. Running a test php script that copies around various files to/from 2 separate NFS mounts. Situation: script is started (forked to do 20 simultaneous runs) and 20 1GB files are copied to the NFS dir which works fine. When it then switches to reading those files back and simultaneously writing to the other NFS mount I see a hang of 75 seconds. If I do an ls -l on the NFS mount it hangs too. After 75 seconds the client has reported: nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again and then things start working again. The server was originally FreeBSD 8.0-Release also but was upgraded to the latest stable to see if this issue could be avoided. # nfsstat -s -W -w 1 GtAttr Lookup Rdlink Read Write Rename Access Rddir 0 0 0222257 0 0 0 0 0 0178135 0 0 0 0 0 0 85127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... for 75 rows of all zeros 0 0 0272266 0 0 0 0 0 0167165 0 0 0 I also tried runs with 15 simultaneous processes and 25. 15 processes gave only about a 5 second stall but 25 gave again the same 75 second stall. Further, I tested with 2 mounts to the same server but from ZFS filesytems with the exact same stall/timeout periods. So, it doesn't appear to matter what the underlying filesystem is - it's something in NFS or networking code. Any ideas on what's going on here? What's causing the complete stall period of zero NFS activity? Any flaws with my testing methods? Thanks for any and all help/ideas. What network driver are you using? Have you tried tcpdumping the packets? -Garrett I'm using igb currently but have also used em. I have not tried tcpdumping the packets yet on this test. Any suggestions on things to look out for (I'm not that familiar with that whole process). Which brings up another point - I'm using TCP connections for NFS, not UDP. Is the net.inet.tcp.tso sysctl enabled or not? What about rxcsum and txcsum? Thanks, -Garrett We're occaisionally seeing these same types of stalls (+ repeated is not responding is alive again messages in quick succession). We're seeing it only on our 8.1-RELEASE systems against a variety of NFS servers (6.3-RELEASE, 7.2-RELEASE, and 8-STABLE from before the release of 8.1). We also see it happen with a variety of client hardware and network adapters (em, bce, bge); the only common denominator is 8.1-RELEASE on the clients. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On 07/15/10 13:31, Michael Tuexen wrote: On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: It may have gone in before the RELENG_8_1 tag/branch occurred? SVN r209309 Jacks's change went into stable/8 on June 18: Also, did anyone provide feedback on SVN r209959 to head/sys/dev/e1000/if_em.c ? It's saying 8.1 MFC, so you might want to ask people to test that on stable/8 then expedite the 8.1 MFC as well. Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from stable/8 anyway. There is no need for re@ approval to MFC it into stable/8. As Brian stated, the change has already been MFC'd into stable/8 (June 18th) with the following comment from Jack: MFC to RELENG8.1 asap Steve Best regards Michael ~BAS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Dell PowerEdge Virtual Media
On 12/08/09 12:41, Jeff Blank wrote: Hi, I'm having a little trouble using the virtual media function of Dell's PowerEdge R-series (R710 in this case) iDRAC6 under FreeBSD (7.1, 8.0). This is presented as /dev/cd0, a USB/SCSI device, I guess. This is in the dmesg buffer when I boot up the existing 7.1 installation with the virtual optical drive mapped to the 8.0-RELEASE amd64 DVD image: We're having some similar issues with our older PowerEdge 1850s (DRAC4). Things were alright on 6.3-RELEASE, but now there is a large hangup when trying to install 8.0-RELEASE: We see ~ 30x of these in dmesg: acd1: WARNING - READ_TOC read data overrun 2012 Followed by this in sysinstall: The disc in your drive looks more like an audio disc than a FreeBSD Release (1). The DRAC Virtual Media and physical CDROM drives are probed like this in dmesg: acd1: DVR VIRTUALCDROM DRIVE/ at ata2-slave PIO3 acd0: CDROM TEAC CD-ROM CD-224E/K.9A This is with the latest DRAC firmware available from Dell. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.0 kmem map too small
On 05/10/10 11:55, Mike Andrews wrote: On 5/5/10 11:19 AM, Freddie Cash wrote: On Tue, May 4, 2010 at 11:32 PM, Giulio Ferroau...@zirakzigil.org wrote: Giulio Ferro wrote: Thanks, I'll try these settings. I'll keep you posted. Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... I'm really astounded at how unstable zfs is, it's causing me a lot of problem. Why isn't it stated in the handbook that zfs isn't up to production yet? As with everything related to computers, it all depends on your uses. Sorry to semi-hijack this, but... I'm also running into frequent kmem_map too small panics on 8-STABLE, such as: panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocated panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocated panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocated panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocated (those are over the course of 3-4 days) On this specific system, it has 32 GB physical memory and has vfs.zfs.arc_max=2G and vm.kmem_size=64G in /boot/loader.conf. The latter was added per earlier suggestions on this list, but appears to be ignored as sysctl vm.kmem_size returns about 2 GB (2172452864) anyway. As Artem stated in another reply, you will need to set vm.kmem_size slightly under 2x the physical memory. The kernel will default to 2GB if you pass this limit. 1.5x physical memory size should be sufficient, so try 48G and verify that it gets set correctly on the next boot. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.0 kmem map too small
On 05/05/10 10:12, Ben Kelly wrote: On May 5, 2010, at 9:33 AM, Pawel Jakub Dawidek wrote: On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: On 05.05.2010 09:52, Jeremy Chadwick wrote: Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... Did you set both vm.kmem_size and vfs.zfs.arc_max, setting the latter to something *less* than vm.kmem_size? Yes. After your suggestion, I set vfs.zfs.arc_max: 3758096384 vm.kmem_size: 4G Now: vfs.zfs.arc_max: 3758096384 vm.kmem_size: 6392119296 Could you try to track down the commit that is causing your problems? Could you try 8-STABLE kernel from before r206815? Are others generally able to run ARC values so close to kmem size? My experience has been that you really need the ARC to be much smaller than the kmem limit (like 25% or less) due to fragmentation of kmem_map. On a system here with 8GB of RAM and a very large zpool consisting of multiple zdevs, little tuning was needed. The system is running 8-STABLE(amd64) as of a month or two ago. The only things I have set in /boot/loader.conf are: vm.kmem_size=12G vfs.zfs.arc_max=4G Setting kmem_size to 12G came from a combination of recommendations I saw in various mailing list posts (you can probably dig them up). Setting it to the physical memory size was the initial recommendation, while others recommended 1.5x physical memory size to help prevent fragmentation/wasted space in kmem. Regardless, this has served us quite well for the ~6 months the system has been in use. It has never crashed, even under intensive multi-threaded benchmarking. -Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS (zpool) doesn't detect failed drive
On 05/05/10 10:56, Harald Schmalzbauer wrote: Harald Schmalzbauer schrieb am 05.05.2010 14:41 (localtime): Hello, one drive of my mirror failed today, but 'zpool staus' shows it online. Every process using a ZFS mount hangs. Also 'zpool offline /dev/ad1' hangs infinitely. ... Sorry, I made an error with zpool create. Somehow the little word mirror must have been lost. So the pool wasn't a mirror but a stripe. Then of course I can't make one vdev offline. Sorry for the noise. But I took the opportunity to do some tests with that failing drive and created a _real_ mirror. That works without failures, but using the mirror again leads to: ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ata3: port is not ready (timeout 1ms) tfd = 0080 ata3: hardware reset timeout ad1: FAILURE - device detached Now zpool reporsts the vdev ad1 still online although it has been detached and 'atacontrol list' doesn't show it anymore: zpool status pool: URUBAmirrorP1 state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: none requested config: NAMESTATE READ WRITE CKSUM URUBAmirrorP1 ONLINE 0 0 0 mirrorONLINE 0 0 0 ad1 ONLINE 3 302K 0 ad2 ONLINE 0 0 0 errors: No known data errors atacontrol list ATA channel 2: Master: ad0 TRANSCEND/20090520 SATA revision 1.x Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: ad2 SAMSUNG HD154UI/1AG01118 SATA revision 2.x Slave: no device present ATA channel 5: Master: ad3 ST3750640NS/3.AEG SATA revision 1.x Slave: no device present How should such a failure be handled? Do I have to manually mark the drive offline for zpool? Thanks, -Harry You may want to try newer controller drivers like ahci(4) if possible. Otherwise, building the kernel with ATA_CAM may accomplish something similar. I'm not sure, but I'm speculating that the newer ATA/CAM system may feed the proper notifications back to the ZFS systems. I use many drives on the siis(4) driver, which is CAM-enabled, and haven't had any issues. However, I have not had an outright drive failure. I do recall testing situations where we would yank a working drive, and I seem to remember it working correctly after the last set of CAM improvements. It may not be something you can try on a production system, but if you can experiment, it's worth a shot. Note that your device names WILL change to adaX instead of adX. I would definitely recommend you glabel(8) and create the zpool/zdevs using the glabel devices instead to circumvent any future problems associated with device numbering. Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
rc.d/rc.subr support for multiple FIBs
With multiple FIB support generally available in FreeBSD 8.0-RELEASE it would be quite beneficial to have the ability to build routing tables in secondary FIBs as well as start certain applications in certain FIBs from within rc.conf(5). I've done some poking around and came across two PRs which implement exactly what I'm looking for: http://www.freebsd.org/cgi/query-pr.cgi?pr=132483 http://www.freebsd.org/cgi/query-pr.cgi?pr=132476 My question is whether there are any plans to commit these into -CURRENT and possibly MFC them to a future 8.x-RELEASE. Having multiple FIBs available has been great so far, it goes hand and hand with Multi-IP Jails. The only thing missing are native methods for constructing the routing tables on boot (Yes, there is rc.local, but I don't want to go there...). Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS hot spares
On 03/09/10 05:11, Ivan Voras wrote:
On 03/08/10 19:06, Steve Polyack wrote:
ZFS in FreeBSD lacks at least one major feature from the Solaris
version: hot spares. There is a PR open at
http://www.freebsd.org/cgi/query-pr.cgi?pr=134491, but there hasn't been
any motion/thoughts posted on it since its creation almost one year ago.
I'm aware that on Solaris, hot spare replacement is handled by a few
Solaris-specific daemons, zfs-retire and zfs-diagnose, which both plug
into the Solaris FMA (Fault Management Architecture). Have there been
any thoughts on porting these over or getting something similar running
within FreeBSD? With all of the recent SATA/SAS CAM hotplug work now
committed, it would be nice to have automatic replacement of hot spares
with a future hot-replacement of the failed drive.
On the other side, I'd be interested in hearing if anyone has had
success in rolling their own scripted solution: i.e. something which
polls 'zpool status' looking for failed drives and performing hot-spare
replacements automatically.
You don't have to exactly poll it. See /etc/devd.conf:
# Sample ZFS problem reports handling.
notify 10 {
match system ZFS;
match typezpool;
action logger -p kern.err 'ZFS: failed to load zpool $pool';
};
notify 10 {
match system ZFS;
match typevdev;
action logger -p kern.err 'ZFS: vdev failure, zpool=$pool
type=$type';
};
notify 10 {
match system ZFS;
match typedata;
action logger -p kern.warn 'ZFS: zpool I/O failure,
zpool=$pool error=$zio_err';
};
notify 10 {
match system ZFS;
match typeio;
action logger -p kern.warn 'ZFS: vdev I/O failure,
zpool=$pool path=$vdev_path offset=$zio_offset size=$zio_size
error=$zio_err';
};
notify 10 {
match system ZFS;
match typechecksum;
action logger -p kern.warn 'ZFS: checksum mismatch,
zpool=$pool path=$vdev_path offset=$zio_offset size=$zio_size';
};
I don't really know if these notifications actually work since I don't
have hot-plug test machines, but if they do, this looks like a decent
starting point.
Thanks for the suggestions. I received a similar one from someone
else. If I get time to build a ZFS lab machine then I will certainly
try these out and provide feedback on how they work.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ZFS hot spares
ZFS in FreeBSD lacks at least one major feature from the Solaris version: hot spares. There is a PR open at http://www.freebsd.org/cgi/query-pr.cgi?pr=134491, but there hasn't been any motion/thoughts posted on it since its creation almost one year ago. I'm aware that on Solaris, hot spare replacement is handled by a few Solaris-specific daemons, zfs-retire and zfs-diagnose, which both plug into the Solaris FMA (Fault Management Architecture). Have there been any thoughts on porting these over or getting something similar running within FreeBSD? With all of the recent SATA/SAS CAM hotplug work now committed, it would be nice to have automatic replacement of hot spares with a future hot-replacement of the failed drive. On the other side, I'd be interested in hearing if anyone has had success in rolling their own scripted solution: i.e. something which polls 'zpool status' looking for failed drives and performing hot-spare replacements automatically. Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hardware for home use large storage
On 02/15/10 12:14, Dan Langille wrote: Dan Naumov wrote: On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille d...@langille.org wrote: Dan Naumov wrote: On Sun, 14 Feb 2010, Dan Langille wrote: After creating three different system configurations (Athena, Supermicro, and HP), my configuration of choice is this Supermicro setup: 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) 2. SuperMicro 5046A $750 (+$43 shipping) 3. LSI SAS 3081E-R $235 4. SATA cables $60 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) 6. Xeon W3520 $310 You do realise how much of a massive overkill this is and how much you are overspending? I appreciate the comments and feedback. I'd also appreciate alternative suggestions in addition to what you have contributed so far. Spec out the box you would build. == Case: Fractal Design Define R2 - 89 euro: http://www.fractal-design.com/?view=productprod=32 Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H PSU: Corsair 400CX 80+ - 59 euro: http://www.corsair.com/products/cx/default.aspx RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro == Total: ~435 euro The motherboard has 6 native AHCI-capable ports on ICH9R controller and you have a PCI-E slot free if you want to add an additional controller card. Feel free to blow the money you've saved on crazy fast SATA disks and if your system workload is going to have a lot of random reads, then spend 200 euro on a 80gb Intel X25-M for use as a dedicated L2ARC device for your pool. Based on the Fractal Design case mentioned above, I was told about Lian Lia cases, which I think are great. As a result, I've gone with a tower case without hot-swap. The parts are listed at and reproduced below: http://dan.langille.org/2010/02/15/a-full-tower-case/ 1. LIAN LI PC-A71F Black Aluminum ATX Full Tower Computer Case $240 (from mwave) 2. Antec EarthWatts EA650 650W PSU $80 3. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) 4. Intel S3200SHV LGA 775 Intel 3200 m/b $200 5. Intel Core2 Quad Q9400 CPU $190 6. SATA cables $22 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 8. Kingston ValueRAM 4GB (2 x 2GB) 240-Pin DDR2 SDRAM ECC $97 Total cost is about $1020 with shipping. Plus HDD. No purchases yet, but the above is what appeals to me now. Dan, I'm not sure about that particular card, but we've never seen that great of performance out of the LSI MegaRAID cards that ship with Dell servers as the PERC. The newest incarnations are better, but I would try to get an Areca. The ones we have tested have displayed fantastic performance. They are fairly expensive in comparison, though. If you're using ZFS in place of the RAID on the LSI MegaRAID, I'd instead recommend other simpler SAS cards which are known to have good driver support. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hardware for home use large storage
On 2/15/2010 6:04 PM, Dan Langille wrote: Steve Polyack wrote: On 02/15/10 12:14, Dan Langille wrote: 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 Dan, I'm not sure about that particular card, but we've never seen that great of performance out of the LSI MegaRAID cards that ship with Dell servers as the PERC. The newest incarnations are better, but I would try to get an Areca. The ones we have tested have displayed fantastic performance. They are fairly expensive in comparison, though. If you're using ZFS in place of the RAID on the LSI MegaRAID, I'd instead recommend other simpler SAS cards which are known to have good driver support. Yes, the card will be used as a straight-through and not use for RAID. ZFS will be running raidz for me, possibly raidz2. Given that, I'm not sure if you're suggesting the3 Areca or something else. In addition, I'm not sure what makes a SAS card simpler and supported. Recommendation? Other cards I have considered include: LSI SAS3041E-R 4 port $120 http://www.google.com/products/catalog?q=lsi+sas+pciehl=encid=1824913543877548833sa=title#p SYBA SY-PEX40008 PCI Express SATA II 4 port $60 http://www.newegg.com/Product/Product.aspx?Item=N82E16816124027 LSISAS1064 chipset - SAS3042e http://www.lsi.com/DistributionSystem/AssetDocument/PCIe_3GSAS_UG.pdf SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA Controller Card $99 http://www.newegg.com/Product/Product.aspx?Item=N82E16815121009 All I meant by simpler was that if you're not going to use the RAID portion then you do not have to pay for it. Same goes for SAS - if you're not going to use SAS disks, you only need a SATA controller. The SYBA card you have listed works great with the siis driver (NCQ support). If you don't need SAS support, I think there are Areca cards around $100 that just do SATA w/o RAID. As far as supported, I know that the Areca driver is very good, as is the recently revamped ahci generic and siis drivers. Like I said, those newer LSI cards may be fine, but I've had bad experiences with the PERC4 and PERC5 (/LSI/ MegaRAID SAS 8408E), which are both re-branded LSI MegaRAID cards. They were always very reliable and handled failed disks quite well, but performance was often ... just bad. YMMV. The PERC6 (one of the newer generations) isn't half as bad... If you end up with one of the LSI cards, let us know how it performs ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ZFS ARC being limited below what is defined in /boot/loader.conf
Has anyone had an issue with the ZFS ARC max being limited below what has been defined in /boot/loader.conf? I just upgraded the RAM in a ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing the following in loader.conf: vfs.zfs.arc_max=4096M However, after rebooting, querying the sysctl gives me this: $ sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 1726489600 or about 1.7GB, an odd number that I can't find any references to. For reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB of RAM. The system was previously very stable with 4GB of RAM and a 512MB arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) or any other ZFS tunables. I'd also like to avoid syncing up to the current 8-STABLE if at all possible. Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS ARC being limited below what is defined in /boot/loader.conf
On 02/12/10 13:47, Artem Belevich wrote: On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyackkor...@comcast.net wrote: Has anyone had an issue with the ZFS ARC max being limited below what has been defined in /boot/loader.conf? I just upgraded the RAM in a ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing the following in loader.conf: vfs.zfs.arc_max=4096M However, after rebooting, querying the sysctl gives me this: $ sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 1726489600 or about 1.7GB, an odd number that I can't find any references to. For reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB of RAM. The system was previously very stable with 4GB of RAM and a 512MB arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) or any other ZFS tunables. I'd also like to avoid syncing up to the current 8-STABLE if at all possible. Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Check your vm.kmem_size. Default setting is way too low. Set it to at least double of desired arc size. --Artem I mentioned it briefly, but vm.kmem_size_max was left at the default for amd64. At 330GB it is way above and beyond what will ever be allocated to ARC: $ sysctl vm.kmem_size_max vm.kmem_size_max: 329853485875 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS ARC being limited below what is defined in /boot/loader.conf
This was indeed the issue. I read your first response incorrectly. Thanks a bunch! On 2/12/2010 4:10 PM, Artem Belevich wrote: vm.kmem_size_max/vm.kmem_size_min define the range vm.kmem_size can be set to. vm_kmem_size specifies the actual kmem size. ARC size in turn limited by vm.kmem_size. If you want to bump ARC size, you do need to bump vm.kmem_size. --Artem On Fri, Feb 12, 2010 at 11:36 AM, Steve Polyackkor...@comcast.net wrote: On 02/12/10 13:47, Artem Belevich wrote: On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyackkor...@comcast.net wrote: Has anyone had an issue with the ZFS ARC max being limited below what has been defined in /boot/loader.conf? I just upgraded the RAM in a ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing the following in loader.conf: vfs.zfs.arc_max=4096M However, after rebooting, querying the sysctl gives me this: $ sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 1726489600 or about 1.7GB, an odd number that I can't find any references to. For reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB of RAM. The system was previously very stable with 4GB of RAM and a 512MB arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) or any other ZFS tunables. I'd also like to avoid syncing up to the current 8-STABLE if at all possible. Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Check your vm.kmem_size. Default setting is way too low. Set it to at least double of desired arc size. --Artem I mentioned it briefly, but vm.kmem_size_max was left at the default for amd64. At 330GB it is way above and beyond what will ever be allocated to ARC: $ sysctl vm.kmem_size_max vm.kmem_size_max: 329853485875 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hardware for home use large storage
On 2/10/2010 12:02 AM, Dan Langille wrote: Trying to make sense of stuff I don't know about... Matthew Dillon wrote: AHCI on-motherboard with equivalent capabilities do not appear to be in wide distribution yet. Most AHCI chips can do NCQ to a single target (even a single target behind a PM), but not concurrently to multiple targets behind a port multiplier. Even though SATA bandwidth constraints might seem to make this a reasonable alternative it actually isn't because any seek heavy activity to multiple drives will be serialized and perform EXTREMELY poorly. Linear performance will be fine. Random performance will be horrible. Don't use a port multiplier and this goes away. I was hoping to avoid a PM and using something like the Syba PCI Express SATA II 4 x Ports RAID Controller seems to be the best solution so far. http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8s=electronicsqid=1258452902sr=1-22 Dan, I can personally vouch for these cards under FreeBSD. We have 3 of them in one system, with almost every port connected to a port multiplier (SiI5xxx PMs). Using the siis(4) driver on 8.0-RELEASE provides very good performance, and supports both NCQ and FIS-based switching (an essential for decent port-multiplier performance). One thing to consider, however, is that the card is only single-lane PCI-Express. The bandwidth available is only 2.5Gb/s (~312MB/sec, slightly less than that of the SATA-2 link spec), so if you have 4 high-performance drives connected, you may hit a bottleneck at the bus. I'd be particularly interested if anyone can find any similar Silicon Image SATA controllers with a PCI-E 4x or 8x interface ;) It should be noted that while hotswap is supported with silicon image chipsets and port multiplier enclosures (which also use Sili chips in the enclosure), the hot-swap capability is not anywhere near as robust as you would find with a more costly commercial SAS setup. SI chips are very poorly made (this is the same company that went bust under another name a few years back due to shoddy chipsets), and have a lot of on-chip hardware bugs, but fortunately OSS driver writers (linux guys) have been able to work around most of them. So even though the chipset is a bit shoddy actual operation is quite good. However, this does mean you generally want to idle all activity on the enclosure to safely hot swap anything, not just the drive you are pulling out. I've done a lot of testing and hot-swapping an idle disk while other drives in the same enclosure are hot is not reliable (for a cheap port multiplier enclosure using a Sili chip inside, which nearly all do). I haven't had such bad experience as the above, but it is certainly a concern. Using ZFS we simply 'offline' the device, pull, replace with a new one, glabel, and zfs replace. It seems to work fine as long as nothing is accessing the device you are replacing (otherwise you will get a kernel panic a few minutes down the line). m...@freebsd.org has also committed a large patch set to 9-CURRENT which implements proper SATA/AHCI hot-plug support and error-recovery through CAM. -Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
On 01/22/10 11:48, Freddie Cash wrote: On Fri, Jan 22, 2010 at 2:23 AM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: Alexander Motin schrieb am 19.01.2010 17:12 (localtime): ... Patch can be found here: http://people.freebsd.org/~mav/cam-ata.20100119.patch Feedback as always welcome. Again, thanks a lot for your ongoing great work! The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't care. Otherwise I couldn't find any problems. The system detects reinserted SATA drives on ICH9 fine. This was tested on a zfs backup server which went to the backbone yesterday, so I can't physically remove any devices any more for testing... But I had some questions about zfs raidz states. I think that isn't a matter of atacam but if I removed one disk, zpool status still showed me the ada3 device online. After reinserting (and proper detection/initialisazion with cam, ada3 was present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O errors. I coudn't get the device into the pool again, no matter what I tried. Only rebooting the machine helped. Then I could clean and scrub. What are the needed steps to provide a reinsterted hard disk to geom? With the latest patches I don't need to issue any reset/rescan comman, right? So it's a zfs problem, right? My mistake in understanding? In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE controller), you have to zpool offlinepool device while the drive is unplugged, before you can re-insert the same disk or a different disk. Without doing that step, it's very hard to re-insert the same disk, or replace it with a new one, without rebooting. Took me a couple of reboots and drive replacements before I figured that one out. :) I think you can do it without the 'zpool offline pool device' command; I may be wrong, but I believe you can use 'zpool replace' to accomplish what you're trying to do. i.e. if you have a bad drive ada3, and take it out, then replace it with a new disk, you can issue a 'zpool replace pool /dev/ada3 /dev/ada3' (yes, the same device is specified twice). ZFS should recognize that its a different disk and/or that it is lacking ZFS metadata and begin to resilver the pool onto the new device. If you watch 'zfs status' in the process you'll see something like: raidz1 DEGRADED 0 0 0 label/ada4ONLINE 0 0 0 12.4M resilvered label/ada5ONLINE 0 0 0 12.4M resilvered label/ada6ONLINE 0 0 0 12.3M resilvered replacing DEGRADED 0 0 0 label/ada3/old UNAVAIL 0 595 0 cannot open label/ada3 ONLINE 0 0 0 9.74G resilvered Try it out and let me know if it works for you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Panic possibly related to glabel/geom and siis(4)
I have a system running 8.0-PRERELEASE with multiple drives and SATA port multipliers (siis controllers and PMPs). All of the attached drives are labeled via glabel(8) and then included into a ZFS pool. During some testing to determine how the system would react to a dead drive (simulated by physically removing a drive during operation), I was able to produce a panic. Now, I know that the SATA PMP and siis(4) code to handle and recover from device errors is incomplete, but I believe the crash may be particular to using glabel'd drives. Basically, after removing a drive while the zpool is in use and issues 'camcontrol reset' and 'rescan' on the appropriate bus, the physical device associated with the drive disappears. In this case: (pass5:siisch7:0:15:0): lost device (pass5:siisch7:0:15:0): removing device entry (ada2:siisch7:0:0:0): lost device and /dev/ada2 disappears. However, the associated glabel /dev/label/bigdisk07 remains. Since my ZFS pool is created based on the drive glabels, I believe this is why ZFS never notices the drives disappear either. Do glabels typically go away after a physical device is lost? Should this not be the case? After some runtime with the physical device missing, a kernel panic is produced: ada2:siisch7:0:0:0): Synchronize cache failed (ada2:siisch7:0:0:0): removing device entry Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 14 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0x8035f375 stack pointer = 0x28:0xff86db60 frame pointer = 0x28:0xff86db70 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 = 2 (g_event) [thread pid 2 tid 100014 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db bt Tracing pid 2 tid 100014 td 0xff00014d4ab0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vdev_geom_release() at vdev_geom_release+0x33 vdev_geom_orphan() at vdev_geom_orphan+0x15c g_run_events() at g_run_events+0x104 g_event_procbody() at g_event_procbody+0x55 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff86dd30, rbp = 0 --- I'm open to try patches and other suggestions. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for SAS/SATA non-RAID adapters
Freddie Cash wrote: On Tue, Nov 17, 2009 at 11:43 PM, Rink Springer r...@freebsd.org wrote: On Tue, Nov 17, 2009 at 08:38:21PM -0800, Freddie Cash wrote: I've also found a couple of Areca cards (PCI-X, non-RAID/PCIe RAID), and have heard good things about Areca support in FreeBSD. Any comments on their quality/performance/reliability? I have got an Areca ARC-1110 4x SATA2 PCI-X card in my server, and I'm quite impressed with the performance; these cards do very well in terms I/O operations per second and the driver has been rock solid for me. The only downside is that they are quite expensive (but well worth it, IMO) Compared to a 3Ware 9550SXU controller, these are cheap. The Areca is only $500 (open-box) or $700 (new) on newegg.ca. The 3Ware cards are over $1000, with the PCIe versions being over $1200 (which is what started me on this journey -- hardware budgets are getting smaller and smaller each year). We've also tried the Areca cards with FreeBSD - the Areca ARC-1680IX-12-2G PCIe x8 card to be precise. It's a SAS/SATA RAID card. The performance was very impressive. MUCH better than the Dell PERC4/5/6s we were used to. The drivers also seemed to be rock solid (FreeBSD is even listed as a supported OS on the company's website). The feature-set of the card itself is also very rich... The one we tried had its own OOB management via serial port or dedicated 100mbps ethernet jack. It supports endless combinations of RAID arrays, volumes, and SMTP/SNMP alerts. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD and SATA Port Multipliers
Alexander Motin wrote: Steve Polyack wrote: Alexander Motin wrote: You can try this patch against today's HEAD: http://people.freebsd.org/~mav/cam-ata.20091022.patch I tried the patch this morning against a fresh checkout of HEAD. Immediately after boot only one device per PM was detected (I have two hooked up at the moment, 5 drives on one, 1 on the other). However, about two minutes later all of the drives showed up! camcontrol also rescans the entire bus *very* quickly now, and discovers all changes (new/missing disks and port multipliers). Here's some verbose info from /var/log/messages immediately after boot: Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is ss 0800 rs 0800 es sts 801b2000 serr Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout status=0001 Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested What was before that? Can you send me full verbose boot messages? Here's a full dmesg from today using the 10/22/2009 head and patch. It actually failed to detect all but one of 6 drives this time. I'm about to try today's head and patch. I'll let you know how it goes. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #2: Thu Oct 22 10:34:44 EDT 2009 Preloaded elf kernel /boot/kernel/kernel at 0x809e7000. Preloaded /boot/zfs/zpool.cache /boot/zfs/zpool.cache at 0x809e7260. Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133421704 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x9ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x1000 - 0x00093fff, 602112 bytes (147 pages) 0x00a16000 - 0xb60f, 3043926016 bytes (743146 pages) 0xbf78e000 - 0xbf78, 8192 bytes (2 pages) 0x0001 - 0x00013ffe, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: 061909 APIC1420 INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 0097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 0097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 0097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 0097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 0097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 0097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 0097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 0097) ACPI: DMAR 0xbf79e0c0 00120 (v1AMI OEMDMAR 0001 MSFT 0097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 0097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 0097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 0097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 0097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0
Re: FreeBSD and SATA Port Multipliers
Alexander Motin wrote: Steve Polyack wrote: I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 Here's a dmesg from todays head and your patch from this morning. It's still only sensing one disk over the two PMs. Forcing SATA1/1.5Gbps operation didn't change anything. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #4: Mon Oct 26 10:01:55 EDT 2009 Preloaded elf kernel /boot/kernel/kernel at 0x809e7000. Preloaded /boot/zfs/zpool.cache /boot/zfs/zpool.cache at 0x809e7260. Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133419836 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x9ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x1000 - 0x00093fff, 602112 bytes (147 pages) 0x00a16000 - 0xb60f, 3043926016 bytes (743146 pages) 0xbf78e000 - 0xbf78, 8192 bytes (2 pages) 0x0001 - 0x00013ffe, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: 061909 APIC1420 INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 0097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 0097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 0097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 0097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 0097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 0097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 0097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 0097) ACPI: DMAR 0xbf79e0c0 00120 (v1AMI OEMDMAR 0001 MSFT 0097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 0097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 0097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 0097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 0097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's - intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 - intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI - LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 Version 2.0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x1000 VER: 0x00060015 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001000f pcm: 0x00010400 nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: memory null: null device, zero device io: I/O random: entropy source, Software, Yarrow acpi0: NEC on motherboard PCIe: Memory Mapped configuration base @ 0xe000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 16 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 - bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 - bus 0 dev 31 func 0 ACPI timer: 1/1 1/0 1/0 1/2 0/459 1/2 1/0 1/0 1/0 1/0 - 9 Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pci_link0:Index IRQ Rtd Ref IRQs Initial Probe
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: Alexander Motin wrote: Steve Polyack wrote: I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 Here's a dmesg from todays head and your patch from this morning. It's still only sensing one disk over the two PMs. Forcing SATA1/1.5Gbps operation didn't change anything. I should also note that if I do a 'camcontrol rescan', the first PM (with 5 physical drives attached, none detected) will vanish. Physically unplugging and reconnecting the device does the same. COMMAND=/sbin/camcontrol rescan all siisch0: Timeout on slot 29 siisch0: siis_timeout is ss 2000 rs 2000 es sts 801f2000 serr siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=0123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=0001 (aprobe0:siisch0:0:15:0): Command timed out (aprobe0:siisch0:0:15:0): error 5 (aprobe0:siisch0:0:15:0): Retries Exhausted (pass0:siisch0:0:15:0): lost device (pass0:siisch0:0:15:0): removing device entry (pmp0:siisch0:0:15:0): lost device siisch0: Timeout on slot 30 siisch0: siis_timeout is ss 4000 rs 4000 es sts 801f serr siisch0: ready wait time=1ms siisch0: ready wait time=1ms (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=0123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=0001 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command (aprobe0:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 1706 PMP freeze: 0 PM ports: 5 PM RESET 0 skipping PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done PM connect done PM status: 0 - 0123 PM status: 1 - PM status: 2 - PM status: 3 - PM status: 4 - PMP release: 0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD and SATA Port Multipliers
Alexander Motin wrote: If your conditions permit, you can try to upgrade to recent HEAD to look how will it go with newer code. I am periodically merging my work there from Perforce. Also I am going to generate new test patch for HEAD, which includes reworked PMP support, tomorrow. You can try this patch against today's HEAD: http://people.freebsd.org/~mav/cam-ata.20091022.patch I tried the patch this morning against a fresh checkout of HEAD. Immediately after boot only one device per PM was detected (I have two hooked up at the moment, 5 drives on one, 1 on the other). However, about two minutes later all of the drives showed up! camcontrol also rescans the entire bus *very* quickly now, and discovers all changes (new/missing disks and port multipliers). Here's some verbose info from /var/log/messages immediately after boot: Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is ss 0800 rs 0800 es sts 801b2000 serr Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout status=0001 Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested Oct 22 10:52:05 lovepod kernel: siisch0: CONNECT requested Oct 22 10:52:05 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:05 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:05 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:05 lovepod kernel: siisch0: SATA connect time=0ms status=0123 Oct 22 10:52:05 lovepod kernel: siisch0: ready wait time=0ms Oct 22 10:52:05 lovepod kernel: siisch0: SIIS reset done: devices=0001 Oct 22 10:52:33 lovepod kernel: siisch0: Timeout on slot 28 Oct 22 10:52:33 lovepod kernel: siisch0: siis_timeout is ss 1000 rs 1000 es sts 801c2000 serr Oct 22 10:52:33 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:33 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:33 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:33 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:33 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:33 lovepod kernel: siisch0: SATA connect timeout status=0001 Oct 22 10:52:33 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:52:33 lovepod kernel: (aprobe0:siisch0:0:2:0): Command timed out Oct 22 10:52:33 lovepod kernel: (aprobe0:siisch0:0:2:0): error 5 Oct 22 10:52:33 lovepod kernel: (aprobe0:siisch0:0:2:0): Retries Exhausted Oct 22 10:52:33 lovepod kernel: siisch0: DISCONNECT requested Oct 22 10:52:35 lovepod kernel: siisch0: CONNECT requested Oct 22 10:52:35 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:35 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:35 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:35 lovepod kernel: siisch0: SATA connect time=0ms status=0123 Oct 22 10:52:35 lovepod kernel: siisch0: ready wait time=0ms Oct 22 10:52:35 lovepod kernel: siisch0: SIIS reset done: devices=0001 Oct 22 10:53:03 lovepod kernel: siisch0: Timeout on slot 29 Oct 22 10:53:03 lovepod kernel: siisch0: siis_timeout is ss 2000 rs 2000 es sts 801d2000 serr Oct 22 10:53:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:03 lovepod kernel: siisch0: SIIS reset... Oct 22 10:53:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:03 lovepod kernel: siisch0: hardware reset ... Oct 22 10:53:03 lovepod kernel: siisch0: SATA connect timeout status=0001 Oct 22 10:53:03 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:53:03 lovepod kernel: (aprobe0:siisch0:0:3:0): Command timed out Oct 22 10:53:03 lovepod kernel: (aprobe0:siisch0:0:3:0): error 5 Oct 22 10:53:03 lovepod kernel: (aprobe0:siisch0:0:3:0): Retries Exhausted Oct 22 10:53:03 lovepod kernel: siisch0: DISCONNECT requested Oct 22 10:53:05 lovepod kernel: siisch0: CONNECT requested Oct 22 10:53:05 lovepod kernel: siisch0: SIIS reset... Oct 22 10:53:05 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:05 lovepod kernel: siisch0: hardware reset ... Oct 22 10:53:05 lovepod kernel: siisch0: SATA connect time=0ms status=0123 Oct 22 10:53:05 lovepod kernel: siisch0: ready wait time=0ms Oct 22 10:53:05 lovepod kernel: siisch0: SIIS reset done:
Re: FreeBSD and SATA Port Multipliers
Alexander Motin wrote: Have you tried new CAM-based ATA subsystem present in 8.x by siis(4) driver? Work is still in progress there, but it should work with port multipliers much better then previous implementation. Indeed, the siis(4) driver works MUCH better. However, it's still not always detecting every drive if I fill a port multiplier with 5/5 drives. Sometimes it boots up with 4, sometimes with 5. Snippet from the dmesg in my other reply: siisch4: Timeout on slot 25 siisch4: siis_timeout is ss 0200 rs 0200 es sts 80192000 serr (aprobe0:siisch4:0:1:0): SIGNATURE: (aprobe0:siisch4:0:2:0): SIGNATURE: (aprobe0:siisch4:0:3:0): SIGNATURE: (aprobe0:siisch4:0:4:0): SIGNATURE: ada0 at siisch4 bus 0 target 1 lun 0 ada0: ST31500341AS CC1H ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled siisch4 bus 0 target 0 lun 0 is missing here, due to some kind of timeout. The drives are fine and the missing device does not follow a specific physical drive. Lastly, using camcontrol to rescan port multipliers and attached drives only leads to failure. Rescanning everythign simply loses all but one drive attached to each port multiplier. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD and SATA Port Multipliers
I have a system running FreeBSD 8.0-RC1 that contains 3x Sil3124 PCI-E SATA controller cards. Each card has 3x Sil3726 Port Multipliers attached (5 slots per SATA PM). The problem is that the disks are often not all detected by FreeBSD, even though the controller Option ROMs list all of the installed physical disks. Which drive(s) are not detected seems to vary with each boot. All of the port multipliers are detected every boot, it's just the drives which aren't getting probed. I've tried the following patch, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129784 , which may have helped - it picks up 6-8 out of 9 disks, but obviously that's not ideal. The motherboard BIOS version is current, as is the firmware for the SATA controllers. Does anyone have any ideas or other patches that I may try? Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: I have a system running FreeBSD 8.0-RC1 that contains 3x Sil3124 PCI-E SATA controller cards. Each card has 3x Sil3726 Port Multipliers attached (5 slots per SATA PM). The problem is that the disks are often not all detected by FreeBSD, even though the controller Option ROMs list all of the installed physical disks. Which drive(s) are not detected seems to vary with each boot. All of the port multipliers are detected every boot, it's just the drives which aren't getting probed. This was mostly fixed by loading the siis(4) module at boot. However, if I attach 5 drives to a port multiplier board and reboot, only 4 of the drives attached to that port multiplier are detected. From dmesg: siisch4: Timeout on slot 25 siisch4: siis_timeout is ss 0200 rs 0200 es sts 80192000 serr (aprobe0:siisch4:0:1:0): SIGNATURE: (aprobe0:siisch4:0:2:0): SIGNATURE: (aprobe0:siisch4:0:3:0): SIGNATURE: (aprobe0:siisch4:0:4:0): SIGNATURE: ada0 at siisch4 bus 0 target 1 lun 0 ada0: ST31500341AS CC1H ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled ada1 at siisch4 bus 0 target 2 lun 0 ada1: ST31500341AS CC1H ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled ada2 at siisch4 bus 0 target 3 lun 0 ada2: ST31500341AS CC1H ATA/ATAPI-8 SATA 2.x device ada2: 300.000MB/s transfers ada2: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada2: Native Command Queueing enabled ada3 at siisch4 bus 0 target 4 lun 0 ada3: ST31500341AS CC1H ATA/ATAPI-8 SATA 2.x device ada3: 300.000MB/s transfers ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada3: Native Command Queueing enabled The disk at siisch4 bus 0 target 0 lun 0 is what's missing - it looks like there's some kind of timeout during the detection. A 'camcontrol rescan all' does not help. In fact, the camcontrol rescan appears to lose all of the SATA drives attached to port-multipliers with a similar timeout message: siisch4: Timeout on slot 17 siisch4: siis_timeout is 0004 ss 0002 rs 0002 es sts 80112000 serr (ada0:siisch4:0:1:0): lost device (ada0:siisch4:0:1:0): removing device entry siisch4: Timeout on slot 19 siisch4: siis_timeout is 0004 ss 0008 rs 0008 es sts 80132000 serr siisch4: Timeout on slot 20 siisch4: siis_timeout is 0004 ss 0010 rs 0010 es sts 80142000 serr (ada1:siisch4:0:2:0): lost device (ada1:siisch4:0:2:0): removing device entry siisch4: Timeout on slot 21 siisch4: siis_timeout is 0004 ss 0020 rs 0020 es sts 80152000 serr siisch4: Timeout on slot 22 siisch4: siis_timeout is 0004 ss 0040 rs 0040 es sts 80162000 serr (ada2:siisch4:0:3:0): lost device (ada2:siisch4:0:3:0): removing device entry I can provide more info on request. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: What does mfi0: Copy out failed mean?
Václav Haisman wrote: I am getting mfi0: Copy out failed message in logs, usually several times a day. What does it mean? This is FreeBSD 7.2. -- VH I can't tell you exactly what the error message means, but out of curiosity what kind of hardware are you running? A PERC6 controller perhaps? Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: What does mfi0: Copy out failed mean?
Václav Haisman wrote: Steve Polyack wrote: Václav Haisman wrote: I am getting mfi0: Copy out failed message in logs, usually several times a day. What does it mean? This is FreeBSD 7.2. I can't tell you exactly what the error message means, but out of curiosity what kind of hardware are you running? A PERC6 controller perhaps? Yes, mfi0: Dell PERC 6. You may want to contact Scott Long, sco...@freebsd.org, to see if he can help. I believe he's the author/maintainer of the mfi(4) driver. He may be interested in any problems you've seen. I've heard of some other people having issues with PERC6 cards and FreeBSD as well. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Radeon 9250 DRM in 7.2-RELEASE
I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE about a day ago. After the upgrade procedure, I'm having no luck with using DRM in X11. It worked fine before and gave reasonable performance. Now when I start up X with DRI enabled, both of my screens display garbage. The mouse pointer is also not visible. I'm using a PCI Radeon 9250. I can get more details if necessary. I can also try to revert the kernel DRM module code to 7.1. From dmesg: drm2: ATI Radeon RV280 9250 on vgapci2 vgapci2: child drm2 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm2: [ITHREAD] Any ideas or suggestions would be appreciated. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
Paul Schmehl wrote: Read /usr/portsUPDATING wrt xorg. There were major changes in the config file and peripheral detection between 7.1 and 7.2 You need to make sure that both dbus and hald are running. Remove the mouse and keyboard sections from your xorg.conf file. They are no longer needed. Make sure to remove any line that references RgbPath. This may help to get the mouse working (ignore the DontZap line): Section ServerFlags Option DontZap No Option AllowEmptyInput No EndSection This should get DRI working: Section DRI Group 0 Mode 0660 EndSection I tackled the above when I upgraded Xorg to 7.4 months ago, independently of any FreeBSD release updates. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: Why is this drm2? Is this a multicard setup? Multicard doesn't work right now. If you aren't using more than one card, can you disable whatever else drm is attaching to? robert. This is something funny I had to deal with initially. There is *no* drm0 or drm1 being probed. Consequently, there is only one entry in /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a source for DRM (probably due to what you said). In the past, I have symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work correctly, utilizing DRM. I have an onboard Intel VGA device, but as far as I know it is disabled. I can double check, but as I've noted things have worked fine with the above tweak until upgrading to 7.2-RELEASE. Thanks, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote: This is something funny I had to deal with initially. There is *no* drm0 or drm1 being probed. Consequently, there is only one entry in /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a source for DRM (probably due to what you said). In the past, I have symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work correctly, utilizing DRM. I have an onboard Intel VGA device, but as far as I know it is disabled. I can double check, but as I've noted things have worked fine with the above tweak until upgrading to 7.2-RELEASE. Can you send me a pciconf -lvb robert. $ pciconf -lvb hos...@pci0:0:0:0:class=0x06 card=0x01ad1028 chip=0x27708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G/GZ/P/PL Host Bridge/DRAM Controller' class = bridge subclass = HOST-PCI pc...@pci0:0:1:0:class=0x060400 card=0x8086 chip=0x27718086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82945G/GZ/P/PL Host to PCI Express Bridge' class = bridge subclass = PCI-PCI vgap...@pci0:0:2:0:class=0x038000 card=0x01ad1028 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb0, size 524288, enabled bar [14] = type I/O Port, range 32, base 0xe898, size 8, enabled bar [18] = type Prefetchable Memory, range 32, base 0xd000, size 268435456, enabled bar [1c] = type Memory, range 32, base 0xfeac, size 262144, enabled vgap...@pci0:0:2:1:class=0x038000 card=0x01ad1028 chip=0x27768086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb8, size 524288, enabled pc...@pci0:0:28:0:class=0x060400 card=0x chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pc...@pci0:0:28:1:class=0x060400 card=0x chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI uh...@pci0:0:29:0:class=0x0c0300 card=0x01ad1028 chip=0x27c88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff80, size 32, enabled uh...@pci0:0:29:1:class=0x0c0300 card=0x01ad1028 chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff60, size 32, enabled uh...@pci0:0:29:2:class=0x0c0300 card=0x01ad1028 chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff40, size 32, enabled uh...@pci0:0:29:3:class=0x0c0300 card=0x01ad1028 chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff20, size 32, enabled eh...@pci0:0:29:7:class=0x0c0320 card=0x01ad1028 chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xffa80800, size 1024, enabled pc...@pci0:0:30:0:class=0x060401 card=0x chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI p...@pci0:0:30:2:class=0x040100 card=0x01ad1028 chip=0x27de8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub AC'97 Audio' class = multimedia subclass = audio bar [10] = type I/O Port, range 32, base 0xec00, size 256, enabled bar [14] = type I/O Port, range 32, base 0xe8c0, size 64, enabled bar [18] = type Memory, range 32, base 0xfeabfa00, size 512, enabled bar [1c] = type Memory, range 32, base 0xfeabf900, size 256, enabled is...@pci0:0:31:0:class=0x060100 card=0x chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: Ok, they are at least partially disabled... I wonder if a BIOS update would help. Anyway, the garbled screen issue is usually associated with the caching method used on the PCI GART. On IGP chips we force the GART to be uncacheable. On PCI chips they are supposed to be able to snoop the bus and DTRT. All of the fixes for memory caching should be in 7. Please try the attached patch and see if that makes a difference. robert. Unfortunately, this didn't help. I should also clarify what I'm seeing, as it's not complete garbage as I thought. I have a dual monitor setup, side-by-side using xrandr. When I start X (xfce4) with drm available, the left monitor (primary) is a sold light shade of blue, except for a black corner which is maybe 10pix square. The right monitor displays my typical background image with another black box over part of it. If it shift back to the console and then back into X, I can see the outlines of my startup windows, but they contain garbage and the outlines are fuzzed with green and magenta garbage. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: ok, how about this one... If this doesn't do it, then we need to start digging... robert. No change when using this patch either. I've also updated to the latest BIOS and have ensured that the onboard Intel adapter is as disabled as it can get. I can provide you some photos of the screen behavior if you think it may help. Thanks again so far! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy
Brian A. Seklecki wrote: NOTE: You're using the 4e/Si, which we have as well. We're experiencing random crashes on the 1850/8th gen, as a result of a (believed) DMA bug introduced into 7.x Just to note, we are only seeing these issues in combination with megarc (/usr/ports/sysutils/megarc) monitoring. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: amr driver issues in 7.1-RELEASE
Steve Polyack wrote: Scott Long wrote: The fix for this that I was thinking of is already in 7.1. There might still be a driver bug, but I'm leaning more towards the controller simply being busy. Do you have a reproducible test case that I could try? Scott So far, I have not been able to reliably reproduce this. It pops up every now and then during our backups, which at the moment aren't that disk intensive. I'll let you know if I come across anything else. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sysinstall partition oddities (6.3/i386 - 7.x/amd64)
Steve Polyack wrote: I've seen some oddities with the partition and bsdlabel editors in the sysinstall program on the 7.0 and 7.1 releases. The partition editor seems to be reading or parsing the partition table incorrectly. I had a 6.3-RELEASE system with the following layout: /dev/amrd3s1a on / (ufs, local) /dev/amrd3s1g on /opt (ufs, local, soft-updates) /dev/amrd3s1f on /usr (ufs, local, soft-updates) /dev/amrd3s1d on /var (ufs, local, soft-updates) /dev/amrd3s1e on /var/log (ufs, local, soft-updates) Upon booting into the 7.x install media and encountering the FDISK Partition Editor, the partition it's seeing is amrd3*a*s1, as opposed to amrd3s1. Trying to continue with the partition table and bsd labels as is only led to the installer bailing out. As soon as it would attempt to newfs the disk partitions, the installer would error and report that it can't find a device entry in /dev for amrd3*a*s1a. Since preserving the data on the disk was not critical, I was able to continue by deleting the original partition/slice and recreating them. This worked fine. However, I'm still curious as to what the cause of this is. I have seen this before on two other systems while installing 7.x, quite possibly while upgrading from 6.3. When this occurred, I was also moving from i386 to amd64; Is there some kind of offset for partition tables which may change based on architecture? Lastly, here's a screenshot of the partition editor: http://people.collaborativefusion.com/~spolyack/fbsd-install.jpg Unfortunately, I do not have any screenshots of the errors during the newfs step. If this comes up again, I'll be sure to take some. Thanks. This also occurs in VMWare. I'm able to get the exact same behavior by installing a 7.1-RELEASE system (single slice, da0s1), then booting off the install media and start a new installation. It picks up the partition as da0as1 instead of da0s1, making it impossible to use sysinstall while preserving existing partitions. -Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
amr driver issues in 7.1-RELEASE
We have multiple systems using LSILogic PERC4 cards (PERC4e/Si, PERC4/DC, amr driver). After recently upgrading two of them from 6.3 to 7.1, we have begun to see the following errors in our logs during heavy use in both systems: amr0: Too many retries on command 0x80a4da58. Controller is likely dead amr0: Too many retries on command 0x80a4eaa8. Controller is likely dead amr0: Too many retries on command 0x80a497a0. Controller is likely dead amr0: Too many retries on command 0x80a4eaa8. Controller is likely dead However, the system continues working and the volumes remain accessible. This happens on the PERC4/DC controllers in both systems. Firmware version is 352D. MegaCLI reports no problems. Has anyone else seen these messages? A google search turns up nothing but results in the driver code. Is this something we should be worried about? We won't be moving any other systems to 7.1 until we can clear this up. Thanks! -Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: amr driver issues in 7.1-RELEASE
Scott Long wrote: The fix for this that I was thinking of is already in 7.1. There might still be a driver bug, but I'm leaning more towards the controller simply being busy. Do you have a reproducible test case that I could try? Scott We saw this one while backups wrote from an array on the PERC4/DC to a tape drive (on a separate controller). amr1: Too many retries on command 0x80a6d060. Controller is likely dead The other four which I noted came during writes to the array attached to the PERC4/DC (external Dell PowerVault). I want to say they showed up while writing a 30G junkfile (/dev/random) to the array which we were using to test the tape access; either that, or while we wrote that file out to the tape drive. If it matters, we also use ports/sysutils/linux-megacli2 to periodically check the status of our arrays. It's possible that this happened during one of these long writes/reads. I'm not having any luck reproducing at the moment, but if I come across a reproducible test, I will let you know. Thanks! Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: amr driver changes in FreeBSD 7.1-RELEASE
In case anyone is interested, the situation has only gotten weirder. Booting 7.1-R with 'boot -v' mysteriously adds: (probe32:amr1:1:6:0): error 22 (probe32:amr1:1:6:0): Unretryable Error However, amr1 is not the one that is giving us issues. It appears to work fine. amr0 is the one on which 7.1-R fails to find any volumes. Even stranger, a 'camcontrol devlist' manages to display all off the individual SCSI drives attached to amr0. Finally, this problem was solved whilst writing this e-mail. The default for kern.cam.scsi_delay (5000ms) appears to be too aggressive in my circumstances. Increasing it to 15000 solves my issue (and gets rid of amr0: adapter is busy messages). Steve Polyack wrote: Hello, We have a Dell PowerEdge 1850 server. It contains two PERC4 RAID controllers. One is a PERC4e/Si, and the other is a PERC4/DC. Right now we are running FreeBSD 6.3-RELEASE, with a 36GB RAID-1 on the PERC4e/Si (amr0), and both a 1TB RAID5 and a 136GB RAID1 on the PERC4/DC(amr1). Both adapters are running the latest firmware revision. When we boot FreeBSD7.1 install media, the amr driver fails to detect any volumes (disks) attached to amr0, the PERC4e/Si. However, it picks up the attached disks on the PERC4/DC just fine. However, if I boot 7.0-RELEASE install media, it picks up all of the attached volumes, leading me to believe the issue is due to changes in the amr driver between 7.0 and 7.1. During the 7.1 boot process, before probing disks, we see the message amr0: adapter is busy show up twice. This also does not occur on the 6.3, 6.4, or 7.0 releases. We also have another PE1850 with a very similar configuration, except the two PERCs get probed in a different order, and it detects all of the attached volumes without any issues. Any suggestions? These are semi-critical systems, so we aren't always able to test things like this. But, we can schedule downtime once or twice a week if necessary. -Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
amr driver changes in FreeBSD 7.1-RELEASE
Hello, We have a Dell PowerEdge 1850 server. It contains two PERC4 RAID controllers. One is a PERC4e/Si, and the other is a PERC4/DC. Right now we are running FreeBSD 6.3-RELEASE, with a 36GB RAID-1 on the PERC4e/Si (amr0), and both a 1TB RAID5 and a 136GB RAID1 on the PERC4/DC(amr1). Both adapters are running the latest firmware revision. When we boot FreeBSD7.1 install media, the amr driver fails to detect any volumes (disks) attached to amr0, the PERC4e/Si. However, it picks up the attached disks on the PERC4/DC just fine. However, if I boot 7.0-RELEASE install media, it picks up all of the attached volumes, leading me to believe the issue is due to changes in the amr driver between 7.0 and 7.1. During the 7.1 boot process, before probing disks, we see the message amr0: adapter is busy show up twice. This also does not occur on the 6.3, 6.4, or 7.0 releases. We also have another PE1850 with a very similar configuration, except the two PERCs get probed in a different order, and it detects all of the attached volumes without any issues. Any suggestions? These are semi-critical systems, so we aren't always able to test things like this. But, we can schedule downtime once or twice a week if necessary. -Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pending MFC of drm updates
Robert Noland wrote: I am planning to merge most all of the drm from -CURRENT to releng_7 shortly. The merge that I have staged includes the following. Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605, 183828,183830-183834,184212-184213,184263,184373-184375 There are really too many updates/fixes to mention as the drm from 7 is more than 2 years old now. This has support for several newer Intel and AMD/ATI chips, (no r6/7xx yet, but soon(tm)). I have a patch available for testing at http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2 robert. I've pulled this down and patched my install of FreeBSD 7.1-RELEASE. Whilst using a Radeon 9250 (R280?), I have no problems. There is also no apparent performance difference. The only issue I have seen occurs with my dual-monitor setup. Occasionally a window on the second monitor will decide to render its drop-down menus or other (overlay-based?) graphics on the primary monitor instead of where it should be. Restarting the application seems to clear this up. I have not seen this previously before applying your patch. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Burning DVD with files4GB from console
Not too say you're .iso images can't be 2GB/4GB, but I'm pretty sure the ISO9660 standard is limited to a 2GB maximum file size (for files within the .iso). You must use UDF to burn files of greater size. mkisofs(8) seems to support this, if only in alpha/hybrid stage: -udf Include UDF support in the generated filesystem image. UDF sup- port is currently in alpha status and for this reason, it is not possible to create UDF only images. Stephen Montgomery-Smith wrote: David Kelly wrote: On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: My backup script split filesystem dumps to files with size of 4,37 GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At this moment I have to burn them from windows via smb-link becuase I didn't manage to do this task from FreeBSD console due to 2GB/4GB filesize restrictions (growisofs). Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I have burned 4.3GB DVDs several times. I never had a problem writing huge files. But I did have a problem subsequently reading it with Windows XP. Maybe the file size restriction is a Windows thing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatable crash on RELENG7
Kevin Oberman wrote: Date: Tue, 2 Dec 2008 19:33:00 +0300 From: Alexandr Pakhomov [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Tue, Dec 2, 2008 at 5:12 PM, Mike Tancsa [EMAIL PROTECTED] wrote: At 08:38 AM 12/2/2008, Kostik Belousov wrote: mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. Thanks, how do I find out what the limit is on a machine ? Is it vm.kvm_size ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Try tune both vm.kmem_size and vm.kmem_size_max via /boot/loader.conf. They are equal to 330M by default. Mike, Let me second Kris's suggestion. I can think of very few cases where malloc backed is in any way better than swap backed. Many people assume that swap-backed performance is better, but this is only the case if you run out of memory (and that is full memory, not kvm). md is still RAM based and very fast. The current mdconfig should be defaulting to swap-backed devices, but I don't see any indication of that in the man page, so I may be wrong. I agree here. Using mdconfig(8) in malloc-backed mode may lead to unpredictable results when attempting to use large amounts of memory. mdconfig(8) seems to allow you to reserve more kernel memory than may be appropriate, and as in Mike's experience, causes a kernel panic upon writing enough data to the malloc'd md(4) device. It seems that the term swap-backed is misleading for some people. It does NOT mean your md(4) device will be constantly swapping to disk (and the man page does an alright job of relaying this). It simply means that generally available memory will be used, and so will swap iff available memory happens to drop low enough. The bottom line in my experience with md(4) devices greater than ~100MB is that swap-backed is always reliable, while malloc'd md(4) devices will cause unpredictable kernel panics. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
