Re: svn commit: r269814 - head/sys/dev/xen/blkfront

2014-09-02 Thread Roger Pau Monné
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

2014-09-02 Thread Ed Schouten
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

2014-09-02 Thread John Baldwin
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

2014-09-02 Thread Konstantin Belousov
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

2014-09-02 Thread John Baldwin
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

2014-09-02 Thread 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 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

2014-09-02 Thread Warner Losh
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

2014-09-02 Thread John-Mark Gurney
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

2014-09-02 Thread 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?"


___
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

2014-09-02 Thread John-Mark Gurney
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

2014-09-02 Thread Steven Hartland
- 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

2014-09-02 Thread Steven Hartland
- 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

2014-09-02 Thread Colin Percival
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

2014-09-02 Thread Rui Paulo
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

2014-09-02 Thread Kashyap D Desai
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

2014-09-02 Thread Alan Cox
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

2014-09-02 Thread John Baldwin
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

2014-09-02 Thread Ed Maste
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

2014-09-02 Thread Steven Hartland
- 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

2014-09-02 Thread Alan Cox
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

2014-09-02 Thread Devin Teske
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

2014-09-02 Thread Mark Johnston
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

2014-09-02 Thread Warner Losh
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

2014-09-02 Thread Hans Petter Selasky
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

2014-09-02 Thread Antoine Brodin
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

2014-09-02 Thread Mateusz Guzik
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

2014-09-02 Thread Ed Schouten
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

2014-09-02 Thread Ed Schouten
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"