Re: 9-STABLE panic on intensive fork
On 29.08.2013, at 22:45, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Aug 28, 2013 at 06:20:29PM +0400, Dmitry Sivachenko wrote: Hello! I am using very recent FreeBSD-9-STABLE snapshot: 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254986: Wed Aug 28 17:18:57 MSK 2013 I run uwsgi program (ports/www/uwsgi) on that machine. When uwsgi starts, it forks pre-configured number of worker processes. If I raise workers parameter high enough (128), I get kernel panic (100% reproducible): Fatal trap 12: page fault while in kernel mode If I compile kernel with KDB enabled, I get the following stack: pmap_demote_pde_locked() pmap_copy() vmspace_fork() fork1() sys_fork() I have only remote console for that machine, so I made 2 screenshots: 1) http://people.freebsd.org/~demon/screen1.jpg Panic screen when kernel has no KDB support compiled in 2) http://people.freebsd.org/~demon/screen2.jpg Panic screen (2nd part) with the above stack shown. Look up the source line for the pmap_demote_pde_locked()+0x471 for your kernel. Dump the core from the panic. Kernel dump is not generated (despite it is configured at boot), there is no Dumping message on console. These screenshots shows everything I see on console. I performed some more investigations on this: I have several (14) totally identical configured machines running exactly the same software. Hardware is a bit different though. I tried to analyze motherboard differences but failed to find common things for the affected machines. Under conditions described in my initial e-mail, some of them crash (exactly the same way), some of them do not. I am confident there is no hardware problems, these machines run for months without reboot, as for now I discovered the only way to crash them. I updated one of the affected servers to 10-current and I can state it does not crash anymore with the same usage scenario. ___ 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: Lost CAM Access to DVD Writer
Hi, I got the same result and error message as I did when trying to dump the file system The question towards FreeBSD developers is therefore: Why does device /dev/cd0 with this gesture ... in_fd = open (device,O_RDONLY)) ... ... if (ioctl (in_fd,CAMGETPASSTHRU,ccb) 0) cause error ENOTTY, as indicated by growisofs message Inappropriate ioctl for device Maybe it is necessary to write a small demo program, because growisofs is kindof an anti-example of a clean software architecture. (Well, a debugger should make clear how it gets to the failed ioctl attempt.) --- The question towards the port maintainer of growisofs would be whether there is interest to develop a workaround which avoids that special ioctl. I would help, if desired. A test with cdrskin as substitute for growisofs would demonstrate whether this is worthwhile: /sbin/dump ... -P 'cdrskin -v dev=/dev/cd0 -eject -' ... or dd if=/dev/zero bs=1M count=100 | cdrskin -v dev=/dev/cd0 -eject - (We have some indication by success of cdrecord. But i am reluctant for social reasons to analyze the FreeBSD doings of cdrecord. Its author accuses others of stealing his code.) I would further like to bring to the porter's attention a bug fix for growisofs with blank BD-R media: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713016 Meanwhile well tested by users of Fedora. --- Have a nice day :) Thomas ___ 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: gmirror crash writing to disk? Or is it su+j crash?
The first one (kern.geom.transient_map_retries) causes the system to wedge. The second one (default is 180, I doubled to 360) causes the system to crash but not dump. So... neither fixes the problem. On Sat, Aug 31, 2013 at 5:27 AM, Edward Tomasz Napierała tr...@freebsd.orgwrote: Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 31 sie 2013, o godz. 00:49: Because someone said that there would be no logging of unerlying ATA errors without verbose, I rebooted with verbose and tried the same make -j4 again... and here is the relatively similar core.txt.5 https://uk.eicat.ca/owncloud/public.php?service=filest=d99648ef5876b91c5957148445e60c87 Looking at it, gmirror is dropping the same error and the underlying hardware is not causing the error... Let me quote Konstantin: It is either an exhaustion of the transient map, or a deadlock. For the first, setting kern.geom.transient_map_retries to 0 could help. For the second, the count of the transient buffers must be increased, by kern.bio_transient_maxcnt loader tunable. Could you try both and tell which one of them fixed the problem? 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: Boot problem if a ZFS log device is missing
On 30/08/2013 12.46, Andriy Gapon wrote: on 30/08/2013 13:37 Andriy Gapon said the following: on 30/08/2013 00:38 Charles Sprickman said the following: If one is willing to accept that data is lost (like the log device is totally smoked), is there a way to boot knowing that you may have some data loss, or is the only option to boot alternate media and force a pool import (assuming that works without the log device)? I think it's the latter. I am not aware of any way to select a behavior similar to import -m or import -F during boot. Perhaps... ZFS_IMPORT_MISSING_LOG should be a default behavior for a root pool or maybe the behavior could be controllable by a tunable. Maurizio, you might want to try the following patch as an interim solution for your environment: --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c @@ -4112,6 +4112,7 @@ spa_import_rootpool(const char *name) } spa-spa_is_root = B_TRUE; spa-spa_import_flags = ZFS_IMPORT_VERBATIM; + spa-spa_import_flags |= ZFS_IMPORT_MISSING_LOG; /* XXX make tunable */ /* * Build up a vdev tree based on the boot device's label config. HI all, unfortunately the patch don't works. The laptop returns the same error message: Mounting from zfs:tank0 failed with error 6 and the same mountroot prompt. I am available for further testing if needs. Thanks anyway, Maurizio ___ 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: Stiil a regression with jails/IPv6/pf?
Hi, On 31 Aug 2013, at 21:49, Tim Bishop t...@bishnet.net wrote: Hi all, This is regarding kern/170070 and these two threads from last year: http://lists.freebsd.org/pipermail/freebsd-stable/2012-July/068987.html http://lists.freebsd.org/pipermail/freebsd-stable/2012-August/069043.html I'm running stable/9 r255017 and I'm seeing the same issue, even with the fix Bjoern committed in r238876. This is still with modulate state in some rules that also hit ipv6 traffic ? It almost looks like doing this kind of traffic alteration is considered harmful for IPv6 http://forums.freebsd.org/showthread.php?t=36595 If that is the case, then this should be applicable only to ipv4 traffic, without requiring specific knowledge from the user My setup is a dual stack one (IPv6 is done through an IPv4 tunnel) and the problem is only with IPv6. I have jails with both IPv4 and IPv6 addresses, and I use pf to rdr certain ports to certain jails. With IPv6 I'm seeing failed checksums on the packets coming back out of my system, both with UDP and TCP. If I connect over IPv6 to the jail host it works fine. If I connect over IPv6 to a jail directly (they have routable addresses, but I prefer them to all be masked behind the single jail host normally), it works fine. So the only failure case is when it goes through a rdr rule in pf. This system replaces a previous one running stable/8 which worked fine with the same pf config file. Has anyone got any suggestions on what I can do to fix this or to debug it further? Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x6C226B37FDF38D55 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 9.2-RC3 - suspend/resume causes slow system performance
So you tinkered with this - which particular line(s) did you revert back to get the old behaviour? -adrian On 1 September 2013 22:46, Mike Harding mvhard...@gmail.com wrote: Why not put this out to stable and take a survey with more than 2 members? I am sure that there are those who will be delighted, as I was with 9.1, to discover that suspend/resume worked without rebooting the machine. I can make the system available to you, contact me at this email. I am in the PDT time zone. ___ 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: 9.2-RC3 - suspend/resume causes slow system performance
It's detailed in the ticket, see http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for 'reverted'. On Mon, Sep 2, 2013 at 6:35 AM, Adrian Chadd adr...@freebsd.org wrote: So you tinkered with this - which particular line(s) did you revert back to get the old behaviour? -adrian ___ 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: 9.2-RC3 - suspend/resume causes slow system performance
On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com wrote: It's detailed in the ticket, see http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for 'reverted'. Ok. You and avg@ are digging into it deeper, so I'll leave it be for now. I'll retest this on my test laptops when I'm back home. -adrian ___ 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: Stiil a regression with jails/IPv6/pf?
Hi, On Mon, Sep 02, 2013 at 12:22:11PM +0200, Ruben van Staveren wrote: On 31 Aug 2013, at 21:49, Tim Bishop t...@bishnet.net wrote: This is regarding kern/170070 and these two threads from last year: http://lists.freebsd.org/pipermail/freebsd-stable/2012-July/068987.html http://lists.freebsd.org/pipermail/freebsd-stable/2012-August/069043.html I'm running stable/9 r255017 and I'm seeing the same issue, even with the fix Bjoern committed in r238876. This is still with modulate state in some rules that also hit ipv6 traffic ? No, I'm not using modulate state. Only keep state. It almost looks like doing this kind of traffic alteration is considered harmful for IPv6 http://forums.freebsd.org/showthread.php?t=36595 So it doesn't look like that's the same problem. It's certainly similar (IPv6 and pf), but doesn't involve the rdr rule or jails. IPv6 is otherwise working fine through pf. Tim. If that is the case, then this should be applicable only to ipv4 traffic, without requiring specific knowledge from the user My setup is a dual stack one (IPv6 is done through an IPv4 tunnel) and the problem is only with IPv6. I have jails with both IPv4 and IPv6 addresses, and I use pf to rdr certain ports to certain jails. With IPv6 I'm seeing failed checksums on the packets coming back out of my system, both with UDP and TCP. If I connect over IPv6 to the jail host it works fine. If I connect over IPv6 to a jail directly (they have routable addresses, but I prefer them to all be masked behind the single jail host normally), it works fine. So the only failure case is when it goes through a rdr rule in pf. This system replaces a previous one running stable/8 which worked fine with the same pf config file. Has anyone got any suggestions on what I can do to fix this or to debug it further? Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x6C226B37FDF38D55 pgpznON5LHBNL.pgp Description: PGP signature
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - - Original Message - Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime): ... snip The intr usage is higher than the other drivers you compared against because if_vmx does the off-level processing in ithreads where as the others do it in a taskqueue. BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can, but I bet the e1000e does. if_vmx - if_vmx 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr if_vmxJumbo - if_vmxJumbo 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr Please find attached the different outputs of dev.vmx.X (the mtu9000 run was only 3.47GBits/sec in that case, took the numbers anyway) Thanks for the sysctl output. dev.vmx.0.txq0.ringfull: 133479 dev.vmx.0.txq0.hstats.tso_packets: 564986 dev.vmx.0.txq0.hstats.ucast_packets: 570604 For the number of packets transmitted, there's a really high percentage of time we find the Tx queue full enough it is not able to hold the next to transmit frame. I've haven't been able to recreate this. But I recently made a commit [1] that might help alleviate this. [1] http://svnweb.freebsd.org/base?view=revisionrevision=255055 wbr, -Harry ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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
