Re: Should process in STOP state be swapped out?
Wiadomość napisana przez Xin LI w dniu 27 paź 2011, o godz. 02:03: I've noticed that if I kill -STOP a process, the in-core size does not change even when there is memory pressure (what I'm expecting is that if there is memory pressure, the process's in-core part gets swapped out from time to time). Is this behavior intentional? Which version is this? I've fixed a very similar problem in r220387. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [UPDATE] Re: Update on ports on 10.0
On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: What, on the other hand, makes sense is to have the fix that should include: a) a KNOB (WITH_FBSD10_FIX or similar), b) that only is run from bsd.port.mk when OSVERSION100 c) runs the latest version of the above patch. The KNOB's existence allow us to turn on the fix only for broken ports, and easily know what these broken ports are -- so we can poke maintainers from time to time about upstream fixes, ... Erwin is currently running a build on i386-10 with this and the following patches: - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) - python patch from beat - python patch from linimon - WITH_FBSD10_FIX in: - textproc/expat2 - devel/pcre - devel/libtool - audio/libogg Results by Monday. These patches have now been committed to the tree, notably with lang/python27 missing in the above list but was included as well. There have been some proposals already and we can now incrementally improve the workaround and, more importantly, start fixing individual ports. Please note that the patch tries to balance between being a general enough fix to make it easy to get a working system running while not just swiping the whole issue under the rug and forget about it until the next release cycle. Make sure to send any fixes upstream to the hack can be removed from the ports again. Thanks for all your patience and thanks for all those involved, especially beat who sent many patches and improvements. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Upgrade from source to RC1: problems with /etc : lost users and dbus
I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. First, I lost my users; nonroot user names are not recognized, if for instance I type passwd arlene I already tried to login as arlene with old password, no good. I copied the /etc directory to a backup on another disk cp -Rp /etc /media/etcbackup-BETA2 and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc but that didn't help. Do I have to recreate nonroot users from scratch? Also, I got a warning about DBUS not starting. When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. I think it was the second mergemaster part. Should I, as root and X not running, do mv /etc /etcbackup-RC1 and cp -Rp /media/etcbackup-BETA2 /etc where /media would be mount point for backup partition on USB 3.0 hard drive? The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: hostname=amelia2 keymap=us.iso.kbd ifconfig_re0=DHCP ifconfig_re0_ipv6=inet6 accept_rtadv sshd_enable=YES moused_enable=YES ntpd_enable=YES hald_enable=YES dbus_enable=YES Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Thu, Oct 27, 2011 at 11:22 AM, Thomas Mueller mueller6...@bellsouth.net wrote: I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. First, I lost my users; nonroot user names are not recognized, if for instance I type passwd arlene I already tried to login as arlene with old password, no good. I copied the /etc directory to a backup on another disk cp -Rp /etc /media/etcbackup-BETA2 and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc but that didn't help. Do I have to recreate nonroot users from scratch? Also, I got a warning about DBUS not starting. When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. I think it was the second mergemaster part. Should I, as root and X not running, do mv /etc /etcbackup-RC1 and cp -Rp /media/etcbackup-BETA2 /etc where /media would be mount point for backup partition on USB 3.0 hard drive? The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: hostname=amelia2 keymap=us.iso.kbd ifconfig_re0=DHCP ifconfig_re0_ipv6=inet6 accept_rtadv sshd_enable=YES moused_enable=YES ntpd_enable=YES hald_enable=YES dbus_enable=YES Tom I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. If you still have a backup, you are probably missing just master.passwd. hald, dbus would fail to start since their users are no longer there. Once you've done this to your system once, you never want to do it again! Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
* Tom Evans tevans...@googlemail.com, 20111027 13:06: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpWLofpb8j4g.pgp Description: PGP signature
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 27/10/2011 11:22, Thomas Mueller wrote: I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. First, I lost my users; nonroot user names are not recognized, if for instance I type passwd arlene I already tried to login as arlene with old password, no good. I copied the /etc directory to a backup on another disk cp -Rp /etc /media/etcbackup-BETA2 and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc but that didn't help. Other people have suggested what you have done to loose them. To get them back you need /etc/passwd /etc/master.passwd possibly /etc/group There should be a handy backup in /var/backups Also you will need to remake the db files, see man pwd_mkdb Vince Do I have to recreate nonroot users from scratch? Also, I got a warning about DBUS not starting. When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. I think it was the second mergemaster part. Should I, as root and X not running, do mv /etc /etcbackup-RC1 and cp -Rp /media/etcbackup-BETA2 /etc where /media would be mount point for backup partition on USB 3.0 hard drive? The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: hostname=amelia2 keymap=us.iso.kbd ifconfig_re0=DHCP ifconfig_re0_ipv6=inet6 accept_rtadv sshd_enable=YES moused_enable=YES ntpd_enable=YES hald_enable=YES dbus_enable=YES Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Oct 27, 2011, at 4:14 AM, Ed Schouten wrote: * Tom Evans tevans...@googlemail.com, 20111027 13:06: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. Or a tool like etcupdate, which provides 3-way diff functionality, was available in base.. -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [UPDATE] Re: Update on ports on 10.0
Erwin Lansing wrote on 27.10.2011 14:21: On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: What, on the other hand, makes sense is to have the fix that should include: a) a KNOB (WITH_FBSD10_FIX or similar), b) that only is run from bsd.port.mk when OSVERSION100 c) runs the latest version of the above patch. The KNOB's existence allow us to turn on the fix only for broken ports, and easily know what these broken ports are -- so we can poke maintainers from time to time about upstream fixes, ... Erwin is currently running a build on i386-10 with this and the following patches: - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) - python patch from beat - python patch from linimon - WITH_FBSD10_FIX in: - textproc/expat2 - devel/pcre - devel/libtool - audio/libogg Results by Monday. These patches have now been committed to the tree, notably with lang/python27 missing in the above list but was included as well. There have been some proposals already and we can now incrementally improve the workaround and, more importantly, start fixing individual ports. Please note that the patch tries to balance between being a general enough fix to make it easy to get a working system running while not just swiping the whole issue under the rug and forget about it until the next release cycle. Make sure to send any fixes upstream to the hack can be removed from the ports again. Thanks for all your patience and thanks for all those involved, especially beat who sent many patches and improvements. Erwin About devel/libtool fix. Why to not update it to 2.4.2 where this was fixed upstream? I mean http://bugs.freebsd.org/162012 -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
umass(4) regression in 9.0-RC1.
Hi. My SDHC card (via adapter) is no longer being detected after upgrade to 9.0-RC1. The same card with this adapter works on my laptop with older HEAD. usbus0: EHCI version 1.0 usbus0: NVIDIA nForce MCP55 USB 2.0 controller on ehci0 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: nVidia at usbus0 uhub0: nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 uhub0: 10 ports with 10 removable, self powered # usbdevs -v usbdevs: no USB controllers found ehci0@pci0:0:10:1: class=0x0c0320 card=0x81fb1043 chip=0x036d10de rev=0xa2 hdr=0x00 vendor = 'nVidia Corporation' device = 'MCP55 USB Controller' class = serial bus subclass = USB After connecting the adapter with the card inside: kernel: ugen0.2: Generic at usbus0 -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpsXGKnZ7vPK.pgp Description: PGP signature
Re: LSI 9240-8i (IBM M1015) MegaRaid support
Roberto de Iriarte writes: | Hi, | | Is there any expectancy of getting this piece of hardware (or it's IBM | silbing, the M1015) working in MegaRaid mode, without having to reflash | the card to IT mode. | | The reason of this request is that the UEFI Bios on the IBM XSeries | 3550M3 refuses to properly initialize the controller if reflashed with | the IT mode firmware, thus making it unusable. | | A search on LSI's website for a driver that supports 8-Stable or 9 did | not produce any results I have driver changes from LSI to support the 9240 and newer ThunderBolt based cards. I have the cards working but need to do a bunch more work to get this into shape to commit to FreeBSD. I also need to look at how they are dealing with their JBOD configuration and attachment. I have cards to test this stuff out but my time is limited to work on it. One thing I should start working on is merging in the LSI changes into the FreeBSD version since the LSI code drop has removed a bunch of features that the FreeBSD version has. Then I can have a smaller change. There are some architectural changes that I need to figure out. They started to use 64 bit addressing. Then there are style issues. Probably the best thing for me to do is add the new HW support to FreeBSD as a small diff then work on improving that and maybe others can also help with that. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Should process in STOP state be swapped out?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/27/11 00:54, Edward Tomasz Napierała wrote: Wiadomość napisana przez Xin LI w dniu 27 paź 2011, o godz. 02:03: I've noticed that if I kill -STOP a process, the in-core size does not change even when there is memory pressure (what I'm expecting is that if there is memory pressure, the process's in-core part gets swapped out from time to time). Is this behavior intentional? Which version is this? I've fixed a very similar problem in r220387. Thanks, I think that's the problem I hit. The version is a heavily patched 8.2-RELEASE. I'll run some tests to make sure that the problem was fixed. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOqZ+yAAoJEATO+BI/yjfBLgsIANdL7NkXPdG6c+zHH0GHX7sY X6W34AXkQ5TGfAeiI2jpdamI3rOscQZiChJ9othR5CztunU7TM/nHcVdIIMyeSCT 8IDwvquvEodh+Un1ybGRUp7p08/Xr3hyNJsxFfucEKF14kH9oSqMmWdIlxHFthP2 4VrrUnZDoNvS4GLZYBDWj/gXzmhavsFvdD7UvPxbI2gtjiM/mwpCRnlHZxhfiGzS tQkceVudRkeHJfaH+7k27p1WcjK4eBicm/WKUz/iR82vA1tNLQ1+LgPr5875mT1l oZJbncdnI6K9Fau7owe+7MJNt+XBYXJFM6u89Tbe8pxLAj+fdIXZzxToT/GeHoQ= =I5Wy -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: umass(4) regression in 9.0-RC1.
On Thursday 27 October 2011 19:07:38 Pawel Jakub Dawidek wrote: Hi. My SDHC card (via adapter) is no longer being detected after upgrade to 9.0-RC1. The same card with this adapter works on my laptop with older HEAD. usbus0: EHCI version 1.0 usbus0: NVIDIA nForce MCP55 USB 2.0 controller on ehci0 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: nVidia at usbus0 uhub0: nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 uhub0: 10 ports with 10 removable, self powered # usbdevs -v usbdevs: no USB controllers found ehci0@pci0:0:10:1: class=0x0c0320 card=0x81fb1043 chip=0x036d10de rev=0xa2 hdr=0x00 vendor = 'nVidia Corporation' device = 'MCP55 USB Controller' class = serial bus subclass = USB After connecting the adapter with the card inside: kernel: ugen0.2: Generic at usbus0 What does usbconfig dump_device_desc, say about this device? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: umass(4) regression in 9.0-RC1.
On Thu, Oct 27, 2011 at 08:30:44PM +0200, Hans Petter Selasky wrote: What does usbconfig dump_device_desc, say about this device? ugen0.1: EHCI root HUB nVidia at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x idProduct = 0x bcdDevice = 0x0100 iManufacturer = 0x0001 nVidia iProduct = 0x0002 EHCI root HUB iSerialNumber = 0x no string bNumConfigurations = 0x0001 -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpP7jchJhwkx.pgp Description: PGP signature
Re: umass(4) regression in 9.0-RC1.
On Thursday 27 October 2011 20:40:37 Pawel Jakub Dawidek wrote: On Thu, Oct 27, 2011 at 08:30:44PM +0200, Hans Petter Selasky wrote: What does usbconfig dump_device_desc, say about this device? ugen0.1: EHCI root HUB nVidia at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x idProduct = 0x bcdDevice = 0x0100 iManufacturer = 0x0001 nVidia iProduct = 0x0002 EHCI root HUB iSerialNumber = 0x no string bNumConfigurations = 0x0001 This is the root HUB. Can you also show the actual device? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: umass(4) regression in 9.0-RC1.
On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote: This is the root HUB. Can you also show the actual device? Sorry, it wasn't connected, here it goes: ugen0.2: USB2.0-CRW Generic at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x0bda idProduct = 0x0119 bcdDevice = 0x1981 iManufacturer = 0x0001 retrieving string failed iProduct = 0x0002 retrieving string failed iSerialNumber = 0x0003 retrieving string failed bNumConfigurations = 0x0001 -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpR8r24wP9lu.pgp Description: PGP signature
[PATCH] Default scrub interval to whole weeks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I think it might be better if we set scrub interval to whole weeks
(proposed changeset changes it to 5 weeks).
The reason for this is to make it easier for system administrators to
estimate when the scrub happens, for instance, if a scrub was done on
Saturday, it always happen on Saturdays. On large zpools, scrub can
consume a lot of time and I/O bandwidth, and having it happen on
random weekday is not a good idea.
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
iQEcBAEBCAAGBQJOqaq+AAoJEATO+BI/yjfBNq8IALxm6vrtIIbnklv+WM9hc1ek
Os3DpIf12UNA52v02Gglqz3fyuff4wQ4iHQBi1gvZRzEkY9pVTQgInFi2F5MlBxF
DC474RLyOShS2SMBmHZQPxlRcGhG6e9OY75XLu0HzbPl3Ah7+HiPcckEgEZ7NjhL
3CKYikvaXerE+Iee+dzrhP9wN+JaG4/RjW4fvHCkWCuIcDemKyebUyqb1O+A35P0
lXjComE1SnYtJSjVWobgGJm9tgJ8CV8fPMd6KcEohwOdDoq6YSaesA1/CAYirZT7
i65FGpT7Eep3K6rV6XJvZUg2bMQcRL/HmqJekowHsMmxDZ8+lLQ001t5QU0jFY4=
=9caN
-END PGP SIGNATURE-
Index: defaults/periodic.conf
===
--- defaults/periodic.conf (revision 226850)
+++ defaults/periodic.conf (working copy)
@@ -150,8 +150,8 @@
# 800.scrub-zfs
daily_scrub_zfs_enable=NO
daily_scrub_zfs_pools= # empty string selects all pools
-daily_scrub_zfs_default_threshold=30 # days between scrubs
-#daily_scrub_zfs_${poolname}_threshold=30# pool specific threshold
+daily_scrub_zfs_default_threshold=35 # days between scrubs
+#daily_scrub_zfs_${poolname}_threshold=35# pool specific threshold
# 999.local
daily_local=/etc/daily.local # Local scripts
Index: periodic/daily/800.scrub-zfs
===
--- periodic/daily/800.scrub-zfs(revision 226850)
+++ periodic/daily/800.scrub-zfs(working copy)
@@ -15,7 +15,7 @@
source_periodic_confs
fi
-: ${daily_scrub_zfs_default_threshold=30}
+: ${daily_scrub_zfs_default_threshold=35}
case $daily_scrub_zfs_enable in
[Yy][Ee][Ss])
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton do...@freebsd.org wrote:
The attached implements that, and is almost certainly the right way to
go. It would be nice if someone could test it, and better if someone
else could commit it. I swore after the last time that I'd stay away
from that file precisely because of all the bikeshed stupidity that this
issue creates.
Hi,
I tested your patch and it works. I am attaching vers.c files which I
generated in trees which were under svn control, and not under svn control.
--
Craig Rodrigues
rodr...@crodrigues.org
Index: newvers.sh
===
--- newvers.sh (revision 226474)
+++ newvers.sh (working copy)
@@ -88,7 +88,7 @@
i=`${MAKE:-make} -V KERN_IDENT`
for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d ${SYSDIR}/.svn -a -x ${dir}/svnversion ] ; then
+ if [ -x ${dir}/svnversion ] ; then
svnversion=${dir}/svnversion
break
fi
@@ -99,8 +99,12 @@
done
if [ -n $svnversion ] ; then
-echo $svnversion
- svn= r`cd ${SYSDIR} $svnversion`
+ echo $svnversion
+ svn=`cd ${SYSDIR} $svnversion`
+ case $svn in
+ [0-9]*) svn= r${svn} ;;
+ *) unset svn ;;
+ esac
fi
if [ -n $git_cmd ] ; then
/*-
* Copyright (c) 1992-2011 The FreeBSD Project.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
#define SCCSSTR @(#)FreeBSD 9.0-BETA2 #0 r225368:226179M: Tue Oct 25 23:35:11
PDT 2011
#define VERSTR FreeBSD 9.0-BETA2 #0 r225368:226179M: Tue Oct 25 23:35:11 PDT
2011\n
rodr...@dibbler.crodrigues.org:/usr/obj/opt2/branches/head/src/sys/MYKERNEL1\n
#define RELSTR 9.0-BETA2
char sccs[sizeof(SCCSSTR) 128 ? sizeof(SCCSSTR) : 128] = SCCSSTR;
char version[sizeof(VERSTR) 256 ? sizeof(VERSTR) : 256] = VERSTR;
char ostype[] = FreeBSD;
char osrelease[sizeof(RELSTR) 32 ? sizeof(RELSTR) : 32] = RELSTR;
int osreldate = 900043;
char kern_ident[] = GENERIC;
/*-
* Copyright (c) 1992-2011 The FreeBSD Project.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
#define SCCSSTR @(#)FreeBSD 9.0-BETA2 #5: Tue Oct 25 23:07:51 PDT 2011
#define VERSTR FreeBSD 9.0-BETA2 #5: Tue Oct 25 23:07:51 PDT 2011\n
rodr...@dibbler.crodrigues.org:/usr/obj/opt2/branches/head/src/sys/MYKERNEL1\n
#define RELSTR 9.0-BETA2
char sccs[sizeof(SCCSSTR) 128 ? sizeof(SCCSSTR) : 128] = SCCSSTR;
char version[sizeof(VERSTR) 256 ? sizeof(VERSTR) : 256] =
Re: [PATCH] Default scrub interval to whole weeks
On Thu, Oct 27, 2011 at 12:02:22PM -0700, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think it might be better if we set scrub interval to whole weeks (proposed changeset changes it to 5 weeks). The reason for this is to make it easier for system administrators to estimate when the scrub happens, for instance, if a scrub was done on Saturday, it always happen on Saturdays. [...] Sounds reasonable. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpRonlwMWRTb.pgp Description: PGP signature
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/27/2011 12:05, Craig Rodrigues wrote: On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton do...@freebsd.org wrote: The attached implements that, and is almost certainly the right way to go. It would be nice if someone could test it, and better if someone else could commit it. I swore after the last time that I'd stay away from that file precisely because of all the bikeshed stupidity that this issue creates. Hi, I tested your patch and it works. I am attaching vers.c files which I generated in trees which were under svn control, and not under svn control. Thanks for testing the non-svn case. I just committed the patch. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panics after AHCI timeouts
On Wed, 26 Oct 2011 16:00:55 +0200 C. P. Ghost cpgh...@cordula.ws wrote: On Wed, Oct 26, 2011 at 2:27 AM, Alexander Kabaev kab...@gmail.com wrote: I do see timeouts on one of my Samsung ST3750330A disks and they definitely do not cause any panics. The weird part in my case is that disk then immediately reappears as online and mirror zpool can be rebuilt by just onlining the disk with 'zpool online pool disk' command. It seems to be happening once system has accumulated some uptime. If rebooted, it keeps running for a week or two with no issues, but then timeouts start to happen more or less reliably every single 24 hours. Does it correlate with high disk activity, i.e. with periodic(8)? On my machine, I have a feeling that timeouts occur more often at that point, than normally... and that they also occur when multiple processes access the disk simultaneously. If it's only one process, the machine (usually) doesn't hang, even when that process is copying big files back and forth for a long period of time (it's a backup process). But interleave that process with another one accessing the same disk, and poof!, almost immediately ahci timeouts. occur. Very strange... Maybe a race condition of some sort after all? No, I cannot say there is any specific correlation to IO load of the machine, timeouts I saw happen randomly and seem almost always happen as system uptime crosses two weeks boundary. I am suspecting Samsung firmware at this point. -- Alexander Kabaev signature.asc Description: PGP signature
RE: Panics after AHCI timeouts
If it's only one process, the machine (usually) doesn't hang, even when that process is copying big files back and forth for a long period of time (it's a backup process). But interleave that process with another one accessing the same disk, and poof!, almost immediately ahci timeouts. occur. Very strange... Maybe a race condition of some sort after all? No, I cannot say there is any specific correlation to IO load of the machine, timeouts I saw happen randomly and seem almost always happen as system uptime crosses two weeks boundary. I am suspecting Samsung firmware at this point. Now that's interesting as I use a mixture of Samsung, WD, and Seagate.. And I do believe the Samsungs tend to do this more. I see ACHI timeouts from time to time on my machine (10-Current AMD64) but normally only when I am doing something like a scrub. The machine has never panicked as a result of this, it normally just FAULTS the drive in the pool and keeps on going. At that point, doing a camcontrol rescan all does not bring the drive back into existence (it will normally just hang on that bus for 15-20 seconds and then carry on without identifying a drive). I have to pull the drive, let it spin down and then reinsert it. Once its reinserted, the drive comes back on the bus and I can online it again. The weird thing is this.. For me, it only ever seems to be when I am writing to the pool/disk. Pure reads don't seem to bother it. I don't really know at this point if the SATA ports have gone wonkey on the motherboard, or if the processor on the HD has crashed. I almost tend to believe it's the drive because camcontrol stops on that port almost as it if knows there is a link there, but can't talk to it. Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC1 panic in tcp_input: negative winow.
On 10/26/11 22:53, John Baldwin wrote: On Wednesday, October 26, 2011 3:54:31 am Pawel Jakub Dawidek wrote: On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: My suggestion would be that if we won't be able to fix it before 9.0, we should turn this assertion off, as the system seems to be able to recover. Shipped kernels have all assertions turned off. Yes, I'm aware of that, but many people compile their production kernels with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing it into a printf, so it will be visible. No, the kernel is corrupting things in other places when this is true, so if you are running with INVARIANTS, we want to know about it. Specifically, in several places in TCP we assume that rcv_adv= rcv_nxt, and depend on being able to do 'rcv_adv - rcv_nxt'. In this case, it looks like the difference is consistently less than one frame. I suspect the other end of the connection is sending just beyond the end of the advertised window (it probably assumes it is better to send a full frame if it has that much pending data even though part of it is beyond the window edge vs sending a truncated packet that just fills the window) and that that frame is accepted ok in the header prediction case and it's ACK is delayed, but the next packet to arrive then trips over this assumption. Since 'win' is guaranteed to be non-negative and we explicitly cast 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking for: tp-rcv_wnd = imax(win, (int)(tp-rcv_adv - tp-rcv_nxt)); I think we already handle this case ok and perhaps the assertion can just be removed? Not sure if others feel that it warrants a comment to note that this is the case being handled. I added debug to the places where rcv_adv and rcv_nxt are modified. Here is what happens before the panic occurs: tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022361548 rcv_adv 4022360100 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022362298 rcv_adv 4022361548 diff -750 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022363746 rcv_adv 4022362298 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022364836 rcv_adv 4022363746 diff -1090 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022366284 rcv_adv 4022364836 diff -1448 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022370628 rcv_adv 4022369690 diff -938 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022379140 rcv_adv 4022377692 diff -1448 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022387792 rcv_adv 4022386344 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022388890 rcv_adv 4022387792 diff -1098 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022390338 rcv_adv 4022388890 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 diff -221 panic: tcp_input negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 win=0 diff -221 I can send you the full log if you want, I've plenty of messages where rcv_adv rcv_nxt, not all of them trigger this assertion. The assertion would be triggered when the next packet arrives (as I said above). Try modifying your debugging output to also log if the ACK is delayed. I suspect it is not delayed until the last one. (Pushing out an ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case of an immediate ACK, rcv_nxt rcv_adv is only a transient condition all under a single lock invocation so never visible to other consumers of the protocol control block.) If that is what you see, then that confirms what I guessed above and I will likely just remove the assertion in tcp_input() and patch the timewait code to handle this case. Pawel, have you been able to confirm John's hypothesis? What I don't quite get is why we haven't had a lot more reports of this issue... Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
samba+zfs
Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs its taking over an hour to just mux in things like DTS english, where it was 15 minutes on beta3. Dan. - Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make installworld fails on releng9
I had some issues while running make installworld after I sync'd to the latest releng9, on my RC1 install. Now, it appears to failed, while trying to create some links, chfn chsh ypchpass ypchfn ypchsh. These are supposed to be hardlinked to /usr/bin/chpass, except that, since the other files already exist, and are immutable, make installworld was unable to do anything, so I wound up removing the immutable flag on these files and re- running make installworld. I didn't see any mention of this little.. issue, in UPDATING, or in the - current mailing list (yes, I know, 9.0 is no longer technically, current, but since it isn't released yet, I figure it's close enough) -- Chuck Burns ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make installworld fails on releng9
On Thu, 27 Oct 2011, Chuck Burns wrote: I had some issues while running make installworld after I sync'd to the latest releng9, on my RC1 install. Now, it appears to failed, while trying to create some links, chfn chsh ypchpass ypchfn ypchsh. These are supposed to be hardlinked to /usr/bin/chpass, except that, since the other files already exist, and are immutable, make installworld was unable to do anything, so I wound up removing the immutable flag on these files and re- running make installworld. I didn't see any mention of this little.. issue, in UPDATING, or in the - current mailing list (yes, I know, 9.0 is no longer technically, current, but since it isn't released yet, I figure it's close enough) I'm seeing this on head (226827, amd64), also. MfG CoCo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC1 panic in tcp_input: negative winow.
On Fri, Oct 28, 2011 at 11:29:34AM +1100, Lawrence Stewart wrote: On 10/26/11 22:53, John Baldwin wrote: The assertion would be triggered when the next packet arrives (as I said above). Try modifying your debugging output to also log if the ACK is delayed. I suspect it is not delayed until the last one. (Pushing out an ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case of an immediate ACK, rcv_nxt rcv_adv is only a transient condition all under a single lock invocation so never visible to other consumers of the protocol control block.) If that is what you see, then that confirms what I guessed above and I will likely just remove the assertion in tcp_input() and patch the timewait code to handle this case. Pawel, have you been able to confirm John's hypothesis? [...] Yeah, sorry. I moved the debug to the points where we drop the t_inpcb lock and I still see rcv_nxt being greater than rcv_adv: tcp_do_segment:2970 negative window: tp 0xfe00685ee3d0 rcv_nxt 1312878324 rcv_adv 1312878187 This is just before the INP_WUNLOCK(tp-t_inpcb) under 'check_delack' label. I see this a lot (it was logged 545 times for 11 different tp pointers during 24h period). tcp_do_segment:3009 negative window: tp 0xfe005cfc6000 rcv_nxt 1442546453 rcv_adv 1442545722 This is just before calling tcp_output(). This one was logged 65 times for 3 different tp pointers. I placed a debug also after tcp_output() call, but it is not logged, so once we return from tcp_output() everything is fine. The panic would be triggered 115 times for 5 different tp pointers during that time. I write 'tp pointers' as I'm not 100% sure if the same pointer always represents the same connection or if it is reused. [...] What I don't quite get is why we haven't had a lot more reports of this issue... Maybe because my TCP/IP stack is heavly modified? ...not:) No idea to be honest. Ask Ken to turn on INVARIANTS in 9.0-RC2 and we will see:) -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpN4xRhoFGYE.pgp Description: PGP signature
