Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sep 18, 2011 11:25 AM, Kostik Belousov kostik...@gmail.com wrote: Please note that interpreting the receiving of 0 bytes on the terminal as EOF is only a convention. If done absolutely properly, script shall not interpret zero-byte read as EOF. Might be, the reasonable thing to do would be to only look at the stdin once in a second after receiving zero-bytes, and switching it back to normal mode if something is read. The other obvious alternative is to test for underlying file type, and distinguish between EOF is forever (ordinary pipes and sockets, some but not all block devices, etc) and other. In fact, the EOF is only temporary mode introduced in the original change might reasonably be limited to character devices only, for the purposes to which script is put. The delay method has significant merit in terms of simplicity, of course: it avoids special-casing. To truly fix the problem, though, you would need something different in terms of a kernel interface: a message from the master side of the pty saying slave side has done a read(n) (where n is some integer), so that the program running the pty can issue a corresponding read(n) on a buffer, to forward the results back through the pty later. Without this, the script program erroneously translates one EOF as signaled by read returning 0 into multiple EOF on pty signals. Adding a delay simply changes this from as many as script can stuff down the pty at maximum CPU rate to one a second. Thus, if I were fixing this, I would lean towards EOF is just a temporary signal being applied only to character devices, and/or perhaps having a command-line flag to force one mode or the other (with the default being EOF is permanent on everything except character devices). Chris ___ 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
busdma MFC broke ipfw fwd for RELENG_6
Eugene Grosbein wrote: Well, given that before busdma commit that hardware worked just fine with stock driver, it could be less overhead for me to rollback that one busdma small chunk :-) Who knows, which drivers got broken then in 2010 in 6.4-STABLE with busdma change besides re(4)... Another example is de(4) as mentioned in kern/151941. -- Dr. Andreas Longwitz Data Service GmbH Beethovenstr. 2A 23617 Stockelsdorf Amtsgericht Lübeck, HRB 318 BS Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau ___ 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
Usling vlan(4) without an actual lan behind it
Can anyone see any problem is doing this ? i.e. creating a vlan interface which doesnt correspond to any physical interface, just as a place to hang IP addresses. I am trying to work around a problem with carp and ndp when there are multiple IPv6 addresses bound to it. cheers, -pete. ___ 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: Usling vlan(4) without an actual lan behind it
On Mon, September 19, 2011 08:02, Pete French wrote: Can anyone see any problem is doing this ? i.e. creating a vlan interface which doesnt correspond to any physical interface, just as a place to hang IP addresses. I am trying to work around a problem with carp and ndp when there are multiple IPv6 addresses bound to it. 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? ___ 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: Usling vlan(4) without an actual lan behind it
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. Currently I am using a range which is the same as the IPv6 - so they do exist on a real ethernet - but the nework interface there is CARP, and from the inside ndp can oly resolve the single initial carp address (I believe this is a known bug). So I want some interface on the firewall box, which is neither the outside, nor the inside, where I can hang a set of addresses on a different subnet. That way both sides will be able to see the addresses fine, and everything will work nicely. -pete. ___ 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: busdma MFC broke ipfw fwd for RELENG_6
On Monday, September 19, 2011 6:20:07 am Andreas Longwitz wrote: Eugene Grosbein wrote: Well, given that before busdma commit that hardware worked just fine with stock driver, it could be less overhead for me to rollback that one busdma small chunk :-) Who knows, which drivers got broken then in 2010 in 6.4-STABLE with busdma change besides re(4)... Another example is de(4) as mentioned in kern/151941. Hmm, that PR isn't really about de(4). For de(4) I think you probably want this change: r197465 | yongari | 2009-09-24 13:53:00 -0400 (Thu, 24 Sep 2009) | 18 lines Align Tx/Rx descriptors on 32 bytes boundary instead of PAGE_SIZE. Also align setup descriptor on 32 bytes boundary. Tx buffer have no alignment limitation so create dmamap without alignment restriction[1]. Rx buffer still seems to require 4 bytes alignment limitation but we can simply use MCLBYTES for size to map the buffer instead of TULIP_DATA_PER_DESC as the buffer is allocated with m_getcl(9). de(4) supports up to TULIP_MAX_TXSEG segments for Tx buffers, increase maximum dma segment size to TULIP_MAX_TXSEG * MCLBYTES. While I'm here remove TULIP_DATA_PER_DESC as it is not used anymore. This should fix de(4) breakage introduced after r176206. Submitted by: jhb [1] Reported by:WATANABE Kazuhiro CQG00620 nifty dot ne dot jp Tested by: WATANABE Kazuhiro CQG00620 nifty dot ne dot jp , Takahashi Yoshihiro nyan jp dot freebsd dot org And probably these as well: r197464 | yongari | 2009-09-24 13:11:41 -0400 (Thu, 24 Sep 2009) | 2 lines Destroy dmamap in dma cleanup. r197463 | yongari | 2009-09-24 13:07:04 -0400 (Thu, 24 Sep 2009) | 2 lines Consistently use bus_addr_t. r197461 | yongari | 2009-09-24 12:57:35 -0400 (Thu, 24 Sep 2009) | 4 lines Use __NO_STRICT_ALIGNMENT to determine whether de(4) have to apply alignment fixup code for received frames on strict alignment architectures. r177937 | jhb | 2008-04-05 13:24:44 -0400 (Sat, 05 Apr 2008) | 9 lines During attach on some de(4) adapters the driver sends out a test packet as part of detecting the media. Explicitly ensure that we don't send it to bpf(4) as bpf(4) isn't setup yet. This worked by accident before the bpf interface stuff was reworked to avoid other races (bpf_peers_present, etc.) but now it needs an explicit check to avoid a panic. MFC after: 3 days PR: kern/120915 r170389 | yongari | 2007-06-06 20:28:47 -0400 (Wed, 06 Jun 2007) | 9 lines The maxsegsz of a dma tag created in de(4) is TULIP_DATA_PER_DESC bytes. In Rx path it allocates a new mbuf with m_getcl(9) so the length of the mbuf is MCLBYTES which is greater than a segment size specified by the dma tag. This segment size mismatch caused a voluntary panic. Fix the panic by settting the mbuf length to TULIP_DATA_PER_DESC. Reported by:Arne H Juul arnej AT yahoo-inc DOT com Tested by: Arne H Juul arnej AT yahoo-inc DOT com -- John Baldwin ___ 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
mpt0 timeouts with an intel SASUC8I controller
Hello I've stability issue with my new intel SASUC8I [1] PCIe controller. It's a LSI 1068e based controller. After a few minutes with disk io (csup or scrub by example) my FreeBSD 8-stable (64bit) is freezing for a couple of minutes and I see a lot of error messages like: Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bc3b0:48367 timed out for ccb 0xff00050a8000 (req-ccb 0xff00050a8000) Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bbb40:48368 timed out for ccb 0xff0004f81800 (req-ccb 0xff0004f81800) Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bc3b0:48367 Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bbb40:48368 Sep 17 03:10:03 gw kernel: mpt0: Timedout requests already complete. Interrupts may not be functioning It takes minutes to execute commands after the first timeout message. The whole OS is running on single raidz ZFS pool. I use 4x 2TB SpinPoint F4 EcoGreen HD204UI disks with fixed firmware [2]. The disks are connected with brand new adaptec cables. I already replaced a cable to disqualify a cable issue. smartctl looks ok. The system is working fine if I connect all 4 disk to the the onboard controller. Is this an known issue with this controller and the mpt driver? Is there an workaround? I hope someone can help me. Regards, Thomas FreeBSD Information: 8.2-STABLE FreeBSD 8.2-STABLE #3: Sun Jul 3 19:39:11 UTC 2011 r...@gw.lan:/usr/obj/usr/src/sys/GENERIC amd64 Motherboard: smbios.planar.maker=ASUSTeK Computer INC. smbios.planar.product=P5N73-AM Controller: mptutil show adapter mpt0 Adapter: Board Name: SASUC8I Board Assembly: L3-25071-00C Chip Name: C1068E Chip Revision: UNUSED RAID Levels: RAID0, RAID1, RAID1E RAID0 Stripes: 64k RAID1E Stripes: 64k RAID0 Drives/Vol: 2-10 RAID1 Drives/Vol: 2 dmesg about the controller: mpt0: LSILogic SAS/SATA Adapter port 0xee00-0xeeff mem 0xef7fc000-0xef7f,0xef7e-0xef7e irq 16 at device 0.0 on pci2 mpt0: [ITHREAD] mpt0: MPI Version=1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) zpool status: pool: tank state: ONLINE scan: scrub canceled on Sun Sep 18 10:44:46 2011 config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gptid/7cd20811-2af6-11e0-9271-e5dbd4b6b481 ONLINE 0 0 0 gptid/7d7af0fc-2af6-11e0-b0b1-85b4c14d926b ONLINE 0 0 0 gptid/7e24b41a-2af6-11e0-944f-fb3dae8bad6a ONLINE 0 0 0 gptid/dac06b61-972b-11e0-affc-1c6f65565b30 ONLINE 0 0 0 /boot/loader.conf: zfs_load=YES vfs.root.mountfrom=zfs:tank/root aio_load=yes ahci_load=YES ataahci_load=YES ipfw_load=YES vm.kmem_size=6G vfs.zfs.arc_max=4G vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 rc.conf: ipv6_firewall_enable=YES ipv6_firewall_type=OPEN sendmail_enable=NO sshd_enable=YES zfs_enable=YES firewall_enable=YES firewall_type=OPEN dmesg: http://pastebin.com/sL15g1vt smartctl: http://pastebin.com/wYU2DXJ4 [1] http://www.intel.com/content/www/us/en/servers/raid/raid-controller-sasuc8i.html [2] http://www.samsung.com/global/business/hdd/faqView.do?b2b_bbs_msg_id=386 ___ 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: mpt0 timeouts with an intel SASUC8I controller
Hello On Sep 19, 2011, at 2:45 PM, Thomas Vogt wrote: I've stability issue with my new intel SASUC8I [1] PCIe controller. It's a LSI 1068e based controller. After a few minutes with disk io (csup or scrub by example) my FreeBSD 8-stable (64bit) is freezing for a couple of minutes and I see a lot of error messages like: dmesg: http://pastebin.com/sL15g1vt smartctl: http://pastebin.com/wYU2DXJ4 Sorry: http://pastebin.com/0Na23R54 Regards, Tom ___ 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: Usling vlan(4) without an actual lan behind it
On Mon, September 19, 2011 08:45, 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 ? No, you can create an lo0:1 that's a /32 and it shouldn't be a problem. There are a bunch HOWTOs around on configuring anycast that instruct one to put the service IP on an alias on lo0 and then run an OSPF process that advertises that this IP is available on this host (which acts as a router). http://www.openfusion.net/linux/anycast_dns ___ 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
change in io statistics since updating 8.2-STABLE
Hello, like described in another thread, we recently updated a fileserver from 8.2-STABLE@2011-05-08 to 8.2-STABLE@2011-09-08 (amd64 both). ZPool is left at v14, the filesystems at version 3. Nothing in /boot/loader.conf or /etc/sysctl.conf has been changed. We now realize that r/w behaviour has changed on the whole pool. The l2arc devices (2 SSDs) have decreased in writes from average 10M/sec (peaks at 20 M/sec) to 5M/sec. On the other hand, reads on the disks (2x5 disks raidz2) have increased (nearly doubled on each disk). I suspect, that the cache is somewhat faulty or has become slow, and so ZFS decides to read data from main storage instead of the cache. Is there another explaination? Are there some defaults of sysctls which have been changed from May to September? with kind regards, Robert Schulze ___ 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: mpt0 timeouts with an intel SASUC8I controller
Hi Marius On 19.09.2011, at 21:06, Marius Strobl wrote: On Mon, Sep 19, 2011 at 02:45:04PM +0200, Thomas Vogt wrote: Hello I've stability issue with my new intel SASUC8I [1] PCIe controller. It's a LSI 1068e based controller. After a few minutes with disk io (csup or scrub by example) my FreeBSD 8-stable (64bit) is freezing for a couple of minutes and I see a lot of error messages like: Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bc3b0:48367 timed out for ccb 0xff00050a8000 (req-ccb 0xff00050a8000) Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bbb40:48368 timed out for ccb 0xff0004f81800 (req-ccb 0xff0004f81800) Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bc3b0:48367 Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bbb40:48368 Sep 17 03:10:03 gw kernel: mpt0: Timedout requests already complete. Interrupts may not be functioning If this really is an issue with interrupts not getting delivered you could try whether disabling MSI/MSI-X by setting hw.pci.enable_msi=0 and hw.pci.enable_msix=0 either on the loader prompt or via loader.conf works around it. I already tried this. It didn't change anything. Same timeouts. I also tried vfs.zfs.vdev.min_pending=1 and vfs.zfs.vdev.max_pending=1 in loader.conf without any positive change. Regards, Tom ___ 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: mpt0 timeouts with an intel SASUC8I controller
On Mon, Sep 19, 2011 at 02:45:04PM +0200, Thomas Vogt wrote: Hello I've stability issue with my new intel SASUC8I [1] PCIe controller. It's a LSI 1068e based controller. After a few minutes with disk io (csup or scrub by example) my FreeBSD 8-stable (64bit) is freezing for a couple of minutes and I see a lot of error messages like: Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bc3b0:48367 timed out for ccb 0xff00050a8000 (req-ccb 0xff00050a8000) Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bbb40:48368 timed out for ccb 0xff0004f81800 (req-ccb 0xff0004f81800) Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bc3b0:48367 Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bbb40:48368 Sep 17 03:10:03 gw kernel: mpt0: Timedout requests already complete. Interrupts may not be functioning If this really is an issue with interrupts not getting delivered you could try whether disabling MSI/MSI-X by setting hw.pci.enable_msi=0 and hw.pci.enable_msix=0 either on the loader prompt or via loader.conf works around it. Marius ___ 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: mpt0 timeouts with an intel SASUC8I controller
On Mon, Sep 19, 2011 at 09:13:53PM +0200, Thomas Vogt wrote: Hi Marius On 19.09.2011, at 21:06, Marius Strobl wrote: On Mon, Sep 19, 2011 at 02:45:04PM +0200, Thomas Vogt wrote: Hello I've stability issue with my new intel SASUC8I [1] PCIe controller. It's a LSI 1068e based controller. After a few minutes with disk io (csup or scrub by example) my FreeBSD 8-stable (64bit) is freezing for a couple of minutes and I see a lot of error messages like: Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bc3b0:48367 timed out for ccb 0xff00050a8000 (req-ccb 0xff00050a8000) Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bbb40:48368 timed out for ccb 0xff0004f81800 (req-ccb 0xff0004f81800) Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bc3b0:48367 Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req 0xff80002bbb40:48368 Sep 17 03:10:03 gw kernel: mpt0: Timedout requests already complete. Interrupts may not be functioning If this really is an issue with interrupts not getting delivered you could try whether disabling MSI/MSI-X by setting hw.pci.enable_msi=0 and hw.pci.enable_msix=0 either on the loader prompt or via loader.conf works around it. I already tried this. It didn't change anything. Same timeouts. I also tried vfs.zfs.vdev.min_pending=1 and vfs.zfs.vdev.max_pending=1 in loader.conf without any positive change. Okay, I was just worried as I recently changed mpt(4) to use MSI/MSI-X by default for the SAS variants but couldn't test with all of them. I'm not aware of any issues with the driver causing command timeouts though. I'd make sure that both the controller and the disks have the latest firmware; IIRC some time ago someone reported on current@ that updating the firmware of the disks solved the timeouts he was seeing for him. Marius ___ 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 panic on a RELENG_8 NFS server
Hiroki Sato h...@freebsd.org wrote in 20110911.054601.1424617155148336027@allbsd.org: hr Hiroki Sato h...@freebsd.org wrote hr in 20110910.044841.232160047547388224@allbsd.org: hr hr hr Hiroki Sato h...@freebsd.org wrote hr hr in 20110907.094717.2272609566853905102@allbsd.org: hr hr hr hr hr During this investigation an disk has to be replaced and resilvering hr hr hr it is now in progress. A deadlock and a forced reboot after that hr hr hr make recovering of the zfs datasets take a long time (for committing hr hr hr logs, I think), so I will try to reproduce the deadlock and get a hr hr hr core dump after it finished. hr hr hr hr I think I could reproduce the symptoms. I have no idea about if hr hr these are exactly the same as occurred on my box before because the hr hr kernel was replaced with one with some debugging options, but these hr hr are reproducible at least. hr hr hr hr There are two symptoms. One is a panic. A DDB output when the panic hr hr occurred is the following: hr hr I am trying vfs.lookup_shared=0 and seeing how it goes. It seems the hr box can endure a high load which quickly caused these symptoms. There was no difference by the knob. The same panic or unresponsiveness still occurs in about 24-32 hours or so. -- Hiroki pgpIwsQ57ZO6Q.pgp Description: PGP signature
