[releng_8 tinderbox] source tree update failure
TB --- 2013-07-08 08:10:00 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-07-08 08:10:00 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-08 08:10:00 - starting RELENG_8 tinderbox run for none/none TB --- 2013-07-08 08:10:00 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-07-08 08:10:00 - cd /tinderbox/RELENG_8/none/none TB --- 2013-07-08 08:10:00 - /usr/local/bin/svn cleanup /src TB --- 2013-07-08 08:10:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:12:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:12:35 - WARNING: sleeping 30 s and retrying... TB --- 2013-07-08 08:13:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:15:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:15:35 - WARNING: sleeping 60 s and retrying... TB --- 2013-07-08 08:16:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:19:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:19:05 - WARNING: sleeping 90 s and retrying... TB --- 2013-07-08 08:20:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:23:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:23:05 - WARNING: sleeping 120 s and retrying... TB --- 2013-07-08 08:25:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:27:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:27:35 - ERROR: unable to check out the source tree TB --- 2013-07-08 08:27:35 - 1.36 user 2.16 system 1055.66 real http://tinderbox.freebsd.org/tinderbox-freebsd8-update-RELENG_8-none-none.full ___ 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"
[releng_8_4 tinderbox] source tree update failure
TB --- 2013-07-08 08:10:00 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-07-08 08:10:00 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-08 08:10:00 - starting RELENG_8_4 tinderbox run for none/none TB --- 2013-07-08 08:10:00 - checking out /src from svn://svn.freebsd.org/base/releng/8.4 TB --- 2013-07-08 08:10:00 - cd /tinderbox/RELENG_8_4/none/none TB --- 2013-07-08 08:10:00 - /usr/local/bin/svn cleanup /src TB --- 2013-07-08 08:10:04 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:12:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:12:35 - WARNING: sleeping 30 s and retrying... TB --- 2013-07-08 08:13:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:15:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:15:35 - WARNING: sleeping 60 s and retrying... TB --- 2013-07-08 08:16:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:19:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:19:05 - WARNING: sleeping 90 s and retrying... TB --- 2013-07-08 08:20:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:23:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:23:05 - WARNING: sleeping 120 s and retrying... TB --- 2013-07-08 08:25:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:27:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:27:35 - ERROR: unable to check out the source tree TB --- 2013-07-08 08:27:35 - 1.44 user 1.98 system 1055.66 real http://tinderbox.freebsd.org/tinderbox-freebsd8-update-RELENG_8_4-none-none.full ___ 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"
Current problem reports assigned to freebsd-stable@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o i386/179112 stable 9.1 installer panics with a kmem_malloc() failure on i 1 problem total. ___ 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: status of autotuning freebsd for 9.2
On 07.07.2013 20:24, Alfred Perlstein wrote: On 7/7/13 1:34 AM, Andre Oppermann wrote: Can you help me with with testing? Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff This is functional bundle MFC of these original commits: MFC r242029 (alfred): Allow autotune maxusers > 384 on 64 bit machines. MFC r242847 (alfred): Allow maxusers to scale on machines with large address space. MFC r243631 (andre): Base the mbuf related limits on the available physical memory or kernel memory, whichever is lower. The overall mbuf related memory limit must be set so that mbufs (and clusters of various sizes) can't exhaust physical RAM or KVM. At the same time divorce maxfiles from maxusers and set maxfiles to physpages / 8 with a floor based on maxusers. This way busy servers can make use of the significantly increased mbuf limits with a much larger number of open sockets. MFC r243639 (andre): Complete r243631 by applying the remainder of kern_mbuf.c that got lost while merging into the commit tree. MFC r243668 (andre): Using a long is the wrong type to represent the realmem and maxmbufmem variable as they may overflow on i386/PAE and i386 with > 2GB RAM. MFC r243995, r243996, r243997 (pjd): Style cleanups, Make use of the fact that uma_zone_set_max(9) already returns actual limit set. MFC r244080 (andre): Prevent long type overflow of realmem calculation on ILP32 by forcing calculation to be in quad_t space. Fix style issue with second parameter to qmin(). MFC r245469 (alfred): Do not autotune ncallout to be greater than 18508. MFC r245575 (andre): Move the mbuf memory limit calculations from init_param2() to tunable_mbinit() where it is next to where it is used later. MFC r246207 (andre): Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. MFC r249843 (andre): Base the calculation of maxmbufmem in part on kmem_map size instead of kernel_map size to prevent kernel memory exhaustion by mbufs and a subsequent panic on physical page allocation failure. -- Andre ___ 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: status of autotuning freebsd for 9.2
On Mon, Jul 8, 2013 at 10:37 AM, Andre Oppermann wrote: > On 07.07.2013 20:24, Alfred Perlstein wrote: > >> On 7/7/13 1:34 AM, Andre Oppermann wrote: >> >>> Can you help me with with testing? >>> >>> Yes. Please give me your proposed changes and I'll stand up a machine >> and give feedback. >> > > http://people.freebsd.org/~**andre/mfc-autotuning-20130708.**diff<http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff> > > This is functional bundle MFC of these original commits: > > MFC r242029 (alfred): > > Allow autotune maxusers > 384 on 64 bit machines. > > MFC r242847 (alfred): > > Allow maxusers to scale on machines with large address space. > > MFC r243631 (andre): > > Base the mbuf related limits on the available physical memory or > kernel memory, whichever is lower. The overall mbuf related memory > limit must be set so that mbufs (and clusters of various sizes) > can't exhaust physical RAM or KVM. > > At the same time divorce maxfiles from maxusers and set maxfiles to > physpages / 8 with a floor based on maxusers. This way busy servers > can make use of the significantly increased mbuf limits with a much > larger number of open sockets. > > MFC r243639 (andre): > > Complete r243631 by applying the remainder of kern_mbuf.c that got > lost while merging into the commit tree. > > MFC r243668 (andre): > > Using a long is the wrong type to represent the realmem and maxmbufmem > variable as they may overflow on i386/PAE and i386 with > 2GB RAM. > > MFC r243995, r243996, r243997 (pjd): > > Style cleanups, Make use of the fact that uma_zone_set_max(9) already > returns actual limit set. > > MFC r244080 (andre): > > Prevent long type overflow of realmem calculation on ILP32 by forcing > calculation to be in quad_t space. Fix style issue with second parameter > to qmin(). > > MFC r245469 (alfred): > > Do not autotune ncallout to be greater than 18508. > > MFC r245575 (andre): > > Move the mbuf memory limit calculations from init_param2() to > tunable_mbinit() where it is next to where it is used later. > > MFC r246207 (andre): > > Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. > > MFC r249843 (andre): > > Base the calculation of maxmbufmem in part on kmem_map size > instead of kernel_map size to prevent kernel memory exhaustion > by mbufs and a subsequent panic on physical page allocation > failure. > > > would it be safe to throw a couple of high end storage systems into this testing pool ?? each has 128G Memory, and dual quad core procs, with 10GB Intel interfaces all they are design to do it samba and nfs and ive been fighting performance with samba and nfs on these systems, Id be curious if autotuning might help, to be honest, theres so much to tweak for samba, nfs, zfs alone in different formats, im surprised anyone has it running efficiently. > -- > Andre > > > __**_ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable<http://lists.freebsd.org/mailman/listinfo/freebsd-stable> > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@**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: status of autotuning freebsd for 9.2
On 08.07.2013 16:41, Outback Dingo wrote: On Mon, Jul 8, 2013 at 10:37 AM, Andre Oppermann mailto:an...@freebsd.org>> wrote: On 07.07.2013 20:24, Alfred Perlstein wrote: On 7/7/13 1:34 AM, Andre Oppermann wrote: Can you help me with with testing? Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. http://people.freebsd.org/~__andre/mfc-autotuning-20130708.__diff <http://people.freebsd.org/%7Eandre/mfc-autotuning-20130708.diff> This is functional bundle MFC of these original commits: MFC r242029 (alfred): Allow autotune maxusers > 384 on 64 bit machines. MFC r242847 (alfred): Allow maxusers to scale on machines with large address space. MFC r243631 (andre): Base the mbuf related limits on the available physical memory or kernel memory, whichever is lower. The overall mbuf related memory limit must be set so that mbufs (and clusters of various sizes) can't exhaust physical RAM or KVM. At the same time divorce maxfiles from maxusers and set maxfiles to physpages / 8 with a floor based on maxusers. This way busy servers can make use of the significantly increased mbuf limits with a much larger number of open sockets. MFC r243639 (andre): Complete r243631 by applying the remainder of kern_mbuf.c that got lost while merging into the commit tree. MFC r243668 (andre): Using a long is the wrong type to represent the realmem and maxmbufmem variable as they may overflow on i386/PAE and i386 with > 2GB RAM. MFC r243995, r243996, r243997 (pjd): Style cleanups, Make use of the fact that uma_zone_set_max(9) already returns actual limit set. MFC r244080 (andre): Prevent long type overflow of realmem calculation on ILP32 by forcing calculation to be in quad_t space. Fix style issue with second parameter to qmin(). MFC r245469 (alfred): Do not autotune ncallout to be greater than 18508. MFC r245575 (andre): Move the mbuf memory limit calculations from init_param2() to tunable_mbinit() where it is next to where it is used later. MFC r246207 (andre): Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. MFC r249843 (andre): Base the calculation of maxmbufmem in part on kmem_map size instead of kernel_map size to prevent kernel memory exhaustion by mbufs and a subsequent panic on physical page allocation failure. would it be safe to throw a couple of high end storage systems into this testing pool ?? each has 128G Memory, and dual quad core procs, with 10GB Intel interfaces all they are design to do it samba and nfs and ive been fighting performance with samba and nfs on these systems, Id be curious if autotuning might help, to be honest, theres so much to tweak for samba, nfs, zfs alone in different formats, im surprised anyone has it running efficiently. I don't know enough about the limits of Samba setups. Testing this MFC may or may not significantly improve the performance, though at least we'll know that it doesn't hurt. -- Andre ___ 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: USB ports on Lenovo T400 do not work after a suspend/resume
On 7 July 2013 22:00, Ian Smith wrote: > Checking one more point .. do the USB ports come up ok if you originally > boot with nothing plugged in? If so (or if not), does that local APIC Yes. > error message appear the same then too? > No -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: USB ports on Lenovo T400 do not work after a suspend/resume
On Sunday, June 30, 2013 10:22:09 am Ian Smith wrote: > On Sat, 29 Jun 2013, Adrian Chadd wrote: > > On 27 June 2013 04:58, Ian Smith wrote: > > > We don't yet know if this is a bus, ACPI &/or USB issue. Home yet? :) > > > > Yup: > > > > http://people.freebsd.org/~adrian/usb/ > > > > dmesg.boot = dmesg at startup > > > > 1 - after powerup, usb device in > > 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in > > 3 - after acpiconf -s3 suspend/resume, with a USB device removed > > before suspend/resume > > After removing [numbers] (for WITNESS?), diff started making sense. > The below is between the first and second suspend/resume cycles in > dmesg-3.txt, encompassing the others. > > Nothing of note that I can see, if that usb hub-to-bus remapping is > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > Maybe someone who knows might comment on that? >From sys/amd64/include/apicreg.h: /* fields in ESR */ #define APIC_ESR_SEND_CS_ERROR 0x0001 #define APIC_ESR_RECEIVE_CS_ERROR 0x0002 #define APIC_ESR_SEND_ACCEPT0x0004 #define APIC_ESR_RECEIVE_ACCEPT 0x0008 #define APIC_ESR_SEND_ILLEGAL_VECTOR0x0020 #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x0040 #define APIC_ESR_ILLEGAL_REGISTER 0x0080 Receive illegal vector (if look in Intel's SDM manuals) means it got an interrupt vector < 32 (probably zero). Perhaps it asserted an interrupt in an I/O APIC before the I/O APIC was properly reset? Are you using MSI at all? -- 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"
Re: USB ports on Lenovo T400 do not work after a suspend/resume
On 8 July 2013 11:19, John Baldwin wrote: > From sys/amd64/include/apicreg.h: This system runs an i386 kernel. > /* fields in ESR */ > #define APIC_ESR_SEND_CS_ERROR 0x0001 > #define APIC_ESR_RECEIVE_CS_ERROR 0x0002 > #define APIC_ESR_SEND_ACCEPT0x0004 > #define APIC_ESR_RECEIVE_ACCEPT 0x0008 > #define APIC_ESR_SEND_ILLEGAL_VECTOR0x0020 > #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x0040 > #define APIC_ESR_ILLEGAL_REGISTER 0x0080 > > Receive illegal vector (if look in Intel's SDM manuals) means it > got an interrupt vector < 32 (probably zero). Perhaps it asserted > an interrupt in an I/O APIC before the I/O APIC was properly reset? > Are you using MSI at all? I think iwn uses MSI. I'm sure other hardware in here does. I can dig through it and let you know. -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"
