Re: svn commit: r269814 - head/sys/dev/xen/blkfront
El 29/08/14 a les 19.52, Roger Pau Monné ha escrit: > El 28/08/14 a les 20.58, Alexander Motin ha escrit: >> On 28.08.2014 21:45, John-Mark Gurney wrote: >>> Alexander Motin wrote this message on Thu, Aug 28, 2014 at 21:23 +0300: Hi, Roger. It looks to me like this commit does not work as it should. I got problem when I just tried `newfs /dev/ada0 ; mount /dev/ada0 /mnt`. Somehow newfs does not produce valid filesystem. Problem is reliably repeatable and reverting this commit fixes it. I found at least one possible cause there: If original data buffer is unmapped, misaligned and not physically contiguous, then present x86 bus_dmamap_load_bio() implementation will process each physically contiguous segment separately. Due to the misalignment first and last physical segments may have size not multiple to 512 bytes. Since each segment processed separately, they are not joined together, and xbd_queue_cb() is getting segments not multiple to 512 bytes. Attempt to convert them to exact number of sectors in the driver cause data corruption. >>> >>> Are you sure this isn't a problem w/ the tag not properly specifying >>> the correct alignement? >> >> I don't know how to specify it stronger then this: >> error = bus_dma_tag_create( >> bus_get_dma_tag(sc->xbd_dev), /* parent */ >> 512, PAGE_SIZE, /* algnmnt, boundary */ >> BUS_SPACE_MAXADDR, /* lowaddr */ >> BUS_SPACE_MAXADDR, /* highaddr */ >> NULL, NULL, /* filter, filterarg */ >> sc->xbd_max_request_size, >> sc->xbd_max_request_segments, >> PAGE_SIZE, /* maxsegsize */ >> BUS_DMA_ALLOCNOW, /* flags */ >> busdma_lock_mutex, /* lockfunc */ >> &sc->xbd_io_lock, /* lockarg */ >> &sc->xbd_io_dmat); >> >>> Also, I don't think there is a way for busdma >>> to say that you MUST have a segment be a multiple of 512, though you >>> could use a 512 boundary, but that would force all segments to only be >>> 512 bytes... >> >> As I understand, that is mandatory requirement for this "hardware". >> Alike 4K alignment requirement also exist at least for SDHCI, and IIRC >> UHCI/OHCI hardware. Even AHCI requires both segment addresses and >> lengths to be even. >> >> I may be wrong, but I think it is quite likely that hardware that >> requires segment address alignment quite likely will have the same >> requirements for segments length. Hello, I have the following fix, which makes sure the total length and the size of each segment is aligned. I'm not very knowledgeable of the busdma code, so someone has to review it. Roger. --- diff --git a/sys/x86/x86/busdma_bounce.c b/sys/x86/x86/busdma_bounce.c index d1c75f8..688f559 100644 --- a/sys/x86/x86/busdma_bounce.c +++ b/sys/x86/x86/busdma_bounce.c @@ -620,6 +620,8 @@ bounce_bus_dmamap_load_phys(bus_dma_tag_t dmat, bus_dmamap_t map, segs = dmat->segments; if ((dmat->bounce_flags & BUS_DMA_COULD_BOUNCE) != 0) { + /* Make sure buflen is aligned */ + buflen = roundup2(buflen, dmat->common.alignment); _bus_dmamap_count_phys(dmat, map, buf, buflen, flags); if (map->pagesneeded != 0) { error = _bus_dmamap_reserve_pages(dmat, map, flags); @@ -634,6 +636,7 @@ bounce_bus_dmamap_load_phys(bus_dma_tag_t dmat, bus_dmamap_t map, if (((dmat->bounce_flags & BUS_DMA_COULD_BOUNCE) != 0) && map->pagesneeded != 0 && bus_dma_run_filter(&dmat->common, curaddr)) { + sgsize = roundup2(sgsize, dmat->common.alignment); sgsize = MIN(sgsize, PAGE_SIZE); curaddr = add_bounce_page(dmat, map, 0, curaddr, sgsize); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270964 - head/sys/sys
Author: ed Date: Tue Sep 2 11:16:44 2014 New Revision: 270964 URL: http://svnweb.freebsd.org/changeset/base/270964 Log: Clean up slightly. - Remove c++0x hack from that was needed when Clang did not fully implement C++11. We can now safely test against C++11 to check whether thread_local is available, like we do for all other C++11 keywords. - Don't use __clang__ to test for thread safety annotation presence. It turns out we have a proper attribute for this. Modified: head/sys/sys/cdefs.h Modified: head/sys/sys/cdefs.h == --- head/sys/sys/cdefs.hTue Sep 2 10:35:04 2014(r270963) +++ head/sys/sys/cdefs.hTue Sep 2 11:16:44 2014(r270964) @@ -298,8 +298,7 @@ #endif #if !__has_extension(c_thread_local) -/* XXX: Change this to test against C++11 when clang in base supports it. */ -#if /* (defined(__cplusplus) && __cplusplus >= 201103L) || */ \ +#if (defined(__cplusplus) && __cplusplus >= 201103L) || \ __has_extension(cxx_thread_local) #define_Thread_local thread_local #else @@ -751,7 +750,7 @@ * held. */ -#ifdef __clang__ +#if __has_extension(c_thread_safety_attributes) #define__lock_annotate(x) __attribute__((x)) #else #define__lock_annotate(x) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica
On Saturday, August 30, 2014 3:58:09 pm Konstantin Belousov wrote: > On Sat, Aug 30, 2014 at 05:48:38PM +, John Baldwin wrote: > > Author: jhb > > Date: Sat Aug 30 17:48:38 2014 > > New Revision: 270850 > > URL: http://svnweb.freebsd.org/changeset/base/270850 > > > > Log: > > Save and restore FPU state across suspend and resume. In earlier revisions > > of this patch, resumectx() called npxresume() directly, but that doesn't > > work because resumectx() runs with a non-standard %cs selector. Instead, > > all of the FPU suspend/resume handling is done in C. > > > > MFC after:1 week > > > > Modified: > > head/sys/i386/i386/mp_machdep.c > > head/sys/i386/i386/swtch.s > > head/sys/i386/include/npx.h > > head/sys/i386/include/pcb.h > > head/sys/i386/isa/npx.c > > head/sys/x86/acpica/acpi_wakeup.c > > > > Modified: head/sys/i386/i386/mp_machdep.c > > == > > --- head/sys/i386/i386/mp_machdep.c Sat Aug 30 17:39:28 2014 > > (r270849) > > +++ head/sys/i386/i386/mp_machdep.c Sat Aug 30 17:48:38 2014 > > (r270850) > > @@ -1522,9 +1522,15 @@ cpususpend_handler(void) > > > > cpu = PCPU_GET(cpuid); > > if (savectx(susppcbs[cpu])) { > > +#ifdef DEV_NPX > > + npxsuspend(&suspcbs[cpu]->pcb_fpususpend); > > +#endif > > wbinvd(); > > CPU_SET_ATOMIC(cpu, &suspended_cpus); > > } else { > > +#ifdef DEV_NPX > > + npxresume(&suspcbs[cpu]->pcb_fpususpend); > > +#endif > > pmap_init_pat(); > > PCPU_SET(switchtime, 0); > > PCPU_SET(switchticks, ticks); > > > > Modified: head/sys/i386/i386/swtch.s > > == > > --- head/sys/i386/i386/swtch.s Sat Aug 30 17:39:28 2014 > > (r270849) > > +++ head/sys/i386/i386/swtch.s Sat Aug 30 17:48:38 2014 > > (r270850) > > @@ -416,45 +416,6 @@ ENTRY(savectx) > > sldtPCB_LDT(%ecx) > > str PCB_TR(%ecx) > > > > -#ifdef DEV_NPX > > - /* > > -* If fpcurthread == NULL, then the npx h/w state is irrelevant and the > > -* state had better already be in the pcb. This is true for forks > > -* but not for dumps (the old book-keeping with FP flags in the pcb > > -* always lost for dumps because the dump pcb has 0 flags). > > -* > > -* If fpcurthread != NULL, then we have to save the npx h/w state to > > -* fpcurthread's pcb and copy it to the requested pcb, or save to the > > -* requested pcb and reload. Copying is easier because we would > > -* have to handle h/w bugs for reloading. We used to lose the > > -* parent's npx state for forks by forgetting to reload. > > -*/ > > - pushfl > > - CLI > > - movlPCPU(FPCURTHREAD),%eax > > - testl %eax,%eax > > - je 1f > > - > > - pushl %ecx > > - movlTD_PCB(%eax),%eax > > - movlPCB_SAVEFPU(%eax),%eax > > - pushl %eax > > - pushl %eax > > - callnpxsave > > - addl$4,%esp > > - popl%eax > > - popl%ecx > > - > > - pushl $PCB_SAVEFPU_SIZE > > - lealPCB_USERFPU(%ecx),%ecx > > - pushl %ecx > > - pushl %eax > > - callbcopy > > - addl$12,%esp > > -1: > > - popfl > > -#endif /* DEV_NPX */ > > - > > movl$1,%eax > > ret > > END(savectx) > > @@ -519,10 +480,6 @@ ENTRY(resumectx) > > movlPCB_DR7(%ecx),%eax > > movl%eax,%dr7 > > > > -#ifdef DEV_NPX > > - /* XXX FIX ME */ > > -#endif > > - > > /* Restore other registers */ > > movlPCB_EDI(%ecx),%edi > > movlPCB_ESI(%ecx),%esi > > > > Modified: head/sys/i386/include/npx.h > > == > > --- head/sys/i386/include/npx.h Sat Aug 30 17:39:28 2014 > > (r270849) > > +++ head/sys/i386/include/npx.h Sat Aug 30 17:48:38 2014 > > (r270850) > > @@ -53,8 +53,10 @@ void npxexit(struct thread *td); > > intnpxformat(void); > > intnpxgetregs(struct thread *td); > > void npxinit(void); > > +void npxresume(union savefpu *addr); > > void npxsave(union savefpu *addr); > > void npxsetregs(struct thread *td, union savefpu *addr); > > +void npxsuspend(union savefpu *addr); > > intnpxtrap_x87(void); > > intnpxtrap_sse(void); > > void npxuserinited(struct thread *); > > > > Modified: head/sys/i386/include/pcb.h > > == > > --- head/sys/i386/include/pcb.h Sat Aug 30 17:39:28 2014 > > (r270849) > > +++ head/sys/i386/include/pcb.h Sat Aug 30 17:48:38 2014 > > (r270850) > > @@ -90,6 +90,8 @@ struct pcb { > > struct region_descriptor pcb_idt; > > uint16_tpcb_ldt; > > uint16_tpcb_tr; > > + > > + union savefpu pcb_fpu
Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica
On Tue, Sep 02, 2014 at 11:00:57AM -0400, John Baldwin wrote: > On Saturday, August 30, 2014 3:58:09 pm Konstantin Belousov wrote: > > On Sat, Aug 30, 2014 at 05:48:38PM +, John Baldwin wrote: > > > Author: jhb > > > Date: Sat Aug 30 17:48:38 2014 > > > New Revision: 270850 > > > URL: http://svnweb.freebsd.org/changeset/base/270850 > > > > > > Log: > > > Save and restore FPU state across suspend and resume. In earlier > revisions > > > of this patch, resumectx() called npxresume() directly, but that doesn't > > > work because resumectx() runs with a non-standard %cs selector. > Instead, > > > all of the FPU suspend/resume handling is done in C. > > > > > > MFC after: 1 week > > > > > > Modified: > > > head/sys/i386/i386/mp_machdep.c > > > head/sys/i386/i386/swtch.s > > > head/sys/i386/include/npx.h > > > head/sys/i386/include/pcb.h > > > head/sys/i386/isa/npx.c > > > head/sys/x86/acpica/acpi_wakeup.c > > > > > > Modified: head/sys/i386/i386/mp_machdep.c > > > > == > > > --- head/sys/i386/i386/mp_machdep.c Sat Aug 30 17:39:28 2014 > > > (r270849) > > > +++ head/sys/i386/i386/mp_machdep.c Sat Aug 30 17:48:38 2014 > > > (r270850) > > > @@ -1522,9 +1522,15 @@ cpususpend_handler(void) > > > > > > cpu = PCPU_GET(cpuid); > > > if (savectx(susppcbs[cpu])) { > > > +#ifdef DEV_NPX > > > + npxsuspend(&suspcbs[cpu]->pcb_fpususpend); > > > +#endif > > > wbinvd(); > > > CPU_SET_ATOMIC(cpu, &suspended_cpus); > > > } else { > > > +#ifdef DEV_NPX > > > + npxresume(&suspcbs[cpu]->pcb_fpususpend); > > > +#endif > > > pmap_init_pat(); > > > PCPU_SET(switchtime, 0); > > > PCPU_SET(switchticks, ticks); > > > > > > Modified: head/sys/i386/i386/swtch.s > > > > == > > > --- head/sys/i386/i386/swtch.sSat Aug 30 17:39:28 2014 > > > (r270849) > > > +++ head/sys/i386/i386/swtch.sSat Aug 30 17:48:38 2014 > > > (r270850) > > > @@ -416,45 +416,6 @@ ENTRY(savectx) > > > sldtPCB_LDT(%ecx) > > > str PCB_TR(%ecx) > > > > > > -#ifdef DEV_NPX > > > - /* > > > - * If fpcurthread == NULL, then the npx h/w state is irrelevant and > the > > > - * state had better already be in the pcb. This is true for forks > > > - * but not for dumps (the old book-keeping with FP flags in the pcb > > > - * always lost for dumps because the dump pcb has 0 flags). > > > - * > > > - * If fpcurthread != NULL, then we have to save the npx h/w state to > > > - * fpcurthread's pcb and copy it to the requested pcb, or save to the > > > - * requested pcb and reload. Copying is easier because we would > > > - * have to handle h/w bugs for reloading. We used to lose the > > > - * parent's npx state for forks by forgetting to reload. > > > - */ > > > - pushfl > > > - CLI > > > - movlPCPU(FPCURTHREAD),%eax > > > - testl %eax,%eax > > > - je 1f > > > - > > > - pushl %ecx > > > - movlTD_PCB(%eax),%eax > > > - movlPCB_SAVEFPU(%eax),%eax > > > - pushl %eax > > > - pushl %eax > > > - callnpxsave > > > - addl$4,%esp > > > - popl%eax > > > - popl%ecx > > > - > > > - pushl $PCB_SAVEFPU_SIZE > > > - lealPCB_USERFPU(%ecx),%ecx > > > - pushl %ecx > > > - pushl %eax > > > - callbcopy > > > - addl$12,%esp > > > -1: > > > - popfl > > > -#endif /* DEV_NPX */ > > > - > > > movl$1,%eax > > > ret > > > END(savectx) > > > @@ -519,10 +480,6 @@ ENTRY(resumectx) > > > movlPCB_DR7(%ecx),%eax > > > movl%eax,%dr7 > > > > > > -#ifdef DEV_NPX > > > - /* XXX FIX ME */ > > > -#endif > > > - > > > /* Restore other registers */ > > > movlPCB_EDI(%ecx),%edi > > > movlPCB_ESI(%ecx),%esi > > > > > > Modified: head/sys/i386/include/npx.h > > > > == > > > --- head/sys/i386/include/npx.h Sat Aug 30 17:39:28 2014 > > > (r270849) > > > +++ head/sys/i386/include/npx.h Sat Aug 30 17:48:38 2014 > > > (r270850) > > > @@ -53,8 +53,10 @@ void npxexit(struct thread *td); > > > int npxformat(void); > > > int npxgetregs(struct thread *td); > > > void npxinit(void); > > > +void npxresume(union savefpu *addr); > > > void npxsave(union savefpu *addr); > > > void npxsetregs(struct thread *td, union savefpu *addr); > > > +void npxsuspend(union savefpu *addr); > > > int npxtrap_x87(void); > > > int npxtrap_sse(void); > > > void npxuserinited(struct thread *); > > > > > > Modified: head/sys/i386/include/pcb.h > > > > == > > > --- head/sys/i386/include/pcb.h Sat Aug 30 17:39:28 2014 > > > (r270849) > > > +++ head/sys/i386/include/pcb.h Sat Aug 30 17:48
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote: > On Saturday 30 August 2014 02:03:42 Steven Hartland wrote: > I'm very disappointed in the attention to detail and errors in the commit. > I'm almost at the point where I want to ask for the whole thing to be backed > out. I would not be too supportive of that. This PR has been open for a long, long time with many users using patches from it in production loads that were greatly improved by the changes and clamoring on the lists multiple times to get someone to look at it. avg@ contributed quite a bit of time to diagnose this with Karl early on, but other developers aside from Steven did not. It also was not hard to explain to Karl the meaning of 'cache + free' in the bug follow-ups itself (though I believe avg@ had tried this before and it didn't sink in that time for some reason). I know Steven has since committed a fix, but if there are still concerns, I think it would be best to not just revert this entirely but to spend some time fixing the remaining issues. Clearly this issue affects a lot of users and the earlier fixes to pagedaemon were not sufficient to fix their issues alone. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
on 02/09/2014 19:01 John Baldwin said the following: > I know Steven has since committed a fix, but if there are still concerns, I > think it would be best to not just revert this entirely but to spend some > time > fixing the remaining issues. Clearly this issue affects a lot of users and > the earlier fixes to pagedaemon were not sufficient to fix their issues alone. I am not sure that that is the case. I could have very well missed an evidence of that, but then I'd appreciate a pointer or two to such reports. I am certainly sure that a large number of reports about "ZFS vs swapping" issue appeared after the pagedaemon problem was introduced. I have also missed any "theoretical" justification for the patch. That is, an explanation of how the patch interacts with the pagedaemon and improves things. The empirical evidence could be insufficient, because it's easy to tilt the balance such that the ARC gives in too easily. But people who were affected by the opposite problem could be different from people who would be affected by the new problem, because of differences in system characteristics such as amount of RAM, workload patterns, working set sizes, etc. Having said that, I do not ask for the changes to be reverted, but I'll probably get back after I have sufficient time to look at the patch and also to test its effect on my systems. This might not be very soon though. P.S. I think that there was no technical reason to initialize the newly introduced parameters via SYSINIT mechanism. I think that the initialization could be just done in arc_init. And the newly added kmem_foo() functions probably do not belong in cddl/compat/opensolaris as Solaris / illumos does not have those functions. I think that in this case e.g. vm_cnt.v_free_target can just be used directly by the FreeBSD-specific ARC code. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270971 - head/sys/boot/fdt/dts/arm
Author: imp Date: Tue Sep 2 16:38:00 2014 New Revision: 270971 URL: http://svnweb.freebsd.org/changeset/base/270971 Log: The proper compatibility string for the AHCI device is allwinner,sun4i-ahci, so use that instead of the older string which had become FreeBSD specific. Modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts head/sys/boot/fdt/dts/arm/sun4i-a10.dtsi head/sys/boot/fdt/dts/arm/sun7i-a20.dtsi Modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts == --- head/sys/boot/fdt/dts/arm/cubieboard2.dts Tue Sep 2 16:14:16 2014 (r270970) +++ head/sys/boot/fdt/dts/arm/cubieboard2.dts Tue Sep 2 16:38:00 2014 (r270971) @@ -60,6 +60,10 @@ emac@01c0b000 { status = "okay"; }; + + ahci: sata@01c18000 { + status = "okay"; + }; }; chosen { Modified: head/sys/boot/fdt/dts/arm/sun4i-a10.dtsi == --- head/sys/boot/fdt/dts/arm/sun4i-a10.dtsiTue Sep 2 16:14:16 2014 (r270970) +++ head/sys/boot/fdt/dts/arm/sun4i-a10.dtsiTue Sep 2 16:38:00 2014 (r270971) @@ -104,7 +104,7 @@ }; sata@01c18000 { - compatible = "allwinner,ahci"; + compatible = "allwinner,sun4i-ahci"; reg = <0x01c18000 0x1000>; interrupts = <56>; interrupt-parent = <&AINTC>; Modified: head/sys/boot/fdt/dts/arm/sun7i-a20.dtsi == --- head/sys/boot/fdt/dts/arm/sun7i-a20.dtsiTue Sep 2 16:14:16 2014 (r270970) +++ head/sys/boot/fdt/dts/arm/sun7i-a20.dtsiTue Sep 2 16:38:00 2014 (r270971) @@ -110,7 +110,7 @@ }; sata@01c18000 { - compatible = "allwinner,ahci"; + compatible = "allwinner,sun4i-a10-ahci"; reg = <0x01c18000 0x1000>; interrupts = <56>; interrupt-parent = <&GIC>; ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269814 - head/sys/dev/xen/blkfront
Roger Pau Monn wrote this message on Tue, Sep 02, 2014 at 11:30 +0200: > El 29/08/14 a les 19.52, Roger Pau Monné ha escrit: > > El 28/08/14 a les 20.58, Alexander Motin ha escrit: > >> On 28.08.2014 21:45, John-Mark Gurney wrote: > >>> Alexander Motin wrote this message on Thu, Aug 28, 2014 at 21:23 +0300: > Hi, Roger. > > It looks to me like this commit does not work as it should. I got > problem when I just tried `newfs /dev/ada0 ; mount /dev/ada0 /mnt`. > Somehow newfs does not produce valid filesystem. Problem is reliably > repeatable and reverting this commit fixes it. > > I found at least one possible cause there: If original data buffer is > unmapped, misaligned and not physically contiguous, then present x86 > bus_dmamap_load_bio() implementation will process each physically > contiguous segment separately. Due to the misalignment first and last > physical segments may have size not multiple to 512 bytes. Since each > segment processed separately, they are not joined together, and > xbd_queue_cb() is getting segments not multiple to 512 bytes. Attempt to > convert them to exact number of sectors in the driver cause data > corruption. > >>> > >>> Are you sure this isn't a problem w/ the tag not properly specifying > >>> the correct alignement? > >> > >> I don't know how to specify it stronger then this: > >> error = bus_dma_tag_create( > >> bus_get_dma_tag(sc->xbd_dev), /* parent */ > >> 512, PAGE_SIZE, /* algnmnt, boundary */ > >> BUS_SPACE_MAXADDR, /* lowaddr */ > >> BUS_SPACE_MAXADDR, /* highaddr */ > >> NULL, NULL, /* filter, filterarg */ > >> sc->xbd_max_request_size, > >> sc->xbd_max_request_segments, > >> PAGE_SIZE, /* maxsegsize */ > >> BUS_DMA_ALLOCNOW, /* flags */ > >> busdma_lock_mutex, /* lockfunc */ > >> &sc->xbd_io_lock, /* lockarg */ > >> &sc->xbd_io_dmat); > >> > >>> Also, I don't think there is a way for busdma > >>> to say that you MUST have a segment be a multiple of 512, though you > >>> could use a 512 boundary, but that would force all segments to only be > >>> 512 bytes... > >> > >> As I understand, that is mandatory requirement for this "hardware". > >> Alike 4K alignment requirement also exist at least for SDHCI, and IIRC > >> UHCI/OHCI hardware. Even AHCI requires both segment addresses and > >> lengths to be even. > >> > >> I may be wrong, but I think it is quite likely that hardware that > >> requires segment address alignment quite likely will have the same > >> requirements for segments length. > > Hello, > > I have the following fix, which makes sure the total length and the > size of each segment is aligned. I'm not very knowledgeable of the > busdma code, so someone has to review it. I feel that this alignment should only be enforced via a new option on the tag... I don't see how alignment and segment size should be conflated... I could totally see a device that requires an alignement of 8 bytes, but has a segment size of 16, or vice versa, and requiring them to be the same means we will bounce unnecesarily... cc'd scottl since he knows this code better than I... and cperciva as he touched it for similar reasons.. Oh, I just found PR 152818, where cperciva did a similar fix to bounce_bus_dmamap_load_buffer for the exact same reason... It was committed in r216194... > --- > diff --git a/sys/x86/x86/busdma_bounce.c b/sys/x86/x86/busdma_bounce.c > index d1c75f8..688f559 100644 > --- a/sys/x86/x86/busdma_bounce.c > +++ b/sys/x86/x86/busdma_bounce.c > @@ -620,6 +620,8 @@ bounce_bus_dmamap_load_phys(bus_dma_tag_t dmat, > bus_dmamap_t map, > segs = dmat->segments; > > if ((dmat->bounce_flags & BUS_DMA_COULD_BOUNCE) != 0) { > + /* Make sure buflen is aligned */ > + buflen = roundup2(buflen, dmat->common.alignment); > _bus_dmamap_count_phys(dmat, map, buf, buflen, flags); > if (map->pagesneeded != 0) { > error = _bus_dmamap_reserve_pages(dmat, map, flags); > @@ -634,6 +636,7 @@ bounce_bus_dmamap_load_phys(bus_dma_tag_t dmat, > bus_dmamap_t map, > if (((dmat->bounce_flags & BUS_DMA_COULD_BOUNCE) != 0) && > map->pagesneeded != 0 && > bus_dma_run_filter(&dmat->common, curaddr)) { > + sgsize = roundup2(sgsize, dmat->common.alignment); > sgsize = MIN(sgsize, PAGE_SIZE); > curaddr = add_bounce_page(dmat, map, 0, curaddr, > sgsize); > Doesn't this same change need to be made to _bus_dmamap_count_phys so that the cound will be correct? Also, make
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 09/02/2014 11:01, John Baldwin wrote: > On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote: >> On Saturday 30 August 2014 02:03:42 Steven Hartland wrote: >> I'm very disappointed in the attention to detail and errors in the commit. >> I'm almost at the point where I want to ask for the whole thing to be backed >> out. > I would not be too supportive of that. This PR has been open for a long, > long > time with many users using patches from it in production loads that were > greatly improved by the changes and clamoring on the lists multiple times to > get someone to look at it. avg@ contributed quite a bit of time to diagnose > this with Karl early on, but other developers aside from Steven did not. It > also was not hard to explain to Karl the meaning of 'cache + free' in the bug > follow-ups itself (though I believe avg@ had tried this before and it didn't > sink in that time for some reason). > > I know Steven has since committed a fix, but if there are still concerns, I > think it would be best to not just revert this entirely but to spend some > time > fixing the remaining issues. Clearly this issue affects a lot of users and > the earlier fixes to pagedaemon were not sufficient to fix their issues alone. > The patch actually makes two completely orthogonal changes at once, and one of those changes has no connection to the page daemon. I suspect that is why some people have said that their issues were not addressed by the page daemon fix. Prior to this patch, we were limiting the ARC size to 3/4 the kmem map/arena/object size on all architectures, including 64-bit, uma_small_alloc-enabled architectures where such a limit makes no sense. Consequently, some people were complaining, "Why is 1/4 of my memory going unused?" ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269814 - head/sys/dev/xen/blkfront
John-Mark Gurney wrote this message on Tue, Sep 02, 2014 at 10:18 -0700: > Roger Pau Monn wrote this message on Tue, Sep 02, 2014 at 11:30 +0200: > > El 29/08/14 a les 19.52, Roger Pau Monné ha escrit: > > > El 28/08/14 a les 20.58, Alexander Motin ha escrit: > > >> On 28.08.2014 21:45, John-Mark Gurney wrote: > > >>> Alexander Motin wrote this message on Thu, Aug 28, 2014 at 21:23 +0300: > > Hi, Roger. > > > > It looks to me like this commit does not work as it should. I got > > problem when I just tried `newfs /dev/ada0 ; mount /dev/ada0 /mnt`. > > Somehow newfs does not produce valid filesystem. Problem is reliably > > repeatable and reverting this commit fixes it. > > > > I found at least one possible cause there: If original data buffer is > > unmapped, misaligned and not physically contiguous, then present x86 > > bus_dmamap_load_bio() implementation will process each physically > > contiguous segment separately. Due to the misalignment first and last > > physical segments may have size not multiple to 512 bytes. Since each > > segment processed separately, they are not joined together, and > > xbd_queue_cb() is getting segments not multiple to 512 bytes. Attempt > > to > > convert them to exact number of sectors in the driver cause data > > corruption. > > >>> > > >>> Are you sure this isn't a problem w/ the tag not properly specifying > > >>> the correct alignement? > > >> > > >> I don't know how to specify it stronger then this: > > >> error = bus_dma_tag_create( > > >> bus_get_dma_tag(sc->xbd_dev), /* parent */ > > >> 512, PAGE_SIZE, /* algnmnt, boundary */ > > >> BUS_SPACE_MAXADDR, /* lowaddr */ > > >> BUS_SPACE_MAXADDR, /* highaddr */ > > >> NULL, NULL, /* filter, filterarg */ > > >> sc->xbd_max_request_size, > > >> sc->xbd_max_request_segments, > > >> PAGE_SIZE, /* maxsegsize */ > > >> BUS_DMA_ALLOCNOW, /* flags */ > > >> busdma_lock_mutex, /* lockfunc */ > > >> &sc->xbd_io_lock, /* lockarg */ > > >> &sc->xbd_io_dmat); > > >> > > >>> Also, I don't think there is a way for busdma > > >>> to say that you MUST have a segment be a multiple of 512, though you > > >>> could use a 512 boundary, but that would force all segments to only be > > >>> 512 bytes... > > >> > > >> As I understand, that is mandatory requirement for this "hardware". > > >> Alike 4K alignment requirement also exist at least for SDHCI, and IIRC > > >> UHCI/OHCI hardware. Even AHCI requires both segment addresses and > > >> lengths to be even. > > >> > > >> I may be wrong, but I think it is quite likely that hardware that > > >> requires segment address alignment quite likely will have the same > > >> requirements for segments length. > > > > Hello, > > > > I have the following fix, which makes sure the total length and the > > size of each segment is aligned. I'm not very knowledgeable of the > > busdma code, so someone has to review it. > > I feel that this alignment should only be enforced via a new option on > the tag... I don't see how alignment and segment size should be > conflated... I could totally see a device that requires an alignement > of 8 bytes, but has a segment size of 16, or vice versa, and requiring > them to be the same means we will bounce unnecesarily... > > cc'd scottl since he knows this code better than I... and cperciva as > he touched it for similar reasons.. > > Oh, I just found PR 152818, where cperciva did a similar fix to > bounce_bus_dmamap_load_buffer for the exact same reason... It was > committed in r216194... Also, if this change is made w/o adding a field to the tag, the busdma man page needs to be updated w/ the fact that alignment also forces segment sizes to be alignment sized... cperciva forgot this when he did his commit... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
- Original Message - From: "Alan Cox" On 09/02/2014 11:01, John Baldwin wrote: On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote: On Saturday 30 August 2014 02:03:42 Steven Hartland wrote: I'm very disappointed in the attention to detail and errors in the commit. I'm almost at the point where I want to ask for the whole thing to be backed out. I would not be too supportive of that. This PR has been open for a long, long time with many users using patches from it in production loads that were greatly improved by the changes and clamoring on the lists multiple times to get someone to look at it. avg@ contributed quite a bit of time to diagnose this with Karl early on, but other developers aside from Steven did not. It also was not hard to explain to Karl the meaning of 'cache + free' in the bug follow-ups itself (though I believe avg@ had tried this before and it didn't sink in that time for some reason). I know Steven has since committed a fix, but if there are still concerns, I think it would be best to not just revert this entirely but to spend some time fixing the remaining issues. Clearly this issue affects a lot of users and the earlier fixes to pagedaemon were not sufficient to fix their issues alone. The patch actually makes two completely orthogonal changes at once, and one of those changes has no connection to the page daemon. I suspect that is why some people have said that their issues were not addressed by the page daemon fix. Prior to this patch, we were limiting the ARC size to 3/4 the kmem map/arena/object size on all architectures, including 64-bit, uma_small_alloc-enabled architectures where such a limit makes no sense. Consequently, some people were complaining, "Why is 1/4 of my memory going unused?" This is exactly the problem which lead me into investigating the issue. It should be noted that for i386, as requested by Peter, this limitation has been re-applied. Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
- Original Message - From: "Andriy Gapon" on 02/09/2014 19:01 John Baldwin said the following: I know Steven has since committed a fix, but if there are still concerns, I think it would be best to not just revert this entirely but to spend some time fixing the remaining issues. Clearly this issue affects a lot of users and the earlier fixes to pagedaemon were not sufficient to fix their issues alone. I am not sure that that is the case. I could have very well missed an evidence of that, but then I'd appreciate a pointer or two to such reports. I am certainly sure that a large number of reports about "ZFS vs swapping" issue appeared after the pagedaemon problem was introduced. I have also missed any "theoretical" justification for the patch. That is, an explanation of how the patch interacts with the pagedaemon and improves things. The empirical evidence could be insufficient, because it's easy to tilt the balance such that the ARC gives in too easily. But people who were affected by the opposite problem could be different from people who would be affected by the new problem, because of differences in system characteristics such as amount of RAM, workload patterns, working set sizes, etc. Having said that, I do not ask for the changes to be reverted, but I'll probably get back after I have sufficient time to look at the patch and also to test its effect on my systems. This might not be very soon though. P.S. I think that there was no technical reason to initialize the newly introduced parameters via SYSINIT mechanism. I created the SYSINT as the values are not available early enough for the sysctl. I think that the initialization could be just done in arc_init. I thought I'd tested this when doing the initial implementation but it was a long week so I just did a quick re-test and confirmed arc_init is called before the pagedaemon is initialised so it can't be used in this case. On a side note it would be nice if ARC sysctls, which are currently done via arc_init, where cleaned up as currently the limits aren't enforced correctly when manually changed, as well as being split up into two locations making them hard to follow. Something I intend to look at when I get some free time. And the newly added kmem_foo() functions probably do not belong in cddl/compat/opensolaris as Solaris / illumos does not have those functions. They could be moved but their current location keeps all the kmem related functions neatly in one place. Spreading them around IMO would just make things hard to find. I think that in this case e.g. vm_cnt.v_free_target can just be used directly by the FreeBSD-specific ARC code. It could but as above keeping everything in one place makes it to find and hence MFC as this area has seen changes which will require all those fields renamed. It also means if the logic for free pages changes in the future there's only one place it needs to be changed. For those interested there's also an open review on additional changes in this area: https://reviews.freebsd.org/D702 Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269814 - head/sys/dev/xen/blkfront
On 09/02/14 10:18, John-Mark Gurney wrote: > cc'd scottl since he knows this code better than I... and cperciva as > he touched it for similar reasons.. > > Oh, I just found PR 152818, where cperciva did a similar fix to > bounce_bus_dmamap_load_buffer for the exact same reason... It was > committed in r216194... This was just a MFamd64 of r204214 -- at that point i386 and amd64 had separate busdma_bounce.c files with different sets of bug fixes. I don't think I ever fixed any new bugs; I just merged fixes between the two architectures and then (once they were identical) replaced them by a single x86 file (in r216316). This particular bug fix came from gibbs. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270972 - head/lib/libthr/thread
Author: rpaulo Date: Tue Sep 2 18:21:19 2014 New Revision: 270972 URL: http://svnweb.freebsd.org/changeset/base/270972 Log: Fix typo in a comment. Modified: head/lib/libthr/thread/thr_cond.c Modified: head/lib/libthr/thread/thr_cond.c == --- head/lib/libthr/thread/thr_cond.c Tue Sep 2 16:38:00 2014 (r270971) +++ head/lib/libthr/thread/thr_cond.c Tue Sep 2 18:21:19 2014 (r270972) @@ -150,7 +150,7 @@ _pthread_cond_destroy(pthread_cond_t *co } /* - * Cancellation behaivor: + * Cancellation behavior: * Thread may be canceled at start, if thread is canceled, it means it * did not get a wakeup from pthread_cond_signal(), otherwise, it is * not canceled. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270973 - head/sys/dev/mrsas
Author: kadesai Date: Tue Sep 2 18:32:41 2014 New Revision: 270973 URL: http://svnweb.freebsd.org/changeset/base/270973 Log: Fix for WITNESS warning while doing xpt_rescan. This happen when converting any JBOD to RAID or creating any new RAID from Unconfigured Drives. Without this fix, user may see below call trace if WITNESS is enabled. witness_warn() at witness_warn+0x4b5/frame 0xfe011f929a00 uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe011f929a70 malloc() at malloc+0x192/frame 0xfe011f929ac0 mrsas_bus_scan_sim() at mrsas_bus_scan_sim+0x32/frame 0xfe011f929af0 mrsas_aen_handler() at mrsas_aen_handler+0x11c/frame 0xfe011f929b20 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe011f929b80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfe011f929bb0 fork_exit() at fork_exit+0x84/frame 0xfe011f929bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe011f929bf0 Submitted by: kadesai Reviewed by:ambrisko MFC after: 3 days Modified: head/sys/dev/mrsas/mrsas.h head/sys/dev/mrsas/mrsas_cam.c Modified: head/sys/dev/mrsas/mrsas.h == --- head/sys/dev/mrsas/mrsas.h Tue Sep 2 18:21:19 2014(r270972) +++ head/sys/dev/mrsas/mrsas.h Tue Sep 2 18:32:41 2014(r270973) @@ -101,7 +101,7 @@ __FBSDID("$FreeBSD$"); */ #define BYTE_ALIGNMENT1 #define MRSAS_MAX_NAME_LENGTH 32 -#define MRSAS_VERSION "06.704.01.00-fbsd" +#define MRSAS_VERSION "06.704.01.01-fbsd" #define MRSAS_ULONG_MAX 0x #define MRSAS_DEFAULT_TIMEOUT 0x14 //temp #define DONE 0 Modified: head/sys/dev/mrsas/mrsas_cam.c == --- head/sys/dev/mrsas/mrsas_cam.c Tue Sep 2 18:21:19 2014 (r270972) +++ head/sys/dev/mrsas/mrsas_cam.c Tue Sep 2 18:32:41 2014 (r270973) @@ -1116,18 +1116,16 @@ int mrsas_bus_scan(struct mrsas_softc *s union ccb *ccb_0; union ccb *ccb_1; -mtx_lock(&sc->sim_lock); if ((ccb_0 = xpt_alloc_ccb()) == NULL) { -mtx_unlock(&sc->sim_lock); return(ENOMEM); } if ((ccb_1 = xpt_alloc_ccb()) == NULL) { xpt_free_ccb(ccb_0); -mtx_unlock(&sc->sim_lock); return(ENOMEM); } +mtx_lock(&sc->sim_lock); if (xpt_create_path(&ccb_0->ccb_h.path, xpt_periph, cam_sim_path(sc->sim_0), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP){ xpt_free_ccb(ccb_0); @@ -1144,9 +1142,9 @@ int mrsas_bus_scan(struct mrsas_softc *s return(EIO); } +mtx_unlock(&sc->sim_lock); xpt_rescan(ccb_0); xpt_rescan(ccb_1); -mtx_unlock(&sc->sim_lock); return(0); } @@ -1161,19 +1159,18 @@ int mrsas_bus_scan_sim(struct mrsas_soft { union ccb *ccb; -mtx_lock(&sc->sim_lock); if ((ccb = xpt_alloc_ccb()) == NULL) { -mtx_unlock(&sc->sim_lock); return(ENOMEM); } +mtx_lock(&sc->sim_lock); if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, cam_sim_path(sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP){ xpt_free_ccb(ccb); mtx_unlock(&sc->sim_lock); return(EIO); } -xpt_rescan(ccb); mtx_unlock(&sc->sim_lock); +xpt_rescan(ccb); return(0); } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 09/02/2014 12:34, Steven Hartland wrote: > - Original Message - From: "Alan Cox" > >> On 09/02/2014 11:01, John Baldwin wrote: >>> On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote: On Saturday 30 August 2014 02:03:42 Steven Hartland wrote: I'm very disappointed in the attention to detail and errors in the commit. I'm almost at the point where I want to ask for the whole thing to be backed out. >>> I would not be too supportive of that. This PR has been open for a >>> long, long time with many users using patches from it in production >>> loads that were greatly improved by the changes and clamoring on the >>> lists multiple times to get someone to look at it. avg@ contributed >>> quite a bit of time to diagnose this with Karl early on, but other >>> developers aside from Steven did not. It also was not hard to >>> explain to Karl the meaning of 'cache + free' in the bug follow-ups >>> itself (though I believe avg@ had tried this before and it didn't >>> sink in that time for some reason). >>> >>> I know Steven has since committed a fix, but if there are still >>> concerns, I think it would be best to not just revert this entirely >>> but to spend some time fixing the remaining issues. Clearly this >>> issue affects a lot of users and the earlier fixes to pagedaemon >>> were not sufficient to fix their issues alone. >>> >> >> The patch actually makes two completely orthogonal changes at once, and >> one of those changes has no connection to the page daemon. I suspect >> that is why some people have said that their issues were not addressed >> by the page daemon fix. >> >> Prior to this patch, we were limiting the ARC size to 3/4 the kmem >> map/arena/object size on all architectures, including 64-bit, >> uma_small_alloc-enabled architectures where such a limit makes no >> sense. Consequently, some people were complaining, "Why is 1/4 of my >> memory going unused?" > > This is exactly the problem which lead me into investigating the issue. > Is there any evidence that anything other than eliminating the KVA limit is needed on machines where the page daemon isn't broken? > It should be noted that for i386, as requested by Peter, this limitation > has been re-applied. > Unlike Solaris, we run on a few 32-bit architectures, besides i386, that don't have a direct map or a full 4GB address space for the kernel. So, for FreeBSD, this needs to be more general than just i386. I would suggest using '#ifndef UMA_MD_SMALL_ALLOC' as being the closest thing that we have to what you want here. This check will allow any machine, including 32-bit machines that allocate some kernel memory through a direct map, to opt out of the kmem map/arena/object limit. Finally, the Solaris KVA check is written to avoid the possibility of integer overflow. However, the FreeBSD version is not. For example, suppose that I setup an i386 machine with something approaching a 2GB/2GB user/kernel split, 3 * kmem_size() could overflow. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270975 - head/sys/dev/ofw
Author: jhb Date: Tue Sep 2 18:57:19 2014 New Revision: 270975 URL: http://svnweb.freebsd.org/changeset/base/270975 Log: Use callout(9) instead of timeout(9). Tested by:danfe Modified: head/sys/dev/ofw/ofw_console.c Modified: head/sys/dev/ofw/ofw_console.c == --- head/sys/dev/ofw/ofw_console.c Tue Sep 2 18:54:40 2014 (r270974) +++ head/sys/dev/ofw/ofw_console.c Tue Sep 2 18:57:19 2014 (r270975) @@ -60,8 +60,7 @@ static struct ttydevsw ofw_ttydevsw = { }; static int polltime; -static struct callout_handle ofw_timeouthandle -= CALLOUT_HANDLE_INITIALIZER(&ofw_timeouthandle); +static struct callout ofw_timer; #if defined(KDB) static int alt_break_state; @@ -101,6 +100,7 @@ cn_drvinit(void *unused) return; if (strlen(output) > 0) tty_makealias(tp, "%s", output); + callout_init_mtx(&ofw_timer, tty_getlock(tp), 0); } } @@ -116,7 +116,7 @@ ofwtty_open(struct tty *tp) if (polltime < 1) polltime = 1; - ofw_timeouthandle = timeout(ofw_timeout, tp, polltime); + callout_reset(&ofw_timer, polltime, ofw_timeout, tp); return (0); } @@ -125,8 +125,7 @@ static void ofwtty_close(struct tty *tp) { - /* XXX Should be replaced with callout_stop(9) */ - untimeout(ofw_timeout, tp, ofw_timeouthandle); + callout_stop(&ofw_timer); } static void @@ -151,13 +150,12 @@ ofw_timeout(void *v) tp = (struct tty *)v; - tty_lock(tp); + tty_lock_assert(tp, MA_OWNED); while ((c = ofw_cngetc(NULL)) != -1) ttydisc_rint(tp, c, 0); ttydisc_rint_done(tp); - tty_unlock(tp); - ofw_timeouthandle = timeout(ofw_timeout, tp, polltime); + callout_schedule(&ofw_timer, polltime); } static void ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270976 - head/share/mk
Author: emaste Date: Tue Sep 2 19:05:34 2014 New Revision: 270976 URL: http://svnweb.freebsd.org/changeset/base/270976 Log: Allow standalone debug for non-default ${PROG} targets This allows WITH_DEBUG_FILES to produce standalone debug for the ELF runtime linker. We previously disabled standalone debug files for bsd.prog.mk consumers that included a non-default ${PROG} target, but this is not required. Consumers that do not support standalone debug are still handled by disabling it for statically linked binaries, and for those that specify a non-default binary format. Sponsored by: DARPA, AFRL Modified: head/share/mk/bsd.prog.mk Modified: head/share/mk/bsd.prog.mk == --- head/share/mk/bsd.prog.mk Tue Sep 2 18:57:19 2014(r270975) +++ head/share/mk/bsd.prog.mk Tue Sep 2 19:05:34 2014(r270976) @@ -29,9 +29,7 @@ CTFFLAGS+= -g PROG= ${PROG_CXX} .endif -.if defined(PROG) && target(${PROG}) -MK_DEBUG_FILES=no -.elif !empty(LDFLAGS:M-Wl,*--oformat,*) || !empty(LDFLAGS:M-static) +.if !empty(LDFLAGS:M-Wl,*--oformat,*) || !empty(LDFLAGS:M-static) MK_DEBUG_FILES=no .endif ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
- Original Message - From: "Alan Cox" On 09/02/2014 12:34, Steven Hartland wrote: - Original Message - From: "Alan Cox" The patch actually makes two completely orthogonal changes at once, and one of those changes has no connection to the page daemon. I suspect that is why some people have said that their issues were not addressed by the page daemon fix. Prior to this patch, we were limiting the ARC size to 3/4 the kmem map/arena/object size on all architectures, including 64-bit, uma_small_alloc-enabled architectures where such a limit makes no sense. Consequently, some people were complaining, "Why is 1/4 of my memory going unused?" This is exactly the problem which lead me into investigating the issue. Is there any evidence that anything other than eliminating the KVA limit is needed on machines where the page daemon isn't broken? In "my" direct experience, I would have to say no, I can't speak for others. It should be noted that for i386, as requested by Peter, this limitation has been re-applied. Unlike Solaris, we run on a few 32-bit architectures, besides i386, that don't have a direct map or a full 4GB address space for the kernel. So, for FreeBSD, this needs to be more general than just i386. I would suggest using '#ifndef UMA_MD_SMALL_ALLOC' as being the closest thing that we have to what you want here. This check will allow any machine, including 32-bit machines that allocate some kernel memory through a direct map, to opt out of the kmem map/arena/object limit. I'm not and don't profess to be an expert in this domain as you know ;-) So I'm to defer to you guys, Peter would you agree with this? Finally, the Solaris KVA check is written to avoid the possibility of integer overflow. However, the FreeBSD version is not. For example, suppose that I setup an i386 machine with something approaching a 2GB/2GB user/kernel split, 3 * kmem_size() could overflow. The returns of said functions are uint64_t so I'm not sure where the overflow would be when working with 2GB values? We seem to be missing some of the following, which doesn't impact us directly but may affect understanding of the "current" illumos code as its not in the tree: https://github.com/illumos/illumos-gate/commit/94dd93aee32d1616436eb51fb7b58094b9a8d3e8 Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 09/02/2014 14:09, Steven Hartland wrote: > - Original Message - From: "Alan Cox" >> On 09/02/2014 12:34, Steven Hartland wrote: >>> - Original Message - From: "Alan Cox" The patch actually makes two completely orthogonal changes at once, and one of those changes has no connection to the page daemon. I suspect that is why some people have said that their issues were not addressed by the page daemon fix. Prior to this patch, we were limiting the ARC size to 3/4 the kmem map/arena/object size on all architectures, including 64-bit, uma_small_alloc-enabled architectures where such a limit makes no sense. Consequently, some people were complaining, "Why is 1/4 of my memory going unused?" >>> >>> This is exactly the problem which lead me into investigating the issue. >>> >> >> Is there any evidence that anything other than eliminating the KVA limit >> is needed on machines where the page daemon isn't broken? > > In "my" direct experience, I would have to say no, I can't speak for > others. > >>> It should be noted that for i386, as requested by Peter, this >>> limitation >>> has been re-applied. >>> >> >> Unlike Solaris, we run on a few 32-bit architectures, besides i386, that >> don't have a direct map or a full 4GB address space for the kernel. So, >> for FreeBSD, this needs to be more general than just i386. I would >> suggest using '#ifndef UMA_MD_SMALL_ALLOC' as being the closest thing >> that we have to what you want here. This check will allow any machine, >> including 32-bit machines that allocate some kernel memory through a >> direct map, to opt out of the kmem map/arena/object limit. > > I'm not and don't profess to be an expert in this domain as you > know ;-) So I'm to defer to you guys, Peter would you agree with > this? > >> Finally, the Solaris KVA check is written to avoid the possibility of >> integer overflow. However, the FreeBSD version is not. For example, >> suppose that I setup an i386 machine with something approaching a >> 2GB/2GB user/kernel split, 3 * kmem_size() could overflow. > > The returns of said functions are uint64_t so I'm not sure where > the overflow would be when working with 2GB values? > Ah, I didn't see the uint64_t. I only looked at the calculation and assumed vm_offset_t was being used. So, yes, you are safe from overflow. > We seem to be missing some of the following, which doesn't impact > us directly but may affect understanding of the "current" illumos > code as its not in the tree: > https://github.com/illumos/illumos-gate/commit/94dd93aee32d1616436eb51fb7b58094b9a8d3e8 > > >Regards >Steve > > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270989 - head/usr.sbin/bsdconfig/share
Author: dteske Date: Tue Sep 2 22:59:40 2014 New Revision: 270989 URL: http://svnweb.freebsd.org/changeset/base/270989 Log: Fix regression introduced by SVN r270954. Correct way to reset getopts is to set OPTIND to 1, not unset it (which causes an error). Thanks to:jilles Modified: head/usr.sbin/bsdconfig/share/dialog.subr Modified: head/usr.sbin/bsdconfig/share/dialog.subr == --- head/usr.sbin/bsdconfig/share/dialog.subr Tue Sep 2 22:01:14 2014 (r270988) +++ head/usr.sbin/bsdconfig/share/dialog.subr Tue Sep 2 22:59:40 2014 (r270989) @@ -2116,7 +2116,7 @@ f_dialog_init() f_dprintf "f_dialog_init: ARGV=[%s] GETOPTS_STDARGS=[%s]" \ "$ARGV" "$GETOPTS_STDARGS" SECURE=`set -- $ARGV - unset OPTIND + OPTIND=1 while getopts \ "$GETOPTS_STDARGS$GETOPTS_EXTRA$GETOPTS_ALLFLAGS" \ flag > /dev/null; do @@ -2126,7 +2126,7 @@ f_dialog_init() done ` # END-BACKTICK USE_XDIALOG=`set -- $ARGV - unset OPTIND + OPTIND=1 while getopts \ "$GETOPTS_STDARGS$GETOPTS_EXTRA$GETOPTS_ALLFLAGS" \ flag > /dev/null; do ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270990 - in head: share/mk sys/sys
Author: markj Date: Tue Sep 2 23:43:06 2014 New Revision: 270990 URL: http://svnweb.freebsd.org/changeset/base/270990 Log: Define _DTRACE_VERSION in sdt.h rather than setting it manually. This is similar to what illumos does, and makes it easier to enable USDT probes in third-party software that doesn't make use of the system makefiles. Modified: head/share/mk/bsd.dep.mk head/sys/sys/sdt.h Modified: head/share/mk/bsd.dep.mk == --- head/share/mk/bsd.dep.mkTue Sep 2 22:59:40 2014(r270989) +++ head/share/mk/bsd.dep.mkTue Sep 2 23:43:06 2014(r270990) @@ -125,7 +125,7 @@ ${_YC:R}.o: ${_YC} .if ${SRCS:M*.d} LDFLAGS+= -lelf LDADD+=${LIBELF} -CFLAGS+= -D_DTRACE_VERSION=1 -I${.OBJDIR} +CFLAGS+= -I${.OBJDIR} .endif .for _DSRC in ${SRCS:M*.d:N*/*} .for _D in ${_DSRC:R} Modified: head/sys/sys/sdt.h == --- head/sys/sys/sdt.h Tue Sep 2 22:59:40 2014(r270989) +++ head/sys/sys/sdt.h Tue Sep 2 23:43:06 2014(r270990) @@ -33,6 +33,8 @@ #ifndef _KERNEL +#define_DTRACE_VERSION 1 + #defineDTRACE_PROBE(prov, name) { \ extern void __dtrace_##prov##___##name(void); \ __dtrace_##prov##___##name(); \ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270991 - head/sys/conf
Author: imp Date: Wed Sep 3 00:32:19 2014 New Revision: 270991 URL: http://svnweb.freebsd.org/changeset/base/270991 Log: Invoke make_dtb with MACHINE defined for enhanced cross building friendliness. This should restore old-fashioned kernel building in a cross environment, though this has only had limited testing. Sponsored by: Netflix Modified: head/sys/conf/files Modified: head/sys/conf/files == --- head/sys/conf/files Tue Sep 2 23:43:06 2014(r270990) +++ head/sys/conf/files Wed Sep 3 00:32:19 2014(r270991) @@ -14,11 +14,11 @@ acpi_quirks.h optional acpi \ # from the specified source (DTS) file: .dts -> .dtb # fdt_dtb_file optional fdt fdt_dtb_static \ - compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} ${.CURDIR}" \ + compile-with "sh MACHINE=${MACHINE} $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} ${.CURDIR}" \ no-obj no-implicit-rule before-depend \ clean "${FDT_DTS_FILE:R}.dtb" fdt_static_dtb.h optional fdt fdt_dtb_static \ - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ${.CURDIR}" \ + compile-with "sh MACHINE=${MACHINE} $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ${.CURDIR}" \ dependency "fdt_dtb_file" \ no-obj no-implicit-rule before-depend \ clean "fdt_static_dtb.h" ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270992 - head/sys/dev/usb/net
Author: hselasky Date: Wed Sep 3 05:14:50 2014 New Revision: 270992 URL: http://svnweb.freebsd.org/changeset/base/270992 Log: Fix logical error. MFC after:3 days Modified: head/sys/dev/usb/net/if_aue.c Modified: head/sys/dev/usb/net/if_aue.c == --- head/sys/dev/usb/net/if_aue.c Wed Sep 3 00:32:19 2014 (r270991) +++ head/sys/dev/usb/net/if_aue.c Wed Sep 3 05:14:50 2014 (r270992) @@ -749,7 +749,7 @@ aue_intr_callback(struct usb_xfer *xfer, if (pkt.aue_txstat0) ifp->if_oerrors++; - if (pkt.aue_txstat0 & (AUE_TXSTAT0_LATECOLL & + if (pkt.aue_txstat0 & (AUE_TXSTAT0_LATECOLL | AUE_TXSTAT0_EXCESSCOLL)) ifp->if_collisions++; } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270964 - head/sys/sys
On Tue, Sep 2, 2014 at 1:16 PM, Ed Schouten wrote: > Author: ed > Date: Tue Sep 2 11:16:44 2014 > New Revision: 270964 > URL: http://svnweb.freebsd.org/changeset/base/270964 > > Log: > Clean up slightly. > > - Remove c++0x hack from that was needed when Clang did > not fully implement C++11. We can now safely test against C++11 to > check whether thread_local is available, like we do for all other > C++11 keywords. > > - Don't use __clang__ to test for thread safety annotation presence. It > turns out we have a proper attribute for this. > > Modified: > head/sys/sys/cdefs.h > > Modified: head/sys/sys/cdefs.h > == > --- head/sys/sys/cdefs.hTue Sep 2 10:35:04 2014(r270963) > +++ head/sys/sys/cdefs.hTue Sep 2 11:16:44 2014(r270964) > @@ -298,8 +298,7 @@ > #endif > > #if !__has_extension(c_thread_local) > -/* XXX: Change this to test against C++11 when clang in base supports it. */ > -#if /* (defined(__cplusplus) && __cplusplus >= 201103L) || */ \ > +#if (defined(__cplusplus) && __cplusplus >= 201103L) || \ > __has_extension(cxx_thread_local) > #define_Thread_local thread_local > #else Hi, This change may break the lang/gcc port on head: http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p367138_s270990/logs/errors/gcc-4.7.4.log Cheers, Antoine ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270993 - head/sys/kern
Author: mjg Date: Wed Sep 3 06:25:34 2014 New Revision: 270993 URL: http://svnweb.freebsd.org/changeset/base/270993 Log: Fix up proc_realparent to always return correct process. Prior to the change it would always return initproc for non-traced processes. This fixes ps apparently always returning 1 as ppid. Pointy hat: mjg Reported by: many MFC after:1 week Modified: head/sys/kern/kern_exit.c Modified: head/sys/kern/kern_exit.c == --- head/sys/kern/kern_exit.c Wed Sep 3 05:14:50 2014(r270992) +++ head/sys/kern/kern_exit.c Wed Sep 3 06:25:34 2014(r270993) @@ -104,8 +104,12 @@ proc_realparent(struct proc *child) sx_assert(&proctree_lock, SX_LOCKED); if ((child->p_treeflag & P_TREE_ORPHANED) == 0) { - return (child->p_pptr->p_pid == child->p_oppid ? - child->p_pptr : initproc); + if (child->p_oppid == 0 || + child->p_pptr->p_pid == child->p_oppid) + parent = child->p_pptr; + else + parent = initproc; + return (parent); } for (p = child; (p->p_treeflag & P_TREE_FIRST_ORPHAN) == 0;) { /* Cannot use LIST_PREV(), since the list head is not known. */ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270994 - head/sys/sys
Author: ed Date: Wed Sep 3 06:34:16 2014 New Revision: 270994 URL: http://svnweb.freebsd.org/changeset/base/270994 Log: Partially revert r270964. Don't test for C++11 to define _Thread_local. In addition to Clang 3.3, it turns out that GCC 4.7 in Ports also does not support the _Thread_local keyword. Let's document this in a bit more detail. Reported by: antoine@ Modified: head/sys/sys/cdefs.h Modified: head/sys/sys/cdefs.h == --- head/sys/sys/cdefs.hWed Sep 3 06:25:34 2014(r270993) +++ head/sys/sys/cdefs.hWed Sep 3 06:34:16 2014(r270994) @@ -298,7 +298,12 @@ #endif #if !__has_extension(c_thread_local) -#if (defined(__cplusplus) && __cplusplus >= 201103L) || \ +/* + * XXX: Some compilers (Clang 3.3, GCC 4.7) falsely announce C++11 mode + * without actually supporting the thread_local keyword. Don't check for + * the presence of C++11 when defining _Thread_local. + */ +#if /* (defined(__cplusplus) && __cplusplus >= 201103L) || */ \ __has_extension(cxx_thread_local) #define_Thread_local thread_local #else ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270964 - head/sys/sys
On 3 September 2014 07:44, Antoine Brodin wrote: > This change may break the lang/gcc port on head: > http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p367138_s270990/logs/errors/gcc-4.7.4.log Good catch! Fixed in r270994. -- Ed Schouten ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"