Re: enable resume from text console on X301 Was:Re: enable/fix vt switching on sandybridge machines

[Owain Ainsworth]

On Thu, Mar 08, 2012 at 10:45:11AM -0800, Dave Del Debbio wrote:
> On Sun, Mar 4 Mar 2012 12:27:56 -0800, Mike Larkin wrote:
> > > This really has nothing to do with ACPI. It could be due to missing a 
> > > repost in resume, but ACPI is really not involved in that part of the
> > > sequence.
> > > 
> > > There is a block of code in sys/dev/pci/vga_pci.c that can be used to try 
> > > one
> > > of two different resume video repost techniques. Did you try putting your
> > > card's ID in there and see what happens? (For both types of repost?)
> > 
> 
> The following patch makes resume work for me on a Thinkpad X301 from a text
> console.  I can also suspend from X, but I cannot resume from X, yet:

I find this very suprising since the GM45 is certainly not sandybridge,
it is 2 full chipset generations behind at least..

Can I see a dmesg and pcidump -v from that machine?

> 
> --- vga_pci.c.old Thu Mar  8 10:24:22 2012
> +++ vga_pci.c Thu Mar  8 09:56:25 2012
> @@ -169,6 +169,11 @@
>* vga_pci (i.e. the x86emulator) or with a locore call to the video
>* bios.
>*/
> + {   /* All machines with Intel GM45 (until more evidence) */
> + {   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82GM45_IGD_1,
> + 0x, 0x },
> + {   0x, 0x, 0x, 0x }, 1, 0
> + },
>   {   /* All machines with Intel US15W (until more evidence) */
>   {   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_US15W_IGD,
>   0x, 0x },
> 

-- 
A person is just about as big as the things that make him angry.

Re: enable/fix vt switching on sandybridge machines

[Owain Ainsworth]

On Sun, Mar 04, 2012 at 10:21:55PM +0100, Mark Kettenis wrote:
> > Date: Sun, 4 Mar 2012 12:27:56 -0800
> > From: Mike Larkin 
> > Cc: joshua stein , tech@openbsd.org
> > Reply-To: mlar...@azathoth.net
> > List-Owner: 
> > X-Loop: tech@openbsd.org
> > Sender: owner-t...@openbsd.org
> > X-XS4ALL-DNSBL-Checked: mxdrop214.xs4all.nl checked 192.43.244.163 against 
> > DNS blacklists
> > X-CNFS-Analysis: v=2.0 cv=e8exv9V/ c=1 sm=0 a=A3duGc4wJ8K8BtNzzvyz4A==:17
> > a=wom5GMh1gUkA:10 a=JV4z2ink_MgA:10 a=NDt0MqMu1W8A:10
> > a=WLtJ5LygAb0A:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10
> > a=xqWC_Br6kY4A:10 a=rTCu5ZAxDHZ_rHRvVYYA:9 a=CjuIK1q_8ugA:10
> > a=A3duGc4wJ8K8BtNzzvyz4A==:117
> > X-Virus-Scanned: by XS4ALL Virus Scanner
> > X-XS4ALL-Spam-Score: 0.0 () none
> > X-XS4ALL-Spam: NO
> > Envelope-To: mark.kette...@xs4all.nl
> > 
> > On Sat, Mar 03, 2012 at 09:43:39PM +0100, Matthieu Herrb wrote:
> > > On Sat, Mar 03, 2012 at 12:50:32PM -0600, joshua stein wrote:
> > > > > And it only works if you don't suspend the machine. After a
> > > > > suspend/resume cycle, X still comes back, but text mode VTs stay black
> > > > > again. 
> > > > 
> > > > does the console resume properly even when you boot up and don't
> > > > start x?  it doesn't on my laptop, so this may be an acpi-related
> > > > problem.
> > > > 
> > > 
> > > No, even in text mode only the console doesn't come back from
> > > suspend. So yes it's an acpi issue.  
> > > -- 
> > > Matthieu Herrb
> > >
> > 
> > This really has nothing to do with ACPI. It could be due to missing a 
> > repost in resume, but ACPI is really not involved in that part of the
> > sequence.
> > 
> > There is a block of code in sys/dev/pci/vga_pci.c that can be used to try 
> > one
> > of two different resume video repost techniques. Did you try putting your
> > card's ID in there and see what happens? (For both types of repost?)
> 
> I'm pretty sure I tried both methods when I was hackig on the initial
> sandybridge support.  They didn't help.  We need to restore the
> graphics state ourselves in the kernel driver.

I did as well. I'm also sure I tried to mess with the int10 hack and had
no luck (because I didn't also have the restore code). (In short, I
concur).

-0-
-- 
Absentee, n.:
A person with an income who has had the forethought to remove
himself from the sphere of exaction.
-- Ambrose Bierce, "The Devil's Dictionary"

Re: (mostly) fix rotation in the intel X driver.

[Owain Ainsworth]

On Wed, Dec 21, 2011 at 09:27:03PM +, Owain Ainsworth wrote:
> There seems to be a damage issue with roatated screens and at least
> rectangle composition still, but this makes rotation possible at all.
> (this is a bug only we have because we still have the UMS code).
> 
> it's a git diff, but should apply clean from
> /usr/xenocara/driver/xf86-video-intel
> 
> Cheers,
> 
> -0-

I Have had no comments on this whatsoever.

-0-

> 
> commit b1dfe9af0ea35f1a1e7cd21aaccc034f280b474f
> Author: Owain G. Ainsworth 
> Date:   Thu Dec 8 19:08:44 2011 +
> 
> fix rotation.
> 
> We can now allocate rotated framebuffers with tiling.
> 
> 1) i830_display_tiled needs to check tiling on rotated buffers too.
> 2) PipeSetBase needs to not only set offset to 0 for rotated shadow 
> buffers, but
> x/y in DSPTILEOFF too.
> 
> diff --git src/i830_display.c src/i830_display.c
> index f833577..84bfb52 100644
> --- src/i830_display.c
> +++ src/i830_display.c
> @@ -941,30 +941,35 @@ i830PipeSetBase(xf86CrtcPtr crtc, int x, int y)
>  I830CrtcPrivatePtr   intel_crtc = crtc->driver_private;
>  int plane = intel_crtc->plane;
>  unsigned long Start, Offset, Stride;
> +drm_intel_bo *bo;
>  int dspbase = (plane == 0 ? DSPABASE : DSPBBASE);
>  int dspsurf = (plane == 0 ? DSPASURF : DSPBSURF);
>  int dsptileoff = (plane == 0 ? DSPATILEOFF : DSPBTILEOFF);
>  int dspstride = (plane == 0) ? DSPASTRIDE : DSPBSTRIDE;
>  
> -Offset = y * intel->front_pitch + x * intel->cpp;
> +crtc->x = x;
> +crtc->y = y;
> +
>  Stride = intel->front_pitch;
> -if (intel->front_buffer == NULL) {
> - /* During startup we may be called as part of monitor detection while
> -  * there is no memory allocation done, so just supply a dummy base
> -  * address.
> -  */
> - Start = 0;
> -} else if (crtc->rotatedData != NULL) {
> - /* offset is done by shadow painting code, not here */
> - Start = (char *)crtc->rotatedData - (char *)intel->FbBase;
> - Offset = 0;
> +bo = intel->front_buffer;
> +Offset = y * Stride + x * intel->cpp;
> +if (intel_crtc->rotate_bo != NULL) {
>   Stride = intel_crtc->rotate_pitch;
> -} else {
> - Start = intel->front_buffer->offset;
> + bo = intel_crtc->rotate_bo;
> + Offset = 0;
> + x = y = 0;
>  }
>  
> -crtc->x = x;
> -crtc->y = y;
> +/*
> + * During startup we may be called as part of monitor detection while
> + * there is no memory allocation done, so just supply a dummy base
> + * address.
> + */
> +if (bo == NULL) {
> + Start = 0;
> +} else {
> + Start = bo->offset;
> +}
>  
>  OUTREG(dspstride, Stride);
>  if (IS_I965G(intel)) {
> @@ -1057,16 +1062,17 @@ static Bool
>  i830_display_tiled(xf86CrtcPtr crtc)
>  {
>  ScrnInfoPtr scrn = crtc->scrn;
> +I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
>  intel_screen_private *intel = intel_get_screen_private(scrn);
> +drm_intel_bo *bo = intel->front_buffer;
>  
> -/* Rotated data is currently linear, allocated either via XAA or EXA */
> -if (crtc->rotatedData)
> - return FALSE;
> +if (intel_crtc->rotate_bo != NULL)
> + bo = intel_crtc->rotate_bo;
>  
> -if (intel->front_buffer) {
> +if (bo != NULL) {
>  uint32_t tiling_mode, swizzle;
> - if (drm_intel_bo_get_tiling(intel->front_buffer,
> - &tiling_mode, &swizzle) == 0 && tiling_mode != I915_TILING_NONE)
> + if (drm_intel_bo_get_tiling(bo, &tiling_mode, &swizzle) == 0 &&
> + tiling_mode != I915_TILING_NONE)
>   return TRUE;
>  }
>  
> @@ -2589,7 +2595,7 @@ i830_crtc_shadow_allocate (xf86CrtcPtr crtc, int width, 
> int height)
>  }
>  
>  intel_crtc->rotate_pitch = rotate_pitch;
> -return intel->FbBase + intel_crtc->rotate_bo->offset;
> +return intel_crtc->rotate_bo;
>  }
>  
>  /**
> @@ -2603,12 +2609,19 @@ i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, 
> int width, int height)
>  I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
>  PixmapPtr rotate_pixmap;
>  
> -if (!data)
> +if (!data) {
>   data = i830_crtc_shadow_allocate (crtc, width, height);
> + if (!data) {
> + xf86DrvMsg(scrn->scrnIndex, X_ERROR,
> + "Couldn't allocate shadow pixmap for rotated CRTC\n");
> + return NULL;
> + }
> +}
>

(mostly) fix rotation in the intel X driver.

[Owain Ainsworth]

There seems to be a damage issue with roatated screens and at least
rectangle composition still, but this makes rotation possible at all.
(this is a bug only we have because we still have the UMS code).

it's a git diff, but should apply clean from
/usr/xenocara/driver/xf86-video-intel

Cheers,

-0-

commit b1dfe9af0ea35f1a1e7cd21aaccc034f280b474f
Author: Owain G. Ainsworth 
Date:   Thu Dec 8 19:08:44 2011 +

fix rotation.

We can now allocate rotated framebuffers with tiling.

1) i830_display_tiled needs to check tiling on rotated buffers too.
2) PipeSetBase needs to not only set offset to 0 for rotated shadow 
buffers, but
x/y in DSPTILEOFF too.

diff --git src/i830_display.c src/i830_display.c
index f833577..84bfb52 100644
--- src/i830_display.c
+++ src/i830_display.c
@@ -941,30 +941,35 @@ i830PipeSetBase(xf86CrtcPtr crtc, int x, int y)
 I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
 int plane = intel_crtc->plane;
 unsigned long Start, Offset, Stride;
+drm_intel_bo *bo;
 int dspbase = (plane == 0 ? DSPABASE : DSPBBASE);
 int dspsurf = (plane == 0 ? DSPASURF : DSPBSURF);
 int dsptileoff = (plane == 0 ? DSPATILEOFF : DSPBTILEOFF);
 int dspstride = (plane == 0) ? DSPASTRIDE : DSPBSTRIDE;
 
-Offset = y * intel->front_pitch + x * intel->cpp;
+crtc->x = x;
+crtc->y = y;
+
 Stride = intel->front_pitch;
-if (intel->front_buffer == NULL) {
-   /* During startup we may be called as part of monitor detection while
-* there is no memory allocation done, so just supply a dummy base
-* address.
-*/
-   Start = 0;
-} else if (crtc->rotatedData != NULL) {
-   /* offset is done by shadow painting code, not here */
-   Start = (char *)crtc->rotatedData - (char *)intel->FbBase;
-   Offset = 0;
+bo = intel->front_buffer;
+Offset = y * Stride + x * intel->cpp;
+if (intel_crtc->rotate_bo != NULL) {
Stride = intel_crtc->rotate_pitch;
-} else {
-   Start = intel->front_buffer->offset;
+   bo = intel_crtc->rotate_bo;
+   Offset = 0;
+   x = y = 0;
 }
 
-crtc->x = x;
-crtc->y = y;
+/*
+ * During startup we may be called as part of monitor detection while
+ * there is no memory allocation done, so just supply a dummy base
+ * address.
+ */
+if (bo == NULL) {
+   Start = 0;
+} else {
+   Start = bo->offset;
+}
 
 OUTREG(dspstride, Stride);
 if (IS_I965G(intel)) {
@@ -1057,16 +1062,17 @@ static Bool
 i830_display_tiled(xf86CrtcPtr crtc)
 {
 ScrnInfoPtr scrn = crtc->scrn;
+I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
 intel_screen_private *intel = intel_get_screen_private(scrn);
+drm_intel_bo *bo = intel->front_buffer;
 
-/* Rotated data is currently linear, allocated either via XAA or EXA */
-if (crtc->rotatedData)
-   return FALSE;
+if (intel_crtc->rotate_bo != NULL)
+   bo = intel_crtc->rotate_bo;
 
-if (intel->front_buffer) {
+if (bo != NULL) {
 uint32_t tiling_mode, swizzle;
-   if (drm_intel_bo_get_tiling(intel->front_buffer,
-   &tiling_mode, &swizzle) == 0 && tiling_mode != I915_TILING_NONE)
+   if (drm_intel_bo_get_tiling(bo, &tiling_mode, &swizzle) == 0 &&
+   tiling_mode != I915_TILING_NONE)
return TRUE;
 }
 
@@ -2589,7 +2595,7 @@ i830_crtc_shadow_allocate (xf86CrtcPtr crtc, int width, 
int height)
 }
 
 intel_crtc->rotate_pitch = rotate_pitch;
-return intel->FbBase + intel_crtc->rotate_bo->offset;
+return intel_crtc->rotate_bo;
 }
 
 /**
@@ -2603,12 +2609,19 @@ i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, 
int width, int height)
 I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
 PixmapPtr rotate_pixmap;
 
-if (!data)
+if (!data) {
data = i830_crtc_shadow_allocate (crtc, width, height);
+   if (!data) {
+   xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+   "Couldn't allocate shadow pixmap for rotated CRTC\n");
+   return NULL;
+   }
+}
 
 if (intel_crtc->rotate_bo == NULL) {
xf86DrvMsg(scrn->scrnIndex, X_ERROR,
   "Couldn't allocate shadow pixmap for rotated CRTC\n");
+   return NULL;
 }
 
 rotate_pixmap = GetScratchPixmapHeader(scrn->pScreen,
@@ -2616,11 +2629,12 @@ i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, 
int width, int height)
   scrn->depth,
   scrn->bitsPerPixel,
   intel_crtc->rotate_pitch,
-  data);
+  NULL);
 
 if (rotate_pixmap == NULL) {
xf86DrvMsg(scrn->scrnIndex, X_ERROR,
   "Couldn't allocate shadow pixmap for rotated CRTC\n");
+return NULL;
 }
 intel_set_pixmap_bo(rotate_pixmap, int

Re: libedit wchar allocation issue

[Owain Ainsworth]

On Tue, Nov 15, 2011 at 11:09:08PM +, Nicholas Marriott wrote:
> Hi
> 
> libedit miscalculates the amount of space needed for constructing it's
> wchar_t version of argv, causing it to overrun the buffer.
> 
> I don't see how the output of mbstowcs can be longer than
> (sum(strlen(argv)) * sizeof (wchar_t)) so this fix should work:
> 
> ok?

This seems to fix an intermittent problem I have been having with
libedit crashing during various initialisation dances.

I approve.
-- 
The wages of sin are high but you get your money's worth.

Re: X Intel driver update. [TESTING NEEDED]

[Owain Ainsworth]

On Mon, Sep 12, 2011 at 12:31:46AM +0100, Owain Ainsworth wrote:
> I've been sitting on various stages of this update for far too long,
> about time i sent it out.
> 
> This updates the rendering code in the in-tree intel driver to much more
> recent versions of the upstream intel driver, while retaining user
> modesetting code (backporting work by me as well as a few openbsd
> specific changes). This fixes many bugs and provides a large speed
> improvement (especially text rendering) on 965 and above chipsets.
> 
> A few bugfixes from kettenis@ are also present fixing some nagging
> issues.
> 
> This is a prerequisite for support for sandybridge chipsets so it would
> be good to get it into the tree soon. Testing would be much appreciated.
> Instructions follow:
> 
> Download the tarball at http://xenocara.org/src/intel_update.tgz
> 
> move /usr/xenocara/driver/xf86-video-intel out of the way and untar the
> tgz from xenocara/drivers
> 
> cd xf86-video-intel
> make -f Makefile.bsd-wrapper obj
> make -f Makefile.bsd-wrapper build
> 
> Please let me know if you find any issues, otherwise reports of which
> hardware this was testing on to me privately please.
> 
> Cheers,
> 
> -0-
> -- 
> I was playing poker the other night ... with Tarot cards. I got a full
> house and four people died.
>   -- Steven Wright

The driver on the web has been updated to not have the sandybridge
pciids set to match.

-0-
-- 
Q:  How many Martians does it take to screw in a lightbulb?
A:  One and a half.

Re: X Intel driver update. [TESTING NEEDED]

[Owain Ainsworth]

On Mon, Sep 12, 2011 at 05:08:46PM +0200, Mark Kettenis wrote:
> > Date: Mon, 12 Sep 2011 17:51:14 +0300
> > From: Paul Irofti 
> >
> > This breaks X on my sandybridge workstation. (This plus the kernel
patch
> > you sent before). I mailed you the dmesg in private, but I'll attach
it
> > here as well for whoever else might be interested. (Watchout, big
dmesg
> > cache.)
>
> It doesn't really break Sandybridge, because the current driver
> doesn't work on sandybridge at all.  I guess Owain left the
> snadbybridge PCI Ids in the driver, to facilitate development.

Mark is 100% correct here. 

>
> The Sandybridge support isn't quite there yet.  But getting this stuff
> in will help us finish support for it.  So it is not neccessary to
> test this on Sandybridge hardware (Intel Core i3/5/7-2xxx CPUs), but
> please do test on anything that's older than that (including the first
> generation Intel Core i3/5/7)!

In more detail, this code has the full sandybridge rendering code from  
upstream as of a couple of months ago (before another acceleration
architecture experement started), as well as the renderer improvements  
for other chipsets. What it currently lacks is the modesetting code for
sandybridge  which is not quite done but getting closer.

>
> Cheers,
>
> Mark
>

Ditto,
-0-
--
A Law of Computer Programming:
Make it possible for programmers to write in English and you
will find the programmers cannot write in English.

X Intel driver update. [TESTING NEEDED]

[Owain Ainsworth]

I've been sitting on various stages of this update for far too long,
about time i sent it out.

This updates the rendering code in the in-tree intel driver to much more
recent versions of the upstream intel driver, while retaining user
modesetting code (backporting work by me as well as a few openbsd
specific changes). This fixes many bugs and provides a large speed
improvement (especially text rendering) on 965 and above chipsets.

A few bugfixes from kettenis@ are also present fixing some nagging
issues.

This is a prerequisite for support for sandybridge chipsets so it would
be good to get it into the tree soon. Testing would be much appreciated.
Instructions follow:

Download the tarball at http://xenocara.org/src/intel_update.tgz

move /usr/xenocara/driver/xf86-video-intel out of the way and untar the
tgz from xenocara/drivers

cd xf86-video-intel
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper build

Please let me know if you find any issues, otherwise reports of which
hardware this was testing on to me privately please.

Cheers,

-0-
-- 
I was playing poker the other night ... with Tarot cards. I got a full
house and four people died.
-- Steven Wright

Re: Sandybridge graphics support: part 1 basic kernel support.

[Owain Ainsworth]

On Thu, Sep 08, 2011 at 05:25:46AM +0100, Owain Ainsworth wrote:
> A few months ago jcs@ got a sandybridge laptop, he did some work to get
> it almost working. I continued this a few months ago in edmonton at
> c2k11. Since then kettenis@ who has hardware has made yet more progress.
> 
> Now the plan is to get this into the tree, but first some precursors.
> 
> This kernel patch is just the very basic bits needed to get sandybridge
> working, the extra ringsbuffers (BSD, blit) are not in this patch (I
> have half to 2/3 of a diff for that). Nor are the requisit xserver bits.
> For now some extra testing is required to make sure these patches don't
> break any existing setups so that they can go in and work can progress.
> 
> So please mail me and kettenis@ privately if this patch regresses your
> inteldrm(4) using hardware. Reports that this does nothing other than
> attach for sandybridge right now are not necessary. We know.
> 
> Cheers,
> 
> -0-

Bah, now without a keyword bit that won't apply.


Index: dev/pci/agp_i810.c
===
RCS file: /cvs/src/sys/dev/pci/agp_i810.c,v
retrieving revision 1.69
diff -u -p -r1.69 agp_i810.c
--- dev/pci/agp_i810.c  6 Sep 2010 15:00:50 -   1.69
+++ dev/pci/agp_i810.c  8 Sep 2011 04:59:19 -
@@ -71,6 +71,7 @@ enum {
CHIP_G4X= 7,/* G4X */
CHIP_PINEVIEW   = 8,/* Pineview/Pineview M */
CHIP_IRONLAKE   = 9,/* Clarkdale/Arrandale */
+   CHIP_SANDYBRIDGE=10,/* Sandybridge */
 };
 
 struct agp_i810_softc {
@@ -183,13 +184,23 @@ agp_i810_get_chiptype(struct pci_attach_
case PCI_PRODUCT_INTEL_82G45_IGD_1:
case PCI_PRODUCT_INTEL_82G41_IGD_1:
return (CHIP_G4X);
+   break;
case PCI_PRODUCT_INTEL_PINEVIEW_IGC_1:
case PCI_PRODUCT_INTEL_PINEVIEW_M_IGC_1:
return (CHIP_PINEVIEW);
+   break;
case PCI_PRODUCT_INTEL_CLARKDALE_IGD:
case PCI_PRODUCT_INTEL_ARRANDALE_IGD:
return (CHIP_IRONLAKE);
break;
+   case PCI_PRODUCT_INTEL_CORE2G_GT1:
+   case PCI_PRODUCT_INTEL_CORE2G_M_GT1:
+   case PCI_PRODUCT_INTEL_CORE2G_GT2:
+   case PCI_PRODUCT_INTEL_CORE2G_M_GT2:
+   case PCI_PRODUCT_INTEL_CORE2G_GT2_PLUS:
+   case PCI_PRODUCT_INTEL_CORE2G_M_GT2_PLUS:
+   return (CHIP_SANDYBRIDGE);
+   break;
}
return (CHIP_NONE);
 }
@@ -246,6 +257,7 @@ agp_i810_attach(struct device *parent, s
case CHIP_I965:
case CHIP_G4X:
case CHIP_IRONLAKE:
+   case CHIP_SANDYBRIDGE:
gmaddr = AGP_I965_GMADR;
mmaddr = AGP_I965_MMADR;
memtype = PCI_MAPREG_TYPE_MEM | PCI_MAPREG_MEM_TYPE_64BIT;
@@ -477,6 +489,85 @@ agp_i810_attach(struct device *parent, s
gatt->ag_physical = READ4(AGP_I810_PGTBL_CTL) & ~1;
break;
 
+   case CHIP_SANDYBRIDGE:
+
+   /* Stolen memory is set up at the beginning of the aperture by
+* the BIOS, consisting of the GATT followed by 4kb for the
+* BIOS display.
+*/
+
+   gcc1 = (u_int16_t)pci_conf_read(bpa.pa_pc, bpa.pa_tag,
+   AGP_INTEL_SNB_GMCH_CTRL);
+
+   stolen = 4;
+
+   switch (gcc1 & AGP_INTEL_SNB_GMCH_GMS_STOLEN_MASK) {
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_32M:
+   isc->stolen = (32768 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_64M:
+   isc->stolen = (65536 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_96M:
+   isc->stolen = (98304 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_128M:
+   isc->stolen = (131072 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_160M:
+   isc->stolen = (163840 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_192M:
+   isc->stolen = (196608 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_224M:
+   isc->stolen = (229376 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_256M:
+   isc->stolen = (262144 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_288M:
+   isc->stolen = (294912 - stolen) * 1024 / 4096;
+   break;
+   case 

Sandybridge graphics support: part 1 basic kernel support.

[Owain Ainsworth]

A few months ago jcs@ got a sandybridge laptop, he did some work to get
it almost working. I continued this a few months ago in edmonton at
c2k11. Since then kettenis@ who has hardware has made yet more progress.

Now the plan is to get this into the tree, but first some precursors.

This kernel patch is just the very basic bits needed to get sandybridge
working, the extra ringsbuffers (BSD, blit) are not in this patch (I
have half to 2/3 of a diff for that). Nor are the requisit xserver bits.
For now some extra testing is required to make sure these patches don't
break any existing setups so that they can go in and work can progress.

So please mail me and kettenis@ privately if this patch regresses your
inteldrm(4) using hardware. Reports that this does nothing other than
attach for sandybridge right now are not necessary. We know.

Cheers,

-0-
-- 
It took me fifteen years to discover that I had no talent for writing,
but I couldn't give up because by that time I was too famous.
-- Robert Benchley


diff --git dev/pci/agp_i810.c dev/pci/agp_i810.c
index 41b9189..b62610e 100644
--- dev/pci/agp_i810.c
+++ dev/pci/agp_i810.c
@@ -71,6 +71,7 @@ enum {
CHIP_G4X= 7,/* G4X */
CHIP_PINEVIEW   = 8,/* Pineview/Pineview M */
CHIP_IRONLAKE   = 9,/* Clarkdale/Arrandale */
+   CHIP_SANDYBRIDGE=10,/* Sandybridge */
 };
 
 struct agp_i810_softc {
@@ -183,13 +184,23 @@ agp_i810_get_chiptype(struct pci_attach_args *pa)
case PCI_PRODUCT_INTEL_82G45_IGD_1:
case PCI_PRODUCT_INTEL_82G41_IGD_1:
return (CHIP_G4X);
+   break;
case PCI_PRODUCT_INTEL_PINEVIEW_IGC_1:
case PCI_PRODUCT_INTEL_PINEVIEW_M_IGC_1:
return (CHIP_PINEVIEW);
+   break;
case PCI_PRODUCT_INTEL_CLARKDALE_IGD:
case PCI_PRODUCT_INTEL_ARRANDALE_IGD:
return (CHIP_IRONLAKE);
break;
+   case PCI_PRODUCT_INTEL_CORE2G_GT1:
+   case PCI_PRODUCT_INTEL_CORE2G_M_GT1:
+   case PCI_PRODUCT_INTEL_CORE2G_GT2:
+   case PCI_PRODUCT_INTEL_CORE2G_M_GT2:
+   case PCI_PRODUCT_INTEL_CORE2G_GT2_PLUS:
+   case PCI_PRODUCT_INTEL_CORE2G_M_GT2_PLUS:
+   return (CHIP_SANDYBRIDGE);
+   break;
}
return (CHIP_NONE);
 }
@@ -246,6 +257,7 @@ agp_i810_attach(struct device *parent, struct device *self, 
void *aux)
case CHIP_I965:
case CHIP_G4X:
case CHIP_IRONLAKE:
+   case CHIP_SANDYBRIDGE:
gmaddr = AGP_I965_GMADR;
mmaddr = AGP_I965_MMADR;
memtype = PCI_MAPREG_TYPE_MEM | PCI_MAPREG_MEM_TYPE_64BIT;
@@ -477,6 +489,85 @@ agp_i810_attach(struct device *parent, struct device 
*self, void *aux)
gatt->ag_physical = READ4(AGP_I810_PGTBL_CTL) & ~1;
break;
 
+   case CHIP_SANDYBRIDGE:
+
+   /* Stolen memory is set up at the beginning of the aperture by
+* the BIOS, consisting of the GATT followed by 4kb for the
+* BIOS display.
+*/
+
+   gcc1 = (u_int16_t)pci_conf_read(bpa.pa_pc, bpa.pa_tag,
+   AGP_INTEL_SNB_GMCH_CTRL);
+
+   stolen = 4;
+
+   switch (gcc1 & AGP_INTEL_SNB_GMCH_GMS_STOLEN_MASK) {
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_32M:
+   isc->stolen = (32768 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_64M:
+   isc->stolen = (65536 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_96M:
+   isc->stolen = (98304 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_128M:
+   isc->stolen = (131072 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_160M:
+   isc->stolen = (163840 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_192M:
+   isc->stolen = (196608 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_224M:
+   isc->stolen = (229376 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_256M:
+   isc->stolen = (262144 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_288M:
+   isc->stolen = (294912 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_320M:
+   isc->stolen = (327680 - stolen) * 1024 / 4096;
+   break;
+   case AGP_INTEL_SNB_GMCH_GMS_STOLEN_352M:
+   

Re: Xorg vs. DRM & AGP GART on IBM X40 laptop running 4.9 stable (workaround)

[Owain Ainsworth]

On Thu, Aug 18, 2011 at 02:58:31PM -0600, Richard Johnson wrote:
> [Posting for documentation of the workaround, and in case the details
> help find a bug beyond "This ancient laptop's video card RAM is too
> small".]
> 
> 
> I resuscitated an IBM X40 laptop by putting in a HD with a clean install
> of OpenBSD 4.9 release.
> 
> X then failed to start both using a new xorg.conf from 'Xorg -configure',
> and using the xorg.conf created the same way and formerly working under
> OpenBSD 4.7.
> 
> Interesting errors (full logs below):
>  | [3730867.237] (EE) intel(1): [drm] Failed to open DRM device for 
> pci::00:02.1: Operation not permitted
>  | ...
>  | [3730869.731] (WW) intel(1): xf86AcquireGART: AGPIOC_ACQUIRE failed 
> (Device busy)
> 
> Updating to 4.9 stable (kernel, userland, xenocara) as of 2011-08-17,
> built on the X40 itself, showed the same problem.
> 
> Since the error was with intel(1), while intel(0) was earlier configured
> successfully according to the log, a likely workaround was to comment out
> the xorg.conf 2nd detected screen and card specs (Screen1 and Card1).
> 
> That workaround indeed avoids the problem, though at the probable (though
> unconfirmed) cost of no signal out the external VGA port.

The intel driver does not support zaphod-style multihead (the one where
you define an X screen per head). Supporting only xrandr/xinerama style
where the heads extends one shared X screen (see xorg.conf(5) and xrandr(1)).
This has been the case for a couple of years now.

Cheers,
-0-
-- 
Why is it that we rejoice at a birth and grieve at a funeral?  It is
because we are not the person involved.
-- Mark Twain

Re: grep \

[Owain Ainsworth]

On Sun, Jul 17, 2011 at 07:28:11PM +0100, Jason McIntyre wrote:
> On Sun, Jul 17, 2011 at 11:43:03AM -0400, Ted Unangst wrote:
> > I recently learned that our grep does not support the \<\> syntax for
> > word boundaries, only the somewhat more difficult to use [[:<:]] format.
> > It's fairly easy to convert one to the other however.
> > 
> 
> if you do this, we will need to think carefully about how to document
> it. grep(1) itself does not discuss REs, and instead points to
> re_format(7). but you are proposing an extension to grep only.
> 
> can i ask why you want to support this? it is a gnu grep thing or
> something?
\

It is quite a common usage for word boundarys in regular expressions.

As a data point nvi (/usr/bin/vi on openbsd) does support this
shorthand (but only refers to re_format(7) in the manpage, a quick dig
in the source shows it has a conversion function that converts between
``vi'' REs and posix in ex_subst.c (re_conv())). Because of this i find
myself botching grep regexes regularly because it doesn't.

(So that's support for the idea from me, but I won't bitch too loudly if
it is shot down).

-0-
> 
> jmc
> 
> > Index: grep.c
> > ===
> > RCS file: /home/tedu/cvs/src/usr.bin/grep/grep.c,v
> > retrieving revision 1.44
> > diff -u -p -r1.44 grep.c
> > --- grep.c  8 Jul 2011 01:20:24 -   1.44
> > +++ grep.c  17 Jul 2011 15:38:58 -
> > @@ -163,6 +163,54 @@ struct option long_options[] =
> > {NULL,  no_argument,NULL, 0}
> >  };
> >  
> > +#ifndef SMALL
> > +char *
> > +fix_word_boundaries(char *pat)
> > +{
> > +   size_t newlen;
> > +   int bs, repl;
> > +   char c, *newpat, *p, *r;
> > +
> > +   repl = 0;
> > +   p = pat;
> > +   while ((p = strstr(p, "\\<"))) {
> > +   p += 2;
> > +   repl++;
> > +   }
> > +   p = pat;
> > +   while ((p = strstr(p, "\\>"))) {
> > +   p += 2;
> > +   repl++;
> > +   }
> > +   if (!repl)
> > +   return pat;
> > +   newlen = strlen(pat) + 1 + repl * 5;
> > +   newpat = grep_malloc(newlen);
> > +   p = pat;
> > +   r = newpat;
> > +   bs = 0;
> > +   while ((c = *p++)) {
> > +   if (bs && (c == '<' || c == '>')) {
> > +   /* overwrite previous backspace */
> > +   snprintf(r-1, 8, "[[:%c:]]", c);
> > +   r += 6;
> > +   bs = 0;
> > +   continue;
> > +   } else if (!bs && c == '\\') {
> > +   bs = 1;
> > +   } else {
> > +   bs = 0;
> > +   }
> > +   *r++ = c;
> > +   }
> > +   *r = 0;
> > +   if (newlen <= strlen(newpat))
> > +   abort();
> > +   free(pat);
> > +   return newpat;
> > +
> > +}
> > +#endif
> >  
> >  static void
> >  add_pattern(char *pat, size_t len)
> > @@ -198,6 +246,12 @@ add_pattern(char *pat, size_t len)
> > pattern[patterns] = grep_malloc(len + 1);
> > memcpy(pattern[patterns], pat, len);
> > pattern[patterns][len] = '\0';
> > +#ifndef SMALL
> > +   if (!Fflag) {
> > +   pattern[patterns] = 
> > fix_word_boundaries(pattern[patterns]);
> > +   }
> > +#endif
> > +
> > }
> > ++patterns;
> >  }
> 

-- 
HELP!  MY TYPEWRITER IS BROKEN!
-- E. E. CUMMINGS

thou shalt not call hardclock() with biglock held.

[Owain Ainsworth]

i386 is a very naughty arch.

While messing with this code make i386 and amd64 more identical.

guenther@ tested this on an mp i386 for me yesterday, the machine seemed
happy.

Cheers,

-0-

diff --git a/arch/amd64/isa/clock.c b/arch/amd64/isa/clock.c
index 23fc0f0..1b4ff7c 100644
--- a/arch/amd64/isa/clock.c
+++ b/arch/amd64/isa/clock.c
@@ -315,7 +315,7 @@ i8254_initclocks(void)
 
isa_intr_establish(NULL, 0, IST_PULSE, IPL_CLOCK, clockintr,
0, "clock");
-   isa_intr_establish(NULL, 8, IST_PULSE, IPL_CLOCK, rtcintr,
+   isa_intr_establish(NULL, 8, IST_PULSE, IPL_STATCLOCK, rtcintr,
0, "rtc");
 
rtcstart(); /* start the mc146818 clock */
diff --git a/arch/i386/i386/apicvec.s b/arch/i386/i386/apicvec.s
index b8d8424..7976692 100644
--- a/arch/i386/i386/apicvec.s
+++ b/arch/i386/i386/apicvec.s
@@ -170,16 +170,10 @@ XINTR(ltimer):
ioapic_asm_ack()
sti
inclCPUVAR(IDEPTH)
-#ifdef MULTIPROCESSOR
-   call_C_LABEL(i386_softintlock)
-#endif
movl%esp,%eax
pushl   %eax
call_C_LABEL(lapic_clockintr)
addl$4,%esp
-#ifdef MULTIPROCESSOR
-   call_C_LABEL(i386_softintunlock)
-#endif
declCPUVAR(IDEPTH)
jmp _C_LABEL(Xdoreti)
 
diff --git a/arch/i386/include/intr.h b/arch/i386/include/intr.h
index d13f876..86b8ecd 100644
--- a/arch/i386/include/intr.h
+++ b/arch/i386/include/intr.h
@@ -107,7 +107,7 @@ void splassert_check(int, const char *);
 #definespltty()splraise(IPL_TTY)
 #definesplaudio()  splraise(IPL_AUDIO)
 #definesplclock()  splraise(IPL_CLOCK)
-#definesplstatclock()  splhigh()
+#definesplstatclock()  splclock()
 #define splipi()   splraise(IPL_IPI)
 
 /*
diff --git a/arch/i386/include/intrdefs.h b/arch/i386/include/intrdefs.h
index c399d47..ef419d3 100644
--- a/arch/i386/include/intrdefs.h
+++ b/arch/i386/include/intrdefs.h
@@ -65,10 +65,10 @@
 #defineIPL_VM  MAKEIPL(7)  /* memory allocation */
 #defineIPL_AUDIO   MAKEIPL(8)  /* audio */
 #defineIPL_CLOCK   MAKEIPL(9)  /* clock */
-#defineIPL_STATCLOCK   MAKEIPL(10) /* statclock */
-#defineIPL_SCHED   IPL_STATCLOCK
-#defineIPL_HIGHMAKEIPL(11) /* everything */
-#defineIPL_IPI MAKEIPL(12) /* interprocessor interrupt */
+#defineIPL_STATCLOCK   IPL_CLOCK   /* statclock */
+#defineIPL_SCHED   IPL_CLOCK
+#defineIPL_HIGHMAKEIPL(10) /* everything */
+#defineIPL_IPI MAKEIPL(11) /* interprocessor interrupt */
 
 /* Interrupt sharing types. */
 #defineIST_NONE0   /* none */
diff --git a/arch/i386/isa/clock.c b/arch/i386/isa/clock.c
index ef669ff..f881378 100644
--- a/arch/i386/isa/clock.c
+++ b/arch/i386/isa/clock.c
@@ -390,7 +390,7 @@ i8254_initclocks(void)
/* When using i8254 for clock, we also use the rtc for profclock */
(void)isa_intr_establish(NULL, 0, IST_PULSE, IPL_CLOCK,
clockintr, 0, "clock");
-   (void)isa_intr_establish(NULL, 8, IST_PULSE, IPL_CLOCK,
+   (void)isa_intr_establish(NULL, 8, IST_PULSE, IPL_STATCLOCK,
rtcintr, 0, "rtc");
 
rtcstart(); /* start the mc146818 clock */

-- 
The best defense against logic is ignorance.

msync retardery

[Owain Ainsworth]

So, the msync implementation in uvm says this:

  /*
 * XXXCDC: do we really need this semantic?
 *
 * XXX Gak!  If size is zero we are supposed to sync "all
modified
 * pages with the region containing addr".  Unfortunately, we
 * don't really keep track of individual mmaps so we approximate
 * by flushing the range of the map entry containing addr.
 * This can be incorrect if the region splits or is coalesced
 * with a neighbor.
 */

I checked in posix and can find no reference to this at all. So I would
like to suggest this diff. This of course needs quite a bit of testing
(a ports bulk build would be nice), but removing unnecessary crap makes
people happy. Otoh, if something actually depends on this then it may
need to stay.

Cheers,

-0-


diff --git uvm/uvm_mmap.c uvm/uvm_mmap.c
index 168ac46..f0615c7 100644
--- uvm/uvm_mmap.c
+++ uvm/uvm_mmap.c
@@ -637,7 +637,7 @@ sys_msync(struct proc *p, void *v, register_t *retval)
vaddr_t addr;
vsize_t size, pageoff;
vm_map_t map;
-   int rv, flags, uvmflags;
+   int flags, uvmflags;
 
/*
 * extract syscall args from the uap
@@ -669,30 +669,6 @@ sys_msync(struct proc *p, void *v, register_t *retval)
map = &p->p_vmspace->vm_map;
 
/*
-* XXXCDC: do we really need this semantic?
-*
-* XXX Gak!  If size is zero we are supposed to sync "all modified
-* pages with the region containing addr".  Unfortunately, we
-* don't really keep track of individual mmaps so we approximate
-* by flushing the range of the map entry containing addr.
-* This can be incorrect if the region splits or is coalesced
-* with a neighbor.
-*/
-   if (size == 0) {
-   vm_map_entry_t entry;
-   
-   vm_map_lock_read(map);
-   rv = uvm_map_lookup_entry(map, addr, &entry);
-   if (rv == TRUE) {
-   addr = entry->start;
-   size = entry->end - entry->start;
-   }
-   vm_map_unlock_read(map);
-   if (rv == FALSE)
-   return (EINVAL);
-   }
-
-   /*
 * translate MS_ flags into PGO_ flags
 */
uvmflags = PGO_CLEANIT;

-- 
The rain it raineth on the just
And also on the unjust fella,
But chiefly on the just, because
The unjust steals the just's umbrella.
--Lord Bowen

move uvm reserve enforcement to pmemrange

[Owain Ainsworth]

so all allocators obey it, not just uvm_pagealloc (which is increasingly
rarely called). This actually makes it a lot harder to deadlock the
machine under very heavy memory pressure (uvm_pglistalloc for 7 pages
when you have 7 pages left, for example).

I have been using variants of this  diff on my machines for months.

I have discussed doing this with ariane@ many many times. here's the
diff:

ok?
-0-


Index: uvm/uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.111
diff -u -p -r1.111 uvm_page.c
--- uvm/uvm_page.c  3 Jul 2011 18:34:14 -   1.111
+++ uvm/uvm_page.c  3 Jul 2011 20:14:37 -
@@ -76,7 +76,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -885,43 +884,19 @@ uvm_pagealloc(struct uvm_object *obj, vo
struct vm_page *pg;
struct pglist pgl;
int pmr_flags;
-   boolean_t use_reserve;
 
KASSERT(obj == NULL || anon == NULL);
KASSERT(off == trunc_page(off));
 
-   /*
-* check to see if we need to generate some free pages waking
-* the pagedaemon.
-*/
-   if ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freemin ||
-   ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freetarg &&
-   (uvmexp.inactive + BUFPAGES_INACT) < uvmexp.inactarg))
-   wakeup(&uvm.pagedaemon);
-
-   /*
-* fail if any of these conditions is true:
-* [1]  there really are no free pages, or
-* [2]  only kernel "reserved" pages remain and
-*the page isn't being allocated to a kernel object.
-* [3]  only pagedaemon "reserved" pages remain and
-*the requestor isn't the pagedaemon.
-*/
-
-   use_reserve = (flags & UVM_PGA_USERESERVE) ||
-   (obj && UVM_OBJ_IS_KERN_OBJECT(obj));
-   if ((uvmexp.free <= uvmexp.reserve_kernel && !use_reserve) ||
-   (uvmexp.free <= uvmexp.reserve_pagedaemon &&
-!((curproc == uvm.pagedaemon_proc) ||
- (curproc == syncerproc
-   goto fail;
-
+   /* XXX these functions should share flags */
pmr_flags = UVM_PLA_NOWAIT;
if (flags & UVM_PGA_ZERO)
pmr_flags |= UVM_PLA_ZERO;
+   if (flags & UVM_PGA_USERESERVE)
+   pmr_flags |= UVM_PLA_USERESERVE;
TAILQ_INIT(&pgl);
if (uvm_pmr_getpages(1, 0, 0, 1, 0, 1, pmr_flags, &pgl) != 0)
-   goto fail;
+   return (NULL);
 
pg = TAILQ_FIRST(&pgl);
KASSERT(pg != NULL && TAILQ_NEXT(pg, pageq) == NULL);
@@ -932,10 +907,7 @@ uvm_pagealloc(struct uvm_object *obj, vo
if (flags & UVM_PGA_ZERO)
atomic_clearbits_int(&pg->pg_flags, PG_CLEAN);
 
-   return(pg);
-
- fail:
-   return (NULL);
+   return (pg);
 }
 
 /*
Index: uvm/uvm_pmemrange.c
===
RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
retrieving revision 1.25
diff -u -p -r1.25 uvm_pmemrange.c
--- uvm/uvm_pmemrange.c 22 Jun 2011 00:16:47 -  1.25
+++ uvm/uvm_pmemrange.c 3 Jul 2011 20:14:37 -
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include  /* for BUFPAGES defines */
 #include   /* XXX for atomic */
 
 /*
@@ -747,6 +748,7 @@ uvm_pmr_getpages(psize_t count, paddr_t 
int memtype;/* Requested memtype. */
int memtype_init;   /* Best memtype. */
int desperate;  /* True if allocation failed. */
+   int is_pdaemon;
 #ifdef DIAGNOSTIC
struct  vm_page *diag_prev; /* Used during validation. */
 #endif /* DIAGNOSTIC */
@@ -762,6 +764,27 @@ uvm_pmr_getpages(psize_t count, paddr_t 
(boundary == 0 || maxseg * boundary >= count) &&
TAILQ_EMPTY(result));
 
+   is_pdaemon = ((curproc == uvm.pagedaemon_proc) ||
+ (curproc == syncerproc));
+
+   /*
+* All allocations by the pagedaemon automatically get access to
+* the kernel reserve of pages so swapping can catch up with memory
+* exhaustion
+*/
+   if (is_pdaemon)
+   flags |= UVM_PLA_USERESERVE;
+
+   /*
+* check to see if we need to generate some free pages waking
+* the pagedaemon.
+*/
+   if ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freemin ||
+   ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freetarg &&
+   (uvmexp.inactive + BUFPAGES_INACT) < uvmexp.inactarg))
+   wakeup(&uvm.pagedaemon);
+
+
/*
 * TRYCONTIG is a noop if you only want a single segment.
 * Remove it if that's the case: otherwise it'll deny the fast
@@ -835,6 +858,20 @@ retry: /* Return point after sleeping. 
fnsegs = 0;
 
uvm_lock_fpageq();
+
+   /*
+* fail if any of these conditions are true:
+* [1]  there really a

pmap_is_direct_mapped

[Owain Ainsworth]

bikeshed time.

pmap_is_direct_mapped() returns a boolean (int) value explaining whether
or not a given virtual address is part of the direct map for that arch.

I'd like this interface so km_alloc can do the direct-map-if-contig
mapping behaviour. This does not do m88k, hppa* and vax because I can't
find a nice define that explains where the direct segment might end.


Diff includes the km_alloc change so you can see why I want it.

Any objections to the idea? Pointers as to how to do the other archs?

-0-

diff --git a/arch/alpha/include/pmap.h b/arch/alpha/include/pmap.h
index f85520b..3d9feaa 100644
--- a/arch/alpha/include/pmap.h
+++ b/arch/alpha/include/pmap.h
@@ -198,6 +198,8 @@ extern  pt_entry_t *VPT;/* Virtual Page 
Table */
  */
 #definepmap_map_direct(pg) ALPHA_PHYS_TO_K0SEG(VM_PAGE_TO_PHYS(pg))
 #definepmap_unmap_direct(va)   
PHYS_TO_VM_PAGE(ALPHA_K0SEG_TO_PHYS((va)))
+#define pmap_is_direct_mapped(va)  (kva >= ALPHA_K0SEG_BASE && \
+   kva <= ALPHA_k0SEG_END)
 #define__HAVE_PMAP_DIRECT
 
 paddr_t vtophys(vaddr_t);
diff --git a/arch/amd64/include/pmap.h b/arch/amd64/include/pmap.h
index e06158f..99c6d85 100644
--- a/arch/amd64/include/pmap.h
+++ b/arch/amd64/include/pmap.h
@@ -561,6 +561,8 @@ kvtopte(vaddr_t va)
 #define PMAP_DIRECT_UNMAP(va)  ((paddr_t)va - PMAP_DIRECT_BASE)
 #define pmap_map_direct(pg)PMAP_DIRECT_MAP(VM_PAGE_TO_PHYS(pg))
 #define pmap_unmap_direct(va)  PHYS_TO_VM_PAGE(PMAP_DIRECT_UNMAP(va))
+#define pmap_is_direct_mapped(va)  (va >= PMAP_DIRECT_BASE &&  \
+   va <= PMAP_DIRECT_END)
 
 #define __HAVE_PMAP_DIRECT
 
diff --git a/arch/mips64/include/pmap.h b/arch/mips64/include/pmap.h
index 9856238..78736b6 100644
--- a/arch/mips64/include/pmap.h
+++ b/arch/mips64/include/pmap.h
@@ -166,6 +166,7 @@ void pmap_update_kernel_page(vaddr_t, pt_entry_t);
 #define__HAVE_PMAP_DIRECT
 vaddr_tpmap_map_direct(vm_page_t);
 vm_page_t pmap_unmap_direct(vaddr_t);
+#define pmap_is_direct_mapped(va)  IS_XKPHYS(va)
 #endif
 
 #endif /* _KERNEL */
diff --git a/arch/powerpc/include/pmap.h b/arch/powerpc/include/pmap.h
index e312669..96893e8 100644
--- a/arch/powerpc/include/pmap.h
+++ b/arch/powerpc/include/pmap.h
@@ -122,6 +122,7 @@ boolean_t pteclrbits(struct vm_page *pg, u_int mask, u_int 
clear);
  */
 #define pmap_map_direct(pg)((vaddr_t)VM_PAGE_TO_PHYS(pg))
 #define pmap_unmap_direct(va)  PHYS_TO_VM_PAGE((paddr_t)va)
+#define pmap_is_direct_mapped(va)  (va >= 0 && va <= 0x8000)
 #define__HAVE_PMAP_DIRECT
 
 void pmap_bootstrap(u_int kernelstart, u_int kernelend);
diff --git a/arch/sh/include/pmap.h b/arch/sh/include/pmap.h
index 25d4a76..7d17604 100644
--- a/arch/sh/include/pmap.h
+++ b/arch/sh/include/pmap.h
@@ -93,6 +93,8 @@ vaddr_t   pmap_prefer_offset(vaddr_t);
 #define__HAVE_PMAP_DIRECT
 vaddr_tpmap_map_direct(vm_page_t);
 vm_page_t pmap_unmap_direct(vaddr_t);
+#define pmap_is_direct_mapped(va)  (va >= SH3_P1SEG_BASE &&\
+   va <= SH3_P2SEG_END)
 
 /* MD pmap utils. */
 pt_entry_t *__pmap_pte_lookup(pmap_t, vaddr_t);
diff --git a/arch/vax/include/pmap.h b/arch/vax/include/pmap.h
index c07cb92..d63f2ce 100644
--- a/arch/vax/include/pmap.h
+++ b/arch/vax/include/pmap.h
@@ -104,6 +104,8 @@ extern  struct pmap kernel_pmap_store;
  */
 #define pmap_map_direct(pg)(VM_PAGE_TO_PHYS(pg) | KERNBASE)
 #define pmap_unmap_direct(va) PHYS_TO_VM_PAGE((va) & ~KERNBASE)
+extern vaddr_t virtual_avail;
+#define pmap_is_direct_mapped(va)  (kva >= virtual_avail)
 #define__HAVE_PMAP_DIRECT
 
 #define PMAP_STEAL_MEMORY
diff --git a/uvm/uvm_km.c b/uvm/uvm_km.c
index 4db83ce..d1c059a 100644
--- a/uvm/uvm_km.c
+++ b/uvm/uvm_km.c
@@ -876,17 +876,9 @@ km_alloc(size_t sz, const struct kmem_va_mode *kv,
}
 
 #ifdef __HAVE_PMAP_DIRECT
-   if (kv->kv_align || kv->kv_executable)
+   /* malloc isn't smart enough for direct mapping */
+   if (kv->kv_align || kv->kv_executable || kv == &kv_intrsafe)
goto alloc_va;
-#if 1
-   /*
-* For now, only do DIRECT mappings for single page
-* allocations, until we figure out a good way to deal
-* with contig allocations in km_free.
-*/
-   if (!kv->kv_singlepage)
-   goto alloc_va;
-#endif
/*
 * Dubious optimization. If we got a contig segment, just map it
 * through the direct map.
@@ -995,11 +987,14 @@ km_free(void *v, size_t sz, const struct kmem_va_mode *kv,
goto free_va;
}
 
-   if (kv->kv_singlepage) {
 #ifdef __HAVE_PMAP_DIRECT
-   pg = pmap_unmap_direct(va);
-   uvm_pagefree(pg);
+   if (kv->kv_singlepage || pmap_is_direct_mapped(va)) {
+   for (va = sva; va < eva; va += PAGE_SIZE)
+   uv

Re: Remove and clean up callers of pmap_clear_reference and pmap_page_protect

[Owain Ainsworth]

On Fri, Apr 15, 2011 at 05:15:02PM +0100, Owain Ainsworth wrote:
> audit callers of pmap_clear_reference() and
> pmap_page_protect(,,VM_PROT_NONE) just before uvm_pagedeactivate noting
> the fact that freshly deactivated pages have their reference cleared in
> uvm_pagedeactivate already.
> 
> first off, clear_reference:
> 
> uvm_anon.c -> only called on swapoff. we don't really require the reference
> cleared if it has been accessed. doesn't matter. and if it was just swapped in
> then the page won't be deactivated and it'll be freshly cleared again. Now I
> come to think about it, though deactivating something we just swapped in is
> wrong, since it isn't swapped out and has no backing store. deactivated pages
> mean we can dump them at will. 
> 
> uvm_aobj.c exactly the same situation as above.
> 
> uvm_fault.c -> deactivating anons due to MADV. so either it is already
> deactivated and will have reference cleared, or is already deactivated and 
> has been
> referenced since, so the advice is bullshit anyway, or it is active and will 
> be
> cleared. (also only for UBC anyway, so this discussion was somewhat
> redundant)
> 
> uvm_map.c -> only for ubc 
> 
> remove all of those redundant calls. The UBC stuff is useless now
> anyway.
> 
> with pmap_page_protect, every caller of uvm_pagedeactivate first calls
> pmap_page_protect. This is techinically incorrect, but done due to pmap
> bugs.  move the page protect call into uvm_pagedeactivate itself and
> detail with an XXX comment why this is done.
> 
> The page_protect part of this diff was commited by art a few years ago
> and backed out as part of the big uvm backout and never reinstated.
> 
> ok?

Here's a version of this diff that applies on top of the vnode.c fix
from last week (so just the uvm_vnode.c chunks changed).

I'm still running this everywhere.

-0-

diff --git uvm/uvm_anon.c uvm/uvm_anon.c
index d0c942b..9f2880f 100644
--- uvm/uvm_anon.c
+++ uvm/uvm_anon.c
@@ -351,8 +351,6 @@ uvm_anon_pagein(struct vm_anon *anon)
 * deactivate the page (to put it on a page queue)
 */
 
-   pmap_clear_reference(pg);
-   pmap_page_protect(pg, VM_PROT_NONE);
uvm_lock_pageq();
uvm_pagedeactivate(pg);
uvm_unlock_pageq();
diff --git uvm/uvm_aobj.c uvm/uvm_aobj.c
index b2ba563..d53c21a 100644
--- uvm/uvm_aobj.c
+++ uvm/uvm_aobj.c
@@ -787,10 +787,6 @@ uao_flush(struct uvm_object *uobj, voff_t start, voff_t 
stop, int flags)
continue;
 
uvm_lock_pageq();
-   /* zap all mappings for the page. */
-   pmap_page_protect(pp, VM_PROT_NONE);
-
-   /* ...and deactivate the page. */
uvm_pagedeactivate(pp);
uvm_unlock_pageq();
 
@@ -1369,10 +1365,6 @@ uao_pagein_page(struct uvm_aobj *aobj, int pageidx)
/*
 * deactivate the page (to put it on a page queue).
 */
-   pmap_clear_reference(pg);
-#ifndef UBC
-   pmap_page_protect(pg, VM_PROT_NONE);
-#endif
uvm_lock_pageq();
uvm_pagedeactivate(pg);
uvm_unlock_pageq();
diff --git uvm/uvm_fault.c uvm/uvm_fault.c
index 76f0708..8a11a3f 100644
--- uvm/uvm_fault.c
+++ uvm/uvm_fault.c
@@ -202,14 +202,8 @@ uvmfault_anonflush(struct vm_anon **anons, int n)
pg = anons[lcv]->an_page;
if (pg && (pg->pg_flags & PG_BUSY) == 0 && pg->loan_count == 0) 
{
uvm_lock_pageq();
-   if (pg->wire_count == 0) {
-#ifdef UBC
-   pmap_clear_reference(pg);
-#else
-   pmap_page_protect(pg, VM_PROT_NONE);
-#endif
+   if (pg->wire_count == 0)
uvm_pagedeactivate(pg);
-   }
uvm_unlock_pageq();
}
simple_unlock(&anons[lcv]->an_lock);
diff --git uvm/uvm_map.c uvm/uvm_map.c
index dee6f73..919b43d 100644
--- uvm/uvm_map.c
+++ uvm/uvm_map.c
@@ -3181,15 +3181,7 @@ uvm_map_clean(struct vm_map *map, vaddr_t start, vaddr_t 
end, int flags)
}
KASSERT(pg->uanon == anon);
 
-#ifdef UBC
/* ...and deactivate the page. */
-   pmap_clear_reference(pg);
-#else
-   /* zap all mappings for the page. */
-   pmap_page_protect(pg, VM_PROT_NONE);
-
-   /* ...and deactivate the page. */
-#endif
uvm_pagedeactivate(pg);
 
uvm_unlock_pageq();
diff --git uvm/uvm_page.c uvm/uvm_page.c
index e0eddfe..b3278

Re: check for correct flag in uvm_page_unbusy

[Owain Ainsworth]

How about this now?

I've got some more important uvm diffs on the way I but would like to
get the small ones out of my tree.

-0-

On Tue, May 31, 2011 at 12:09:35AM +0100, Owain Ainsworth wrote:
> No functional change since aobjs should never hit this path. However, I
> introduced this diff when I reworked the page releasing stuff for
> objects.
> 
> ok?
> 
> diff --git uvm/uvm_page.c uvm/uvm_page.c
> index 10ef7d1..27e970a 100644
> --- uvm/uvm_page.c
> +++ uvm/uvm_page.c
> @@ -1099,7 +1099,7 @@ uvm_page_unbusy(struct vm_page **pgs, int npgs)
>   uvm_lock_pageq();
>   pmap_page_protect(pg, VM_PROT_NONE);
>   /* XXX won't happen right now */
> - if (pg->pg_flags & PQ_ANON)
> + if (pg->pg_flags & PQ_AOBJ)
>   uao_dropswap(uobj,
>   pg->offset >> PAGE_SHIFT);
>   uvm_pagefree(pg);
> -- 
> 1.7.5
> 
> 
> -- 
> Blood flows down one leg and up the other.

-- 
Campus sidewalks never exist as the straightest line between two
points.
-- M. M. Johnston

Re: Don't bother checking for an empty pageq before freeing the list

[Owain Ainsworth]

How about this now?

On Tue, May 31, 2011 at 12:03:49AM +0100, Owain Ainsworth wrote:
> It will handle an empty list just fine (there is a potential small
> optimisation in there to avoid grabbing the fpageqlock if no pages need
> freeing but that is another diff)
> 
> ok?
> 
> diff --git uvm/uvm_km.c uvm/uvm_km.c
> index 1990adf..818cb18 100644
> --- uvm/uvm_km.c
> +++ uvm/uvm_km.c
> @@ -925,8 +925,7 @@ alloc_va:
>   while (uvm_km_pages.free == 0) {
>   if (kd->kd_waitok == 0) {
>   mtx_leave(&uvm_km_pages.mtx);
> - if (!TAILQ_EMPTY(&pgl))
> - uvm_pglistfree(&pgl);
> + uvm_pglistfree(&pgl);
>   return NULL;
>   }
>   msleep(&uvm_km_pages.free, &uvm_km_pages.mtx, PVM,
> @@ -959,8 +958,7 @@ try_map:
>   tsleep(map, PVM, "km_allocva", 0);
>   goto try_map;
>   }
> - if (!TAILQ_EMPTY(&pgl))
> - uvm_pglistfree(&pgl);
> + uvm_pglistfree(&pgl);
>   return (NULL);
>   }
>   }
> -- 
> 1.7.5
> 
> -- 
> Banectomy, n.:
>   The removal of bruises on a banana.
>   -- Rich Hall, "Sniglets"

-- 
"Matrimony isn't a word, it's a sentence."

Re: Move uvm_pglist* to uvm_page.c

[Owain Ainsworth]

How about this now? 

On Tue, May 31, 2011 at 12:05:04AM +0100, Owain Ainsworth wrote:
> These functions used to be big and complicated, now they are glorified
> wrappers around pmemrange and don't really need their own file.
> Discussed with ariane@ a while ago.
> 
> ok?
> 
> 
> diff --git conf/files conf/files
> index 02da860..017e5f9 100644
> --- conf/files
> +++ conf/files
> @@ -1007,7 +1007,6 @@ file uvm/uvm_object.c
>  file uvm/uvm_page.c
>  file uvm/uvm_pager.c
>  file uvm/uvm_pdaemon.c
> -file uvm/uvm_pglist.c
>  file uvm/uvm_pmemrange.c
>  file uvm/uvm_stat.c
>  file uvm/uvm_swap.c
> diff --git uvm/uvm_page.c uvm/uvm_page.c
> index 10ef7d1..ed8e6d4 100644
> --- uvm/uvm_page.c
> +++ uvm/uvm_page.c
> @@ -806,6 +806,81 @@ uvm_pagealloc_pg(struct vm_page *pg, struct uvm_object 
> *obj, voff_t off,
>  }
>  
>  /*
> + * uvm_pglistalloc: allocate a list of pages
> + *
> + * => allocated pages are placed at the tail of rlist.  rlist is
> + *assumed to be properly initialized by caller.
> + * => returns 0 on success or errno on failure
> + * => doesn't take into account clean non-busy pages on inactive list
> + *   that could be used(?)
> + * => params:
> + *   sizethe size of the allocation, rounded to page size.
> + *   low the low address of the allowed allocation range.
> + *   highthe high address of the allowed allocation range.
> + *   alignment   memory must be aligned to this power-of-two boundary.
> + *   boundaryno segment in the allocation may cross this 
> + *   power-of-two boundary (relative to zero).
> + * => flags:
> + *   UVM_PLA_NOWAIT  fail if allocation fails
> + *   UVM_PLA_WAITOK  wait for memory to become avail
> + *   UVM_PLA_ZEROreturn zeroed memory
> + */
> +int
> +uvm_pglistalloc(psize_t size, paddr_t low, paddr_t high, paddr_t alignment,
> +paddr_t boundary, struct pglist *rlist, int nsegs, int flags)
> +{
> + UVMHIST_FUNC("uvm_pglistalloc"); UVMHIST_CALLED(pghist);
> +
> + KASSERT((alignment & (alignment - 1)) == 0);
> + KASSERT((boundary & (boundary - 1)) == 0);
> + KASSERT(!(flags & UVM_PLA_WAITOK) ^ !(flags & UVM_PLA_NOWAIT));
> +
> + if (size == 0)
> + return (EINVAL);
> +
> + if ((high & PAGE_MASK) != PAGE_MASK) {
> + printf("uvm_pglistalloc: Upper boundary 0x%lx "
> + "not on pagemask.\n", (unsigned long)high);
> + }
> +
> + /*
> +  * Our allocations are always page granularity, so our alignment
> +  * must be, too.
> +  */
> + if (alignment < PAGE_SIZE)
> + alignment = PAGE_SIZE;
> +
> + low = atop(roundup(low, alignment));
> + /*
> +  * high + 1 may result in overflow, in which case high becomes 0x0,
> +  * which is the 'don't care' value.
> +  * The only requirement in that case is that low is also 0x0, or the
> +  * low +  */
> + high = atop(high + 1);
> + size = atop(round_page(size));
> + alignment = atop(alignment);
> + if (boundary < PAGE_SIZE && boundary != 0)
> + boundary = PAGE_SIZE;
> + boundary = atop(boundary);
> +
> + return uvm_pmr_getpages(size, low, high, alignment, boundary, nsegs,
> + flags, rlist);
> +}
> +
> +/*
> + * uvm_pglistfree: free a list of pages
> + *
> + * => pages should already be unmapped
> + */
> +void
> +uvm_pglistfree(struct pglist *list)
> +{
> + UVMHIST_FUNC("uvm_pglistfree"); UVMHIST_CALLED(pghist);
> + uvm_pmr_freepageq(list);
> +}
> +
> +/*
>   * interface used by the buffer cache to allocate a buffer at a time.
>   * The pages are allocated wired in DMA accessible memory
>   */
> diff --git uvm/uvm_pglist.c uvm/uvm_pglist.c
> deleted file mode 100644
> index d29fb14..000
> --- uvm/uvm_pglist.c
> +++ /dev/null
> @@ -1,136 +0,0 @@
> -/*   $OpenBSD$   */
> -/*   $NetBSD: uvm_pglist.c,v 1.13 2001/02/18 21:19:08 chs Exp $  */
> -
> -/*-
> - * Copyright (c) 1997 The NetBSD Foundation, Inc.
> - * All rights reserved.
> - *  
> - * This code is derived from software contributed to The NetBSD Foundation
> - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
> - * NASA Ames Research Center.  
> - *
> - * Redistribution and use in source and binary forms, with or without
> - * modification, are permitted provided that the following conditions
> - * are met:
> - * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of condit

Re: replaced handrolled version of uvmfault_unlockmaps with that function

[Owain Ainsworth]

How about this now?

On Tue, May 31, 2011 at 12:06:15AM +0100, Owain Ainsworth wrote:
> ok?
> 
> diff --git uvm/uvm_fault.c uvm/uvm_fault.c
> index 76f0708..76429dc 100644
> --- uvm/uvm_fault.c
> +++ uvm/uvm_fault.c
> @@ -1936,11 +1936,7 @@ uvmfault_lookup(struct uvm_faultinfo *ufi, boolean_t 
> write_lock)
>*/
>   if (UVM_ET_ISSUBMAP(ufi->entry)) {
>   tmpmap = ufi->entry->object.sub_map;
> - if (write_lock) {
> - vm_map_unlock(ufi->map);
> - } else {
> - vm_map_unlock_read(ufi->map);
> - }
> + uvmfault_unlockmaps(ufi, write_lock);
>   ufi->map = tmpmap;
>   continue;
>   }
> -- 
> 1.7.5
> 
> -- 
> It's easier to fight for one's principles than to live up to them.

-- 
I used to be an agnostic, but now I'm not so sure.

Re: bus_dmamem_map fix (test+ok)

[Owain Ainsworth]

On Wed, Jun 22, 2011 at 09:32:06PM +0200, Ariane van der Steldt wrote:
> On Tue, Jun 21, 2011 at 09:00:49PM +0200, Ariane van der Steldt wrote:
> > Bus_dmamem_map has a bug in its error path, where it frees the wrong
> > memory in the wrong way.
> 
> After some discussion on icb, the comments and the pmap_remove can go
> too. The pmap_remove is executed by uvm_km_free() at uvm_unmap_remove()
> and uvm_km_free won't use the pmap but the object to lookup pages (and
> the object has none at these addresses).
> 
> Ok?

OK.

> -- 
> Ariane
> 
> 
> Index: arch/alpha/dev/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/alpha/dev/bus_dma.c,v
> retrieving revision 1.30
> diff -u -d -p -r1.30 bus_dma.c
> --- arch/alpha/dev/bus_dma.c  26 Dec 2010 15:40:58 -  1.30
> +++ arch/alpha/dev/bus_dma.c  22 Jun 2011 18:59:28 -
> @@ -614,12 +614,8 @@ _bus_dmamem_map(t, segs, nsegs, size, kv
>   VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
>   VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
>   if (error) {
> - /*
> -  * Clean up after ourselves.
> -  * XXX uvm_wait on WAITOK
> -  */
>   pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, ssize);
> + uvm_km_free(kernel_map, sva, ssize);
>   return (error);
>   }
>   }
> Index: arch/amd64/amd64/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bus_dma.c,v
> retrieving revision 1.36
> diff -u -d -p -r1.36 bus_dma.c
> --- arch/amd64/amd64/bus_dma.c2 Apr 2011 16:37:39 -   1.36
> +++ arch/amd64/amd64/bus_dma.c22 Jun 2011 18:59:28 -
> @@ -492,12 +492,8 @@ _bus_dmamem_map(bus_dma_tag_t t, bus_dma
>   VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
>   VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
>   if (error) {
> - /*
> -  * Clean up after ourselves.
> -  * XXX uvm_wait on WAITOK
> -  */
>   pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, ssize);
> + uvm_km_free(kernel_map, sva, ssize);
>   return (error);
>   }
>   }
> Index: arch/arm/arm/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/arm/arm/bus_dma.c,v
> retrieving revision 1.20
> diff -u -d -p -r1.20 bus_dma.c
> --- arch/arm/arm/bus_dma.c4 Jan 2011 21:12:55 -   1.20
> +++ arch/arm/arm/bus_dma.c22 Jun 2011 18:59:30 -
> @@ -718,12 +718,8 @@ _bus_dmamem_map(bus_dma_tag_t t, bus_dma
>   VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
>   VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
>   if (error) {
> - /*
> -  * Clean up after ourselves.
> -  * XXX uvm_wait on WAITOK
> -  */
>   pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, ssize);
> + uvm_km_free(kernel_map, sva, ssize);
>   return (error);
>   }
>   /*
> Index: arch/aviion/aviion/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/aviion/aviion/bus_dma.c,v
> retrieving revision 1.3
> diff -u -d -p -r1.3 bus_dma.c
> --- arch/aviion/aviion/bus_dma.c  26 Dec 2010 15:40:59 -  1.3
> +++ arch/aviion/aviion/bus_dma.c  22 Jun 2011 18:59:30 -
> @@ -544,12 +544,8 @@ bus_dmamem_map(t, segs, nsegs, size, kva
>  VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
>  VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
>  if (error) {
> -   /*
> -* Clean up after ourselves.
> -* XXX uvm_wait on WAITOK
> -*/
> pmap_update(pmap_kernel());
> -   uvm_km_free(kernel_map, va, ssize);
> +   uvm_km_free(kernel_map, sva, ssize);
> return (error);
>  }
>  }
> Index: arch/i386/i386/bus_dma.c
> ===

Re: hibernate_machdep.c depends on acpi

[Owain Ainsworth]

On Mon, Jun 20, 2011 at 01:54:38PM +0200, Mark Kettenis wrote:
> > Date: Mon, 20 Jun 2011 13:22:52 +0200 (CEST)
> > From: Mark Kettenis 
> > 
> > > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > > From: Mike Belopuhov 
> > > 
> > > hi,
> > > 
> > > the hibernate_machdep.c file depends on the acpi so it would be
> > > nice if we excluded this file if kernel config doesn't reference
> > > acpi. a simple fix that establishes the dependency is below. ok?
> > 
> > The hibernate code doesn't really depend on ACPI.  Currently it is
> > only called by the acpi code, but it should work just as well on
> > systems without ACPI.
> > 
> > The code should be !small_kernel though; it seems it is currently
> > wasting ramdisk space.
> 
> Turns out it isn't actually wasting space, or at least not a lot of
> it, since the whole file is wrapped in #ifndef SMALL_KERNEL.  We could
> still consider adding !small_kernel, since it will speed up building
> ramdisk kernels a bit.

Agreed, !small_kernel in the config is much nicer than wrapping the
whole file in an #ifndef.

If no one else does this i'll whip up the diff later today.

-0-
-- 
The sooner all the animals are dead, the sooner we'll find their money.
-- Ed Bluestone, "The National Lampoon"

softraid crypto: preallocate crypops and dma buffers.

[Owain Ainsworth]

So here's the problem: ENOMEM on io in a hba driver is bad juju.

In more detail: 

When preparing for each io softraid crypto does a
sr_crypto_getcryptop(). This operation does a few things:

- allocate a uio and iovec from a pool.
- if this is a read then allocate a dma buffer with dma_alloc (up to
   MAXPHYS, i.e. 64k)
- allocate a cryptop to be used with the crypto(9) framework.
- initialise the above for use in the io.

So if you are getting very low on memory, one of these operations
(probably the dma alloc) will fail. when this happens softraid returns
XS_DRIVER_STUFFUP to scsi land. This returns an EIO back to callers.

Now it is fairly common to use softdep in these situations, synchronous
filesystems are slw. softdep has certain assumptions about how
things will work. if a queued dependancy fails that invalidates these
assumptions. softraid panics in this case. I used to hit this repeatedly
(several times a day) before I bought more memory.

in general, most disk controllers prealloc everything they need (that
isn't passed down to them) so that this won't be a problem.

This diff does the same for softraid crypto. It'll eat just over 1meg of
kva, but it is hardly the only driver to need to do that.

The only slightly scary thing here is the cryptodesc list manipulations
(the comments explain why they are necesary).

I'm typing from a machine that runs this. todd@ is also testing it and
marco kindly did some horrible io torture on a machine running this too
and it runs quite nicely.

A side benefit is that due to missing out allocations in every disk io
this is actually slightly faster in io too.

More testing would be appreciated. Cheers,

-0-

diff --git dev/softraid_crypto.c dev/softraid_crypto.c
index 3259121..a60824e 100644
--- dev/softraid_crypto.c
+++ dev/softraid_crypto.c
@@ -56,9 +56,26 @@
 #include 
 #include 
 
-struct cryptop *sr_crypto_getcryptop(struct sr_workunit *, int);
+/*
+ * the per-io data that we need to preallocate. We can't afford to allow io
+ * to start failing when memory pressure kicks in.
+ * We can store this in the WU because we assert that only one
+ * ccb per WU will ever be active.
+ */
+struct sr_crypto_wu {
+   TAILQ_ENTRY(sr_crypto_wu)cr_link;
+   struct uio   cr_uio;
+   struct iovec cr_iov;
+   struct cryptop  *cr_crp;
+   struct cryptodesc   *cr_descs;
+   struct sr_workunit  *cr_wu;
+   void*cr_dmabuf;
+};
+
+
+struct sr_crypto_wu *sr_crypto_wu_get(struct sr_workunit *, int);
+void   sr_crypto_wu_put(struct sr_crypto_wu *);
 intsr_crypto_create_keys(struct sr_discipline *);
-void   *sr_crypto_putcryptop(struct cryptop *);
 intsr_crypto_get_kdf(struct bioc_createraid *,
struct sr_discipline *);
 intsr_crypto_decrypt(u_char *, u_char *, u_char *, size_t, int);
@@ -78,7 +95,7 @@ int   sr_crypto_meta_opt_load(struct sr_discipline *,
struct sr_meta_opt *);
 intsr_crypto_write(struct cryptop *);
 intsr_crypto_rw(struct sr_workunit *);
-intsr_crypto_rw2(struct sr_workunit *, struct cryptop *);
+intsr_crypto_rw2(struct sr_workunit *, struct sr_crypto_wu *);
 void   sr_crypto_intr(struct buf *);
 intsr_crypto_read(struct cryptop *);
 void   sr_crypto_finish_io(struct sr_workunit *);
@@ -230,40 +247,35 @@ done:
return (rv);
 }
 
-struct cryptop *
-sr_crypto_getcryptop(struct sr_workunit *wu, int encrypt)
+
+struct sr_crypto_wu *
+sr_crypto_wu_get(struct sr_workunit *wu, int encrypt)
 {
struct scsi_xfer*xs = wu->swu_xs;
struct sr_discipline*sd = wu->swu_dis;
-   struct cryptop  *crp = NULL;
+   struct sr_crypto_wu *crwu;
struct cryptodesc   *crd;
-   struct uio  *uio = NULL;
-   int flags, i, n, s;
+   int flags, i, n;
daddr64_t   blk = 0;
u_int   keyndx;
 
-   DNPRINTF(SR_D_DIS, "%s: sr_crypto_getcryptop wu: %p encrypt: %d\n",
+   DNPRINTF(SR_D_DIS, "%s: sr_crypto_wu_get wu: %p encrypt: %d\n",
DEVNAME(sd->sd_sc), wu, encrypt);
 
-   s = splbio();
-   uio = pool_get(&sd->mds.mdd_crypto.sr_uiopl, PR_ZERO | PR_NOWAIT);
-   if (uio == NULL)
-   goto poolunwind;
-   uio->uio_iov = pool_get(&sd->mds.mdd_crypto.sr_iovpl,
-   PR_ZERO | PR_NOWAIT);
-   if (uio->uio_iov == NULL)
-   goto poolunwind;
-   splx(s);
+   mtx_enter(&sd->mds.mdd_crypto.scr_mutex);
+   if ((crwu = TAILQ_FIRST(&sd->mds.mdd_crypto.scr_wus)) != NULL)
+   TAILQ_REMOVE(&sd->mds.mdd_crypto.scr_wus, crwu, cr_link);
+   mtx_leave(&sd->mds.mdd_crypto.scr_mutex);
+   if (crwu == NULL)
+   panic("sr_crypto_w

Re: iwn(4) MSI

[Owain Ainsworth]

On Thu, Jun 02, 2011 at 11:55:54PM +0200, Mark Kettenis wrote:
> > Date: Thu, 2 Jun 2011 22:49:43 +0100
> > From: Owain Ainsworth 
> > 
> > Been running with this for a couple of weeks, seems to work fine.
> > 
> > ok?
> > 
> > diff --git dev/pci/if_iwn.c dev/pci/if_iwn.c
> > index 16765f4..a54556b 100644
> > --- dev/pci/if_iwn.c
> > +++ dev/pci/if_iwn.c
> > @@ -338,7 +338,8 @@ iwn_attach(struct device *parent, struct device *self, 
> > void *aux)
> > }
> >  
> > /* Install interrupt handler. */
> > -   if (pci_intr_map(pa, &ih) != 0) {
> > +   if (pci_intr_map_msi(pa, &ih) != 0 &&
> > +   pci_intr_map(pa, &ih) != 0) {
> > printf(": can't map interrupt\n");
> > return;
> > }
> 
> Please keep those calls on a single line, to keep this consistent with
> the other wireless drivers.

I forgot about this diff for a while, but sure:

ok?


diff --git dev/pci/if_iwn.c dev/pci/if_iwn.c
index 16765f4..4ebcb95 100644
--- dev/pci/if_iwn.c
+++ dev/pci/if_iwn.c
@@ -338,7 +338,7 @@ iwn_attach(struct device *parent, struct device *self, void 
*aux)
}
 
/* Install interrupt handler. */
-   if (pci_intr_map(pa, &ih) != 0) {
+   if (pci_intr_map_msi(pa, &ih) != 0 && pci_intr_map(pa, &ih) != 0) {
printf(": can't map interrupt\n");
return;
}

-- 
There is no such thing as fortune.  Try again.

Re: Fix page deactivation in uvm_vnode.c when clustering

[Owain Ainsworth]

On Tue, Jun 07, 2011 at 06:51:31PM +0200, Christian Ehrhardt wrote:
> Hi,
> 
> while reading through uvm code I stubled accross a piece of code that
> appears to be buggy. Here's the proposed patch, rational follows:
> 
> Index: uvm_vnode.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
> retrieving revision 1.71
> diff -u -r1.71 uvm_vnode.c
> --- uvm_vnode.c   18 May 2010 04:41:14 -  1.71
> +++ uvm_vnode.c   7 Jun 2011 16:42:15 -
> @@ -924,8 +924,8 @@
>*/
>  
>   if (flags & PGO_DEACTIVATE) {
> - if ((pp->pg_flags & PQ_INACTIVE) == 0 &&
> - pp->wire_count == 0) {
> + if ((ptmp->pg_flags & PQ_INACTIVE) == 0 &&
> + ptmp->wire_count == 0) {
>   pmap_page_protect(ptmp,
VM_PROT_NONE); >
uvm_pagedeactivate(ptmp); >   }

This does look correct to me. In very *very* rare cases where one page was
wired and the other was not (playing with mlock() could cause this
synthetically with luck) this could cause us to hit a KASSERT in 
uvm_pagedeactivate().

Note that the PQ_INACTIVE bit isn't needed (pagedeactivate already
checks that) but the wire count check is still necessary.

Anyone willing to ok this diff? I'll take care of it.

-0-

> 
> This code handles (among other things) write back of dirty pages to disk.
> It calls uvm_pager_put to do the actual IO (one call per page). To improve
> performance, uvm_pager_put is allowed to do IO for adjacent pages as well
> and returns an array of all pages that must be unbusied by the caller
> (uvn_flush).
> 
> The code above is part of the loop that does this. pp is the initial page
> passed to uvm_pager_put and ptmp is the page that we are about to unbusy.
> Thus we should IMHO check the PQ_INACTIVE flag and the wire_count of ptmp
> instead of pp.
> 
-- 
They told me I was gullible ... and I believed them!

iwn(4) MSI

[Owain Ainsworth]

Been running with this for a couple of weeks, seems to work fine.

ok?

diff --git dev/pci/if_iwn.c dev/pci/if_iwn.c
index 16765f4..a54556b 100644
--- dev/pci/if_iwn.c
+++ dev/pci/if_iwn.c
@@ -338,7 +338,8 @@ iwn_attach(struct device *parent, struct device *self, void 
*aux)
}
 
/* Install interrupt handler. */
-   if (pci_intr_map(pa, &ih) != 0) {
+   if (pci_intr_map_msi(pa, &ih) != 0 &&
+   pci_intr_map(pa, &ih) != 0) {
printf(": can't map interrupt\n");
return;
}

-- 
The idea is to die young as late as possible.
-- Ashley Montague

check for correct flag in uvm_page_unbusy

[Owain Ainsworth]

No functional change since aobjs should never hit this path. However, I
introduced this diff when I reworked the page releasing stuff for
objects.

ok?

diff --git uvm/uvm_page.c uvm/uvm_page.c
index 10ef7d1..27e970a 100644
--- uvm/uvm_page.c
+++ uvm/uvm_page.c
@@ -1099,7 +1099,7 @@ uvm_page_unbusy(struct vm_page **pgs, int npgs)
uvm_lock_pageq();
pmap_page_protect(pg, VM_PROT_NONE);
/* XXX won't happen right now */
-   if (pg->pg_flags & PQ_ANON)
+   if (pg->pg_flags & PQ_AOBJ)
uao_dropswap(uobj,
pg->offset >> PAGE_SHIFT);
uvm_pagefree(pg);
-- 
1.7.5


-- 
Blood flows down one leg and up the other.

Move uvm_pglist* to uvm_page.c

[Owain Ainsworth]

These functions used to be big and complicated, now they are glorified
wrappers around pmemrange and don't really need their own file.
Discussed with ariane@ a while ago.

ok?


diff --git conf/files conf/files
index 02da860..017e5f9 100644
--- conf/files
+++ conf/files
@@ -1007,7 +1007,6 @@ file uvm/uvm_object.c
 file uvm/uvm_page.c
 file uvm/uvm_pager.c
 file uvm/uvm_pdaemon.c
-file uvm/uvm_pglist.c
 file uvm/uvm_pmemrange.c
 file uvm/uvm_stat.c
 file uvm/uvm_swap.c
diff --git uvm/uvm_page.c uvm/uvm_page.c
index 10ef7d1..ed8e6d4 100644
--- uvm/uvm_page.c
+++ uvm/uvm_page.c
@@ -806,6 +806,81 @@ uvm_pagealloc_pg(struct vm_page *pg, struct uvm_object 
*obj, voff_t off,
 }
 
 /*
+ * uvm_pglistalloc: allocate a list of pages
+ *
+ * => allocated pages are placed at the tail of rlist.  rlist is
+ *assumed to be properly initialized by caller.
+ * => returns 0 on success or errno on failure
+ * => doesn't take into account clean non-busy pages on inactive list
+ * that could be used(?)
+ * => params:
+ * sizethe size of the allocation, rounded to page size.
+ * low the low address of the allowed allocation range.
+ * highthe high address of the allowed allocation range.
+ * alignment   memory must be aligned to this power-of-two boundary.
+ * boundaryno segment in the allocation may cross this 
+ * power-of-two boundary (relative to zero).
+ * => flags:
+ * UVM_PLA_NOWAIT  fail if allocation fails
+ * UVM_PLA_WAITOK  wait for memory to become avail
+ * UVM_PLA_ZEROreturn zeroed memory
+ */
+int
+uvm_pglistalloc(psize_t size, paddr_t low, paddr_t high, paddr_t alignment,
+paddr_t boundary, struct pglist *rlist, int nsegs, int flags)
+{
+   UVMHIST_FUNC("uvm_pglistalloc"); UVMHIST_CALLED(pghist);
+
+   KASSERT((alignment & (alignment - 1)) == 0);
+   KASSERT((boundary & (boundary - 1)) == 0);
+   KASSERT(!(flags & UVM_PLA_WAITOK) ^ !(flags & UVM_PLA_NOWAIT));
+
+   if (size == 0)
+   return (EINVAL);
+
+   if ((high & PAGE_MASK) != PAGE_MASK) {
+   printf("uvm_pglistalloc: Upper boundary 0x%lx "
+   "not on pagemask.\n", (unsigned long)high);
+   }
+
+   /*
+* Our allocations are always page granularity, so our alignment
+* must be, too.
+*/
+   if (alignment < PAGE_SIZE)
+   alignment = PAGE_SIZE;
+
+   low = atop(roundup(low, alignment));
+   /*
+* high + 1 may result in overflow, in which case high becomes 0x0,
+* which is the 'don't care' value.
+* The only requirement in that case is that low is also 0x0, or the
+* low pages should already be unmapped
+ */
+void
+uvm_pglistfree(struct pglist *list)
+{
+   UVMHIST_FUNC("uvm_pglistfree"); UVMHIST_CALLED(pghist);
+   uvm_pmr_freepageq(list);
+}
+
+/*
  * interface used by the buffer cache to allocate a buffer at a time.
  * The pages are allocated wired in DMA accessible memory
  */
diff --git uvm/uvm_pglist.c uvm/uvm_pglist.c
deleted file mode 100644
index d29fb14..000
--- uvm/uvm_pglist.c
+++ /dev/null
@@ -1,136 +0,0 @@
-/* $OpenBSD$   */
-/* $NetBSD: uvm_pglist.c,v 1.13 2001/02/18 21:19:08 chs Exp $  */
-
-/*-
- * Copyright (c) 1997 The NetBSD Foundation, Inc.
- * All rights reserved.
- *  
- * This code is derived from software contributed to The NetBSD Foundation
- * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
- * NASA Ames Research Center.  
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright 
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *  
- * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
- * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
- * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-/*
- * uvm_pglist.c: pglist functions
- */
-
-#include 
-#include 
-#include 
-#incl

replaced handrolled version of uvmfault_unlockmaps with that function

[Owain Ainsworth]

ok?

diff --git uvm/uvm_fault.c uvm/uvm_fault.c
index 76f0708..76429dc 100644
--- uvm/uvm_fault.c
+++ uvm/uvm_fault.c
@@ -1936,11 +1936,7 @@ uvmfault_lookup(struct uvm_faultinfo *ufi, boolean_t 
write_lock)
 */
if (UVM_ET_ISSUBMAP(ufi->entry)) {
tmpmap = ufi->entry->object.sub_map;
-   if (write_lock) {
-   vm_map_unlock(ufi->map);
-   } else {
-   vm_map_unlock_read(ufi->map);
-   }
+   uvmfault_unlockmaps(ufi, write_lock);
ufi->map = tmpmap;
continue;
}
-- 
1.7.5

-- 
It's easier to fight for one's principles than to live up to them.

Don't bother checking for an empty pageq before freeing the

[Owain Ainsworth]

list
Reply-To: 


It will handle an empty list just fine (there is a potential small
optimisation in there to avoid grabbing the fpageqlock if no pages need
freeing but that is another diff)

ok?

diff --git uvm/uvm_km.c uvm/uvm_km.c
index 1990adf..818cb18 100644
--- uvm/uvm_km.c
+++ uvm/uvm_km.c
@@ -925,8 +925,7 @@ alloc_va:
while (uvm_km_pages.free == 0) {
if (kd->kd_waitok == 0) {
mtx_leave(&uvm_km_pages.mtx);
-   if (!TAILQ_EMPTY(&pgl))
-   uvm_pglistfree(&pgl);
+   uvm_pglistfree(&pgl);
return NULL;
}
msleep(&uvm_km_pages.free, &uvm_km_pages.mtx, PVM,
@@ -959,8 +958,7 @@ try_map:
tsleep(map, PVM, "km_allocva", 0);
goto try_map;
}
-   if (!TAILQ_EMPTY(&pgl))
-   uvm_pglistfree(&pgl);
+   uvm_pglistfree(&pgl);
return (NULL);
}
}
-- 
1.7.5

-- 
Banectomy, n.:
The removal of bruises on a banana.
-- Rich Hall, "Sniglets"

Re: cwm: utf-8 diff

[Owain Ainsworth]

On Fri, May 27, 2011 at 04:28:44PM +0400, Alexander Polakov wrote:
> This diff works for me with some fonts (fixed, snap, even verdana),
> but doesn't work with terminus (black squares instead of chars).

I have been meaning to write this diff for years.

I will try and get to it soon.

Cheers,

-0-
> 
> Index: app/cwm/calmwm.c
> ===
> RCS file: /cvs/xenocara/app/cwm/calmwm.c,v
> retrieving revision 1.54
> diff -u -p -u -r1.54 calmwm.c
> --- app/cwm/calmwm.c  11 May 2011 13:53:51 -  1.54
> +++ app/cwm/calmwm.c  27 May 2011 12:35:51 -
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "calmwm.h"
>  
> @@ -61,6 +62,8 @@ main(int argc, char **argv)
>   const char  *conf_file = NULL;
>   char*display_name = NULL;
>   int  ch;
> +
> + setlocale(LC_CTYPE, "");
>  
>   while ((ch = getopt(argc, argv, "c:d:")) != -1) {
>   switch (ch) {
> Index: app/cwm/font.c
> ===
> RCS file: /cvs/xenocara/app/cwm/font.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 font.c
> --- app/cwm/font.c11 May 2011 13:53:51 -  1.14
> +++ app/cwm/font.c27 May 2011 12:35:51 -
> @@ -66,7 +66,7 @@ font_width(struct screen_ctx *sc, const 
>  {
>   XGlyphInfo   extents;
>  
> - XftTextExtents8(X_Dpy, sc->font, (const XftChar8*)text,
> + XftTextExtentsUtf8(X_Dpy, sc->font, (unsigned char*)text,
>   len, &extents);
>  
>   return (extents.xOff);
> @@ -77,9 +77,8 @@ font_draw(struct screen_ctx *sc, const c
>  Drawable d, int x, int y)
>  {
>   XftDrawChange(sc->xftdraw, d);
> - /* Really needs to be UTF8'd. */
> - XftDrawString8(sc->xftdraw, &sc->xftcolor, sc->font, x, y,
> - (const FcChar8*)text, len);
> + XftDrawStringUtf8(sc->xftdraw, &sc->xftcolor, sc->font, x, y,
> + (const unsigned char*)text, len);
>  }
>  
>  XftFont *
> 
> -- 
> Alexander Polakov | plhk.ru
> 

-- 
When the going gets tough, the tough get empirical
-- Jon Carroll

Re: AVL tree

[Owain Ainsworth]

On Thu, May 19, 2011 at 05:27:01PM +, Thordur Bjornsson wrote:
> On Thu, May 19, 2011 at 07:21:21PM +0200, Mike Belopuhov wrote:
> > On Thu, May 19, 2011 at 7:12 PM, Thordur Bjornsson  wrote:
> > > On Thu, May 19, 2011 at 07:52:44PM +0300, Michael Pounov wrote:
> > >> Add AVL tree implementation and merge few RB tree related macros.
> > >>
> > >> If you have comments or any claims, please send me feedback
> > >> and I will fix them.
> > > cool. but tech@ removes attachments, send your diffs inline.
> > >
> > > I'm assuming you implemented this as a macro a la RB/SPAY in
> > > tree.h;
> > >
> > > That being said, there is already an AVL tree implementation
> > > floating around, that's "not macros".
> > >
> > > I've been beating on it (with some of the RB trees diffs we
> > > have in the kernel switched over) for some time, and hopefully
> > > it will be committable soon.
> > >
> > 
> > what do you need it for? it's pretty much the same as r/b tree.
> > do you think that lookup speed up is considerable?
> > same questions apply to Michael.
> 
> It's not the same as an r/b tree.
> 
> The main reason for it is to cut down on the code bloat that
> the tree.h macros introduce.
> 
> Also, my (limited though, have not done proper networking checks)
> show no performance difference.

The networking code is where the performance differences tend to show up

the theory is still that gcc manages to inline the comparators

-0-
-- 
Some programming languages manage to absorb change, but withstand
progress.
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982

Re: AVL tree

[Owain Ainsworth]

On Thu, May 19, 2011 at 08:16:22PM +0300, Michael Pounov wrote:
> Add AVL tree implementation and merge few RB tree related macros.
> 
> If you have comments or any claims, please send me feedback
> and I will fix them. 
> 
> Include patch file
> 
> -- 
> 
> M.Punov
> -
> AITNET - Sofia/Bulgaria -
> Software & Network Solutions
> (+359) 888 73 73 58;(+359) 2 402 4000
> 
> [demime 1.01d removed an attachment of type text/x-diff which had a name of 
> tree.patch]
> 

Still attached via mime.

put the patch text inline in the mail message please.

-0-
-- 
Do what comes naturally now.  Seethe and fume and throw a tantrum.

Re: AVL tree

[Owain Ainsworth]

On Thu, May 19, 2011 at 07:52:44PM +0300, Michael Pounov wrote:
> Add AVL tree implementation and merge few RB tree related macros.
> 
> If you have comments or any claims, please send me feedback
> and I will fix them. 

First of all, before we get anto any technical discussion etc. please
provide the patch inline in the mail. OpenBSD lists othe than ports@
strip MIME attachments. (This is mentioned on OpenBSD.org/mail.html).

> [demime 1.01d removed an attachment of type text/x-chdr which had a name of 
> tree.h]
> 

Cheers,

-0-
-- 
The porcupine with the sharpest quills gets stuck on a tree more often.

mmuagp driver

[Owain Ainsworth]

Most other OSen name this agp_amd64 or similar, no numbers in device
names here. this is a driver for the early amd64s that had an agp slot
which interfaces with the GART on the cpu.

This has been floating around for probably 3 years now, but never got
commited because it conflicted with the amd64 iommu code. Since that is
dead viva mmuagp.

At least matthieu@, kettenis@ and Tom Murphy have been using this for
periods between several years and a month. Driver comes from free/net
with some heavy reworking to fit out agp subystem by your truly.

No suspend resume bits as of yet, but this has already spent too long
outside the tree.

I've also got a three year old nvidia nforce and nforce 2 driver that i
resurrected from a tech post that i'd forgotten about if anyone can test
it.

ok?

-0-


Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.316
diff -u -p -r1.316 GENERIC
--- arch/amd64/conf/GENERIC 10 Apr 2011 20:27:02 -  1.316
+++ arch/amd64/conf/GENERIC 21 Apr 2011 20:16:45 -
@@ -292,7 +292,10 @@ wskbd* at pckbd? mux 1
 wsmouse*   at pms? mux 0
 
 intagp*at vga? # intel integrated graphics
+mmuagp*at pchb?# amd64 mmu agp.
+
 agp*   at intagp?
+agp*   at mmuagp?
 
 #optionDRM_DEBUG
 inteldrm*  at vga? # Intel i915, i945 DRM driver
Index: arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.713
diff -u -p -r1.713 GENERIC
--- arch/i386/conf/GENERIC  10 Apr 2011 20:27:02 -  1.713
+++ arch/i386/conf/GENERIC  21 Apr 2011 20:16:47 -
@@ -359,6 +359,7 @@ amdagp* at pchb?
 intelagp*  at pchb?
 sisagp*at pchb?
 viaagp*at pchb?
+mmuagp*at pchb?
 
 agp*   at intagp?  # AGP bridges
 agp*   at aliagp?  # AGP bridges
@@ -366,6 +367,7 @@ agp*at amdagp?  # AGP bridges
 agp*   at intelagp?# AGP bridges
 agp*   at sisagp?  # AGP bridges
 agp*   at viaagp?  # AGP bridges
+agp*   at mmuagp?  
 
 #optionDRMDEBUG
 inteldrm*  at vga? # Intel i915, i945 DRM driver
Index: dev/pci/files.agp
===
RCS file: /cvs/src/sys/dev/pci/files.agp,v
retrieving revision 1.3
diff -u -p -r1.3 files.agp
--- dev/pci/files.agp   9 Nov 2008 15:11:19 -   1.3
+++ dev/pci/files.agp   22 Jun 2009 15:45:51 -
@@ -25,6 +25,10 @@ attach   intagp at agpint
 # intelagp needs file to check presence of IGD
 file   dev/pci/agp_i810.c  intagp  needs-flag
 
+device mmuagp: agpdev
+attach mmuagp at agpbus
+file   dev/pci/mmuagp.cmmuagp
+
 device sisagp: agpdev
 attach sisagp at agpbus
 file   dev/pci/agp_sis.c   sisagp
Index: dev/pci/mmuagp.c
===
RCS file: dev/pci/mmuagp.c
diff -N dev/pci/mmuagp.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ dev/pci/mmuagp.c22 Jun 2009 16:00:47 -
@@ -0,0 +1,564 @@
+/*-
+ * Copyright (c) 2004, 2005 Jung-uk Kim 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+/*
+ * AMD64 GART registers
+ */
+#defineAGP_AMD64_APCTRL0x90
+#defineAGP

Re: Remove the freelist member from vm_physseg

[Owain Ainsworth]

On Mon, May 09, 2011 at 10:15:23PM +0100, Owain Ainsworth wrote:
> On Mon, May 09, 2011 at 07:22:01PM +0100, Owain Ainsworth wrote:
> > The new world order of pmemrange makes this data completely redundant
> > (being dealt with by the pmemrange constraints instead). Remove all code
> > that messes with the freelist.
> > 
> > While touching every caller of uvm_page_physload() anyway, add the flags
> > argument to all callers (all but one is 0 and that one already used
> > PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
> > without it.
> > 
> > Should shrink the code a bit, as well.
> > 
> > My machine room is still in a mess, so this has only had the build
> > testing on i386 and amd64. I'd appreciate if people could check the
> > others since it'll be a while before I can get all my machines properly
> > set up.
> > 
> > ok?
> 
> matthew@ kindly pointed out two cases there I had missed the flags
> addition.

So i have verified that this builds on:

alpha
amd64
armish
beagle
hppa
hppa64
i386
landisk
loongson
macppc
octeon
palm
socppc
sparc
sparc64
zaurus

gumstix didn't pass config let alone build but that seems to be a
problem in GENERIC.

So that leaves only the m88k-arch, m68k-arch and vax kernels untested (and
there is no way I can verify them really).

Any comments? ok?

-0-
> 
> diff --git arch/alpha/alpha/machdep.c arch/alpha/alpha/machdep.c
> index 2a5a8de..216a681 100644
> --- arch/alpha/alpha/machdep.c
> +++ arch/alpha/alpha/machdep.c
> @@ -559,7 +559,7 @@ nobootinfo:
>   "0x%lx / 0x%lx\n", pfn0, kernstartpfn);
>  #endif
>   uvm_page_physload(pfn0, kernstartpfn,
> - pfn0, kernstartpfn, VM_FREELIST_DEFAULT);
> + pfn0, kernstartpfn, 0);
>   }
>  #ifdef _PMAP_MAY_USE_PROM_CONSOLE
>   }
> @@ -573,7 +573,7 @@ nobootinfo:
>   "0x%lx / 0x%lx\n", kernendpfn, pfn1);
>  #endif
>   uvm_page_physload(kernendpfn, pfn1,
> - kernendpfn, pfn1, VM_FREELIST_DEFAULT);
> + kernendpfn, pfn1, 0);
>   }
>   } else {
>   /*
> @@ -583,8 +583,7 @@ nobootinfo:
>   printf("Loading cluster %d: 0x%lx / 0x%lx\n", i,
>   pfn0, pfn1);
>  #endif
> - uvm_page_physload(pfn0, pfn1, pfn0, pfn1,
> - VM_FREELIST_DEFAULT);
> + uvm_page_physload(pfn0, pfn1, pfn0, pfn1, 0);
>   }
>  #ifdef _PMAP_MAY_USE_PROM_CONSOLE
>   }
> diff --git arch/alpha/include/vmparam.h arch/alpha/include/vmparam.h
> index 24fb644..5ff1c06 100644
> --- arch/alpha/include/vmparam.h
> +++ arch/alpha/include/vmparam.h
> @@ -125,9 +125,6 @@
>  #define  VM_PHYSSEG_STRATVM_PSTRAT_BSEARCH
>  #define  VM_PHYSSEG_NOADD/* no more after 
> vm_mem_init */
>  
> -#define  VM_NFREELIST1
> -#define  VM_FREELIST_DEFAULT 0
> -
>  /*
>   * pmap-specific data stored in the vm_physmem[] array.
>   */
> diff --git arch/amd64/amd64/machdep.c arch/amd64/amd64/machdep.c
> index 9ca1a7a..bc728a3 100644
> --- arch/amd64/amd64/machdep.c
> +++ arch/amd64/amd64/machdep.c
> @@ -1360,7 +1360,6 @@ init_x86_64(paddr_t first_avail)
>   for (x = 0; x < mem_cluster_cnt; x++) {
>   paddr_t seg_start = mem_clusters[x].start;
>   paddr_t seg_end = seg_start + mem_clusters[x].size;
> - int seg_type;
>  
>   if (seg_start < first_avail) seg_start = first_avail;
>   if (seg_start > seg_end) continue;
> @@ -1368,20 +1367,12 @@ init_x86_64(paddr_t first_avail)
>  
>   physmem += atop(mem_clusters[x].size);
>  
> - /* XXX - Should deal with 4GB boundary */
> - if (seg_start >= (1UL<<32))
> - seg_type = VM_FREELIST_HIGH;
> - else if (seg_end <= 16*1024*1024)
> - seg_type = VM_FREELIST_LOW;
> - else
> - seg_type = VM_FREELIST_DEFAULT;
> -
>  #if DEBUG_MEMLOAD
>   printf("loading 0x%lx-0x%lx (0x%lx-0x%lx)\n",
>   seg_start, seg_end, atop(seg_start), atop(seg_end));
>  #endif
>   uvm_page_physload(atop(seg_start), atop(seg_end),
> - atop(seg_start), atop(seg_end), seg_type);
> + atop(seg_start)

Re: Fan mode management in acpithinkpad(4)

[Owain Ainsworth]

On Sat, May 14, 2011 at 01:37:51AM +0400, Vadim Zhukov wrote:
> On 14 May 2011 c. 01:09:03 Christopher Zimmermann wrote:
> > On 05/13/11 20:56, Alexander Polakov wrote:
> > > * Marco Peereboom  [110512 17:59]:
> > >> On Thu, May 12, 2011 at 03:32:56PM +0200, Christopher Zimmermann wrote:
> > >>> On 05/12/11 14:37, Vadim Zhukov wrote:
> >  Hello all.
> > 
> >  Here is a patch that allows for me to work on other things. :)
> >  Basically, it makes OS choose fan mode instead of firmware. Main
> >  feature here is enabling of "disengadged" mode when temperature
> >  goes critical, picking 80C as a "red line". Now I can fully load
> >  CPU on my X201i - say, "make -j 4" - and it still works instead
> >  of being powering off by acpitz(4).
> > >>
> > >> User space will not be allowed to play.  I don't have a stinkpad so
> > >> I can't test this but I do encourage people to play with this diff
> > >> and report to the list.
> > >
> > > My thinkpad is AMD-powered, so 60 degrees is *normal* for it. With
> > > this diff the fan is always running at max speed, generating lots of
> > > noise.
> >
> > I think the THINKPAD_FANMODE_MAX part could be left out. The normal
> > automatic should be able to set maximum speed at a model specific
> > appropriate temperature. The important part is the disengaged mode,
> > because the automatic regulation of the firmware is not able to set
> > this mode.
> 
> Received your letter just before rebooting new kernel. :)
> New version acts as you say: place fan in disengadged mode on
> critical overheat, and return to automatical firmware management
> when temperature goes back to (more or less) normal.
> 
> I also made temperature and fan mode sensors fill sensor status.
> If anyone objects, I'll make this a separate diff, of course.
> 
> --
>   Best wishes,
> Vadim Zhukov
> 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> 
> 
> + sc->sc_sens[THINKPAD_SENSOR_FANRPM].value = ((hi << 8L) + lo);
> +
> + /* Update fan mode based on max temperature seen */
> + if (maxtmp > THINKPAD_TEMP_OUCH) {
> + mode = THINKPAD_FANMODE_DISENGADGED;
> + desc = "disengadged";
> + ss = SENSOR_S_CRIT;
> + } else {
> + mode = THINKPAD_FANMODE_AUTO;
> + desc = "auto";
> + ss = SENSOR_S_OK;
> + }

No actual comment on the diff right now, but please spell ``disengaged''
correctly.

Cheers,
-0-

> + acpiec_write(sc->sc_ec, THINKPAD_ECOFFSET_FANMODE, 1, &mode);
> + sc->sc_sens[THINKPAD_SENSOR_FANMODE].value = mode;
> + sc->sc_sens[THINKPAD_SENSOR_FANMODE].status = ss;
> + snprintf(sc->sc_sens[THINKPAD_SENSOR_FANMODE].desc,
> + sizeof(sc->sc_sens[THINKPAD_SENSOR_FANMODE]),
> + "fan mode: %s", desc);
>  }
> 
>  void
> 

-- 
And on the seventh day, He exited from append mode.

Re: Remove the freelist member from vm_physseg

[Owain Ainsworth]

On Mon, May 09, 2011 at 07:22:01PM +0100, Owain Ainsworth wrote:
> The new world order of pmemrange makes this data completely redundant
> (being dealt with by the pmemrange constraints instead). Remove all code
> that messes with the freelist.
> 
> While touching every caller of uvm_page_physload() anyway, add the flags
> argument to all callers (all but one is 0 and that one already used
> PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
> without it.
> 
> Should shrink the code a bit, as well.
> 
> My machine room is still in a mess, so this has only had the build
> testing on i386 and amd64. I'd appreciate if people could check the
> others since it'll be a while before I can get all my machines properly
> set up.
> 
> ok?

matthew@ kindly pointed out two cases there I had missed the flags
addition.

diff --git arch/alpha/alpha/machdep.c arch/alpha/alpha/machdep.c
index 2a5a8de..216a681 100644
--- arch/alpha/alpha/machdep.c
+++ arch/alpha/alpha/machdep.c
@@ -559,7 +559,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", pfn0, kernstartpfn);
 #endif
uvm_page_physload(pfn0, kernstartpfn,
-   pfn0, kernstartpfn, VM_FREELIST_DEFAULT);
+   pfn0, kernstartpfn, 0);
}
 #ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
@@ -573,7 +573,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", kernendpfn, pfn1);
 #endif
uvm_page_physload(kernendpfn, pfn1,
-   kernendpfn, pfn1, VM_FREELIST_DEFAULT);
+   kernendpfn, pfn1, 0);
}
} else {
/*
@@ -583,8 +583,7 @@ nobootinfo:
printf("Loading cluster %d: 0x%lx / 0x%lx\n", i,
pfn0, pfn1);
 #endif
-   uvm_page_physload(pfn0, pfn1, pfn0, pfn1,
-   VM_FREELIST_DEFAULT);
+   uvm_page_physload(pfn0, pfn1, pfn0, pfn1, 0);
}
 #ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
diff --git arch/alpha/include/vmparam.h arch/alpha/include/vmparam.h
index 24fb644..5ff1c06 100644
--- arch/alpha/include/vmparam.h
+++ arch/alpha/include/vmparam.h
@@ -125,9 +125,6 @@
 #defineVM_PHYSSEG_STRATVM_PSTRAT_BSEARCH
 #defineVM_PHYSSEG_NOADD/* no more after 
vm_mem_init */
 
-#defineVM_NFREELIST1
-#defineVM_FREELIST_DEFAULT 0
-
 /*
  * pmap-specific data stored in the vm_physmem[] array.
  */
diff --git arch/amd64/amd64/machdep.c arch/amd64/amd64/machdep.c
index 9ca1a7a..bc728a3 100644
--- arch/amd64/amd64/machdep.c
+++ arch/amd64/amd64/machdep.c
@@ -1360,7 +1360,6 @@ init_x86_64(paddr_t first_avail)
for (x = 0; x < mem_cluster_cnt; x++) {
paddr_t seg_start = mem_clusters[x].start;
paddr_t seg_end = seg_start + mem_clusters[x].size;
-   int seg_type;
 
if (seg_start < first_avail) seg_start = first_avail;
if (seg_start > seg_end) continue;
@@ -1368,20 +1367,12 @@ init_x86_64(paddr_t first_avail)
 
physmem += atop(mem_clusters[x].size);
 
-   /* XXX - Should deal with 4GB boundary */
-   if (seg_start >= (1UL<<32))
-   seg_type = VM_FREELIST_HIGH;
-   else if (seg_end <= 16*1024*1024)
-   seg_type = VM_FREELIST_LOW;
-   else
-   seg_type = VM_FREELIST_DEFAULT;
-
 #if DEBUG_MEMLOAD
printf("loading 0x%lx-0x%lx (0x%lx-0x%lx)\n",
seg_start, seg_end, atop(seg_start), atop(seg_end));
 #endif
uvm_page_physload(atop(seg_start), atop(seg_end),
-   atop(seg_start), atop(seg_end), seg_type);
+   atop(seg_start), atop(seg_end), 0);
}
 #if DEBUG_MEMLOAD
printf("avail_start = 0x%lx\n", avail_start);
diff --git arch/amd64/include/vmparam.h arch/amd64/include/vmparam.h
index 494416f..bc22bac 100644
--- arch/amd64/include/vmparam.h
+++ arch/amd64/include/vmparam.h
@@ -110,11 +110,6 @@
 #define VM_PHYSSEG_STRAT   VM_PSTRAT_BIGFIRST
 #define VM_PHYSSEG_NOADD   /* can't add RAM after vm_mem_init */
 
-#defineVM_NFREELIST3
-#defineVM_FREELIST_DEFAULT 0
-#defineVM_FREELIST_LOW 1
-#defineVM_FREELIST_HIGH2
-
 #define __HAVE_VM_PAGE_MD
 struct pv_entry;
 struct vm_page_md {
diff --git arch/armish/armish/armish_machdep.c 
arch/armish/armish/armish_machdep.c
index d8ac7f6..850694f 100644
--- arch/armish/armish/armish_machdep.c
+++ arch/armish/armish/ar

Remove the freelist member from vm_physseg

[Owain Ainsworth]

The new world order of pmemrange makes this data completely redundant
(being dealt with by the pmemrange constraints instead). Remove all code
that messes with the freelist.

While touching every caller of uvm_page_physload() anyway, add the flags
argument to all callers (all but one is 0 and that one already used
PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
without it.

Should shrink the code a bit, as well.

My machine room is still in a mess, so this has only had the build
testing on i386 and amd64. I'd appreciate if people could check the
others since it'll be a while before I can get all my machines properly
set up.

ok?

-0-


diff --git arch/alpha/alpha/machdep.c arch/alpha/alpha/machdep.c
index 2a5a8de..216a681 100644
--- arch/alpha/alpha/machdep.c
+++ arch/alpha/alpha/machdep.c
@@ -559,7 +559,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", pfn0, kernstartpfn);
 #endif
uvm_page_physload(pfn0, kernstartpfn,
-   pfn0, kernstartpfn, VM_FREELIST_DEFAULT);
+   pfn0, kernstartpfn, 0);
}
 #ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
@@ -573,7 +573,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", kernendpfn, pfn1);
 #endif
uvm_page_physload(kernendpfn, pfn1,
-   kernendpfn, pfn1, VM_FREELIST_DEFAULT);
+   kernendpfn, pfn1, 0);
}
} else {
/*
@@ -583,8 +583,7 @@ nobootinfo:
printf("Loading cluster %d: 0x%lx / 0x%lx\n", i,
pfn0, pfn1);
 #endif
-   uvm_page_physload(pfn0, pfn1, pfn0, pfn1,
-   VM_FREELIST_DEFAULT);
+   uvm_page_physload(pfn0, pfn1, pfn0, pfn1, 0);
}
 #ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
diff --git arch/alpha/include/vmparam.h arch/alpha/include/vmparam.h
index 24fb644..5ff1c06 100644
--- arch/alpha/include/vmparam.h
+++ arch/alpha/include/vmparam.h
@@ -125,9 +125,6 @@
 #defineVM_PHYSSEG_STRATVM_PSTRAT_BSEARCH
 #defineVM_PHYSSEG_NOADD/* no more after 
vm_mem_init */
 
-#defineVM_NFREELIST1
-#defineVM_FREELIST_DEFAULT 0
-
 /*
  * pmap-specific data stored in the vm_physmem[] array.
  */
diff --git arch/amd64/amd64/machdep.c arch/amd64/amd64/machdep.c
index 9ca1a7a..bc728a3 100644
--- arch/amd64/amd64/machdep.c
+++ arch/amd64/amd64/machdep.c
@@ -1360,7 +1360,6 @@ init_x86_64(paddr_t first_avail)
for (x = 0; x < mem_cluster_cnt; x++) {
paddr_t seg_start = mem_clusters[x].start;
paddr_t seg_end = seg_start + mem_clusters[x].size;
-   int seg_type;
 
if (seg_start < first_avail) seg_start = first_avail;
if (seg_start > seg_end) continue;
@@ -1368,20 +1367,12 @@ init_x86_64(paddr_t first_avail)
 
physmem += atop(mem_clusters[x].size);
 
-   /* XXX - Should deal with 4GB boundary */
-   if (seg_start >= (1UL<<32))
-   seg_type = VM_FREELIST_HIGH;
-   else if (seg_end <= 16*1024*1024)
-   seg_type = VM_FREELIST_LOW;
-   else
-   seg_type = VM_FREELIST_DEFAULT;
-
 #if DEBUG_MEMLOAD
printf("loading 0x%lx-0x%lx (0x%lx-0x%lx)\n",
seg_start, seg_end, atop(seg_start), atop(seg_end));
 #endif
uvm_page_physload(atop(seg_start), atop(seg_end),
-   atop(seg_start), atop(seg_end), seg_type);
+   atop(seg_start), atop(seg_end), 0);
}
 #if DEBUG_MEMLOAD
printf("avail_start = 0x%lx\n", avail_start);
diff --git arch/amd64/include/vmparam.h arch/amd64/include/vmparam.h
index 494416f..bc22bac 100644
--- arch/amd64/include/vmparam.h
+++ arch/amd64/include/vmparam.h
@@ -110,11 +110,6 @@
 #define VM_PHYSSEG_STRAT   VM_PSTRAT_BIGFIRST
 #define VM_PHYSSEG_NOADD   /* can't add RAM after vm_mem_init */
 
-#defineVM_NFREELIST3
-#defineVM_FREELIST_DEFAULT 0
-#defineVM_FREELIST_LOW 1
-#defineVM_FREELIST_HIGH2
-
 #define __HAVE_VM_PAGE_MD
 struct pv_entry;
 struct vm_page_md {
diff --git arch/armish/armish/armish_machdep.c 
arch/armish/armish/armish_machdep.c
index d8ac7f6..850694f 100644
--- arch/armish/armish/armish_machdep.c
+++ arch/armish/armish/armish_machdep.c
@@ -750,8 +750,7 @@ initarm(void *arg)
 #endif
uvm_setpagesize();  /* initialize PAGE_SIZE-dependent variables */
uvm_page_physload(atop(physical_freestart), atop(physical_freeend),
-   atop(physical_freestart), atop(physical_freeend),
-   VM_FREELIST_DEFAULT);
+   atop(phy

kill the unused vm_page_lookup_freelist()

[Owain Ainsworth]

ok?

-0-

diff --git uvm/uvm_page.c uvm/uvm_page.c
index f1b5d04..10ef7d1 100644
--- uvm/uvm_page.c
+++ uvm/uvm_page.c
@@ -1477,23 +1477,6 @@ uvm_pagecopy(struct vm_page *src, struct vm_page *dst)
 }
 
 /*
- * uvm_page_lookup_freelist: look up the free list for the specified page
- */
-int
-uvm_page_lookup_freelist(struct vm_page *pg)
-{
-#if VM_PHYSSEG_MAX == 1
-   return (vm_physmem[0].free_list);
-#else
-   int lcv;
-
-   lcv = vm_physseg_find(atop(VM_PAGE_TO_PHYS(pg)), NULL);
-   KASSERT(lcv != -1);
-   return (vm_physmem[lcv].free_list);
-#endif
-}
-
-/*
  * uvm_pagecount: count the number of physical pages in the address range.
  */
 psize_t
diff --git uvm/uvm_page.h uvm/uvm_page.h
index 3acbfd1..e131424 100644
--- uvm/uvm_page.h
+++ uvm/uvm_page.h
@@ -256,8 +256,6 @@ voiduvm_pagealloc_pg(struct vm_page *, 
struct uvm_object *,
 struct uvm_constraint_range; /* XXX move to uvm_extern.h? */
 psize_tuvm_pagecount(struct uvm_constraint_range*);
 
-intuvm_page_lookup_freelist(struct vm_page *);
-
 #if  VM_PHYSSEG_MAX == 1
 /*
  * Inline functions for archs like the vax where function calls are expensive.


-- 
Harris's Lament:
All the good ones are taken.

Re: sudoers, add ENV to env_keep?

[Owain Ainsworth]

On Fri, May 06, 2011 at 12:46:40PM +0200, Claudio Jeker wrote:
> On Fri, May 06, 2011 at 11:37:53AM +0100, Stuart Henderson wrote:
> > sudo doesn't preserve ENV by default, so any shell settings (e.g.
> > set -o emacs) you might have in your ${ENV} file don't take effect.
> > 
> > for people who like EDITOR=vi but also like "set -o emacs" in the
> > shell, this is really annoying; EDITOR/VISUAL are preserved, so the
> > (imo horrible) /bin/ksh "feature" of changing line editing mode
> > depending on setting of these variables takes priority.
> > 
> > I'm not entirely convinced it's safe to add ENV to env_keep by
> > default but the only other workaround I've found (i.e. ln -s
> > /usr/bin/{vi,not_emacs} and setting VISUAL=/usr/bin/not_emacs)
> > is messy and annoying to do on multiple machines.
> > 
> > anyone have other ideas or comments?
> 
> I'm all for killing the ksh autoswitch feature. Whenever I end up on a
> system with EDITOR set to vi and ksh as shell I'm lost. If people like to
> use a specific mode they should add it to .profile. 

I would somehow cope if it was removed, but I really like that feature
(which got added to tmux, too).

-0-
-- 
What this country needs is a good five cent ANYTHING!

Re: tunefs(8) don't need no stinkin' opendisk(3). And wants DUIDs!

[Owain Ainsworth]

On Wed, May 04, 2011 at 11:59:52PM -0400, Kenneth R Westerback wrote:
> And by using opendev(3) tunefs can accept disk UID's.
> 
> Any actual tunefs(8) guru's out there who can explain what this
> might break?
> 
> Inspired by oga@'s work on atactl.

millert already provided a diff for that, the the getpartition dance is
necessary if you want to be able to provide partition names from fstab
(say tunefs -N /home). This diff breaks that ability.

The diff is appended here for completeness (from millert, not me)

> 
> This is the last use of opendisk(3) in the tree. Any reason to
> keep it if this goes in? ports?

I have no idea, but a porter should probably check the distfiles.

-0-

Index: tunefs.c
===
RCS file: /cvs/src/sbin/tunefs/tunefs.c,v
retrieving revision 1.30
diff -u -p -r1.30 tunefs.c
--- tunefs.c27 Oct 2009 23:59:34 -  1.30
+++ tunefs.c4 May 2011 18:30:33 -
@@ -71,7 +71,7 @@ staticvoidbwrite(daddr64_t, char *, in
 static voidbread(daddr64_t, char *, int, const char *);
 static int getnum(const char *, const char *, int, int);
 static voidgetsb(struct fs *, const char *);
-static int openpartition(const char *, int, char *, size_t);
+static int openpartition(char *, int, char **);
 static voidusage(void);
 
 int
@@ -79,8 +79,8 @@ main(int argc, char *argv[])
 {
 #defineOPTSTRING   "AFNe:g:h:m:o:"
int i, ch, Aflag, Fflag, Nflag, openflags;
-   const char  *special, *chg[2];
-   chardevice[MAXPATHLEN];
+   char*special;
+   const char  *chg[2];
int maxbpg, minfree, optim;
int avgfilesize, avgfpdir;
 
@@ -151,10 +151,8 @@ main(int argc, char *argv[])
openflags = Nflag ? O_RDONLY : O_RDWR;
if (Fflag)
fi = open(special, openflags);
-   else {
-   fi = openpartition(special, openflags, device, sizeof(device));
-   special = device;
-   }
+   else
+   fi = openpartition(special, openflags, &special);
if (fi == -1)
err(1, "%s", special);
getsb(&sblock, special);
@@ -319,11 +317,11 @@ bread(daddr64_t blk, char *buffer, int c
 }
 
 static int
-openpartition(const char *name, int flags, char *device, size_t devicelen)
+openpartition(char *name, int flags, char **devicep)
 {
charrawspec[MAXPATHLEN], *p;
struct fstab*fs;
-   int fd, oerrno;
+   int fd;
 
fs = getfsfile(name);
if (fs) {
@@ -334,11 +332,8 @@ openpartition(const char *name, int flag
} else
name = fs->fs_spec;
}
-   fd = opendisk(name, flags, device, devicelen, 0);
-   if (fd == -1 && errno == ENOENT) {
-   oerrno = errno;
-   strlcpy(device, name, devicelen);
-   errno = oerrno;
-   }
+   fd = opendev(name, flags, 0, devicep);
+   if (fd == -1 && errno == ENOENT)
+   devicep = &name;
return (fd);
 }

-- 
I fell asleep reading a dull book, and I dreamt that I was reading on,
so I woke up from sheer boredom.

so long, uvm_pglist.h

[Owain Ainsworth]

uvm_pglist.h defines 3 things. two of whch are unused (ok, used in if0ed
out code for page idle zeroing that needs completely rewriting because
the code doesn't work like that anymore). The third thing is the
defintion of struct pglist (a TAILQ_HEAD).

Move that definiton to uvm_page.h with the definition of struct vm_page
and nuke the otherwise tiny header.

Please note that the hppa pmap.h inclusion of this header doesn't seem
to be needed but I have no way to check other than manual inspection.
I'd like confirmation that it still builds (else it needs uvm_page.h
incuding). i386 I have checked and hppa64 needs the struct pglist
definition.

ok?

-0-


Index: arch/hppa/include/pmap.h
===
RCS file: /cvs/src/sys/arch/hppa/include/pmap.h,v
retrieving revision 1.41
diff -u -p -r1.41 pmap.h
--- arch/hppa/include/pmap.h28 Apr 2011 20:42:28 -  1.41
+++ arch/hppa/include/pmap.h4 May 2011 22:08:04 -
@@ -30,7 +30,6 @@
 #define _MACHINE_PMAP_H_
 
 #include 
-#include 
 #include 
 
 #ifdef _KERNEL
Index: arch/hppa64/include/pmap.h
===
RCS file: /cvs/src/sys/arch/hppa64/include/pmap.h,v
retrieving revision 1.5
diff -u -p -r1.5 pmap.h
--- arch/hppa64/include/pmap.h  28 Apr 2011 20:43:41 -  1.5
+++ arch/hppa64/include/pmap.h  4 May 2011 22:08:42 -
@@ -21,7 +21,7 @@
 #define _MACHINE_PMAP_H_
 
 #include 
-#include 
+#include 
 #include 
 
 struct pmap {
Index: arch/i386/include/pmap.h
===
RCS file: /cvs/src/sys/arch/i386/include/pmap.h,v
retrieving revision 1.57
diff -u -p -r1.57 pmap.h
--- arch/i386/include/pmap.h23 Mar 2011 16:54:35 -  1.57
+++ arch/i386/include/pmap.h4 May 2011 22:09:06 -
@@ -43,7 +43,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
Index: uvm/uvm_page.h
===
RCS file: /cvs/src/sys/uvm/uvm_page.h,v
retrieving revision 1.45
diff -u -p -r1.45 uvm_page.h
--- uvm/uvm_page.h  2 Apr 2011 12:38:37 -   1.45
+++ uvm/uvm_page.h  4 May 2011 21:55:29 -
@@ -96,7 +96,8 @@
  */
 
 #include 
-#include 
+
+TAILQ_HEAD(pglist, vm_page);
 
 struct vm_page {
TAILQ_ENTRY(vm_page)pageq;  /* queue info for FIFO
Index: uvm/uvm_pglist.h
===
RCS file: uvm/uvm_pglist.h
diff -N uvm/uvm_pglist.h
--- uvm/uvm_pglist.h26 Jun 2008 05:42:20 -  1.6
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,54 +0,0 @@
-/* $OpenBSD: uvm_pglist.h,v 1.6 2008/06/26 05:42:20 ray Exp $  */
-/* $NetBSD: uvm_pglist.h,v 1.3 2001/05/02 01:22:20 thorpej Exp $   */
-
-/*-
- * Copyright (c) 2000, 2001 The NetBSD Foundation, Inc.
- * All rights reserved.
- *
- * This code is derived from software contributed to The NetBSD Foundation
- * by Jason R. Thorpe.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
- * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
- * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef _PGLIST_H_
-#define _PGLIST_H_
-
-/*
- * This defines the type of a page queue, e.g. active list, inactive
- * list, etc.
- */
-TAILQ_HEAD(pglist, vm_page);
-
-/*
- * A page free list consists of free pages of unknown contents and free
- * pages of all zeros.
- */
-#definePGFL_UNKNOWN0
-#definePGFL_ZEROS  1
-#definePGFL_NQUEUES2
-
-struct pgfreelist {
-   struct pglist pgfl_queues[PGFL_NQUEUES];
-};
-
-#endif
-- 
Chef, n.:
Any cook who swears in French.

save a little space in uvm aobjs

[Owain Ainsworth]

For storing swapslots aobj's select between a hashtable or an array
(sizes vary between a page and the kernel address space), by definition
we only need one of those, so make it a union and possibly shave some
bytes.

ok?

been running with this for a while, I hit swap daily and my machine
allocs a lot of uaos.

-0-


Index: uvm_aobj.c
===
RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
retrieving revision 1.51
diff -u -p -r1.51 uvm_aobj.c
--- uvm_aobj.c  2 Jul 2010 02:08:53 -   1.51
+++ uvm_aobj.c  27 Apr 2011 12:37:35 -
@@ -147,12 +147,16 @@ struct uvm_aobj {
struct uvm_object u_obj; /* has: lock, pgops, memt, #pages, #refs */
int u_pages; /* number of pages in entire object */
int u_flags; /* the flags (see uvm_aobj.h) */
-   int *u_swslots;  /* array of offset->swapslot mappings */
-/*
- * hashtable of offset->swapslot mappings
- * (u_swhash is an array of bucket heads)
- */
-   struct uao_swhash *u_swhash;
+   /*
+* Either an array or hashtable (array of bucket heads) of
+* offset -> swapslot mappings for the aobj.
+*/
+#define u_swslots  u_swap.slot_array 
+#define u_swhash   u_swap.slot_hash
+   union swslots {
+   int *slot_array;
+   struct uao_swhash   *slot_hash;
+   } u_swap;
u_long u_swhashmask;/* mask for hashtable */
LIST_ENTRY(uvm_aobj) u_list;/* global list of aobjs */
 };
 
 
-- 
I used to work in a fire hydrant factory.  You couldn't park anywhere
near the place.
-- Steven Wright

Re: Remove and clean up callers of pmap_clear_reference and pmap_page_protect

[Owain Ainsworth]

On Fri, Apr 15, 2011 at 05:15:02PM +0100, Owain Ainsworth wrote:
> audit callers of pmap_clear_reference() and
> pmap_page_protect(,,VM_PROT_NONE) just before uvm_pagedeactivate noting
> the fact that freshly deactivated pages have their reference cleared in
> uvm_pagedeactivate already.
> 
> first off, clear_reference:
> 
> uvm_anon.c -> only called on swapoff. we don't really require the reference
> cleared if it has been accessed. doesn't matter. and if it was just swapped in
> then the page won't be deactivated and it'll be freshly cleared again. Now I
> come to think about it, though deactivating something we just swapped in is
> wrong, since it isn't swapped out and has no backing store. deactivated pages
> mean we can dump them at will. 
> 
> uvm_aobj.c exactly the same situation as above.
> 
> uvm_fault.c -> deactivating anons due to MADV. so either it is already
> deactivated and will have reference cleared, or is already deactivated and 
> has been
> referenced since, so the advice is bullshit anyway, or it is active and will 
> be
> cleared. (also only for UBC anyway, so this discussion was somewhat
> redundant)
> 
> uvm_map.c -> only for ubc 
> 
> remove all of those redundant calls. The UBC stuff is useless now
> anyway.
> 
> with pmap_page_protect, every caller of uvm_pagedeactivate first calls
> pmap_page_protect. This is techinically incorrect, but done due to pmap
> bugs.  move the page protect call into uvm_pagedeactivate itself and
> detail with an XXX comment why this is done.
> 
> The page_protect part of this diff was commited by art a few years ago
> and backed out as part of the big uvm backout and never reinstated.
> 
> ok?

Still looking for feedback on this diff.

> 
> -0-
> 
> Index: uvm/uvm_anon.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_anon.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 uvm_anon.c
> --- uvm/uvm_anon.c16 Jun 2009 23:54:57 -  1.34
> +++ uvm/uvm_anon.c1 Apr 2011 20:57:25 -
> @@ -351,8 +351,6 @@ uvm_anon_pagein(struct vm_anon *anon)
>* deactivate the page (to put it on a page queue)
>*/
>  
> - pmap_clear_reference(pg);
> - pmap_page_protect(pg, VM_PROT_NONE);
>   uvm_lock_pageq();
>   uvm_pagedeactivate(pg);
>   uvm_unlock_pageq();
> Index: uvm/uvm_aobj.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 uvm_aobj.c
> --- uvm/uvm_aobj.c2 Jul 2010 02:08:53 -   1.51
> +++ uvm/uvm_aobj.c1 Apr 2011 21:10:23 -
> @@ -783,10 +783,6 @@ uao_flush(struct uvm_object *uobj, voff_
>   continue;
>  
>   uvm_lock_pageq();
> - /* zap all mappings for the page. */
> - pmap_page_protect(pp, VM_PROT_NONE);
> -
> - /* ...and deactivate the page. */
>   uvm_pagedeactivate(pp);
>   uvm_unlock_pageq();
>  
> @@ -1364,10 +1360,6 @@ uao_pagein_page(struct uvm_aobj *aobj, i
>   /*
>* deactivate the page (to put it on a page queue).
>*/
> - pmap_clear_reference(pg);
> -#ifndef UBC
> - pmap_page_protect(pg, VM_PROT_NONE);
> -#endif
>   uvm_lock_pageq();
>   uvm_pagedeactivate(pg);
>   uvm_unlock_pageq();
> Index: uvm/uvm_fault.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_fault.c,v
> retrieving revision 1.58
> diff -u -p -r1.58 uvm_fault.c
> --- uvm/uvm_fault.c   22 Jul 2009 21:05:37 -  1.58
> +++ uvm/uvm_fault.c   1 Apr 2011 21:00:12 -
> @@ -202,14 +202,8 @@ uvmfault_anonflush(struct vm_anon **anon
>   pg = anons[lcv]->an_page;
>   if (pg && (pg->pg_flags & PG_BUSY) == 0 && pg->loan_count == 0) 
> {
>   uvm_lock_pageq();
> - if (pg->wire_count == 0) {
> -#ifdef UBC
> - pmap_clear_reference(pg);
> -#else
> - pmap_page_protect(pg, VM_PROT_NONE);
> -#endif
> + if (pg->wire_count == 0)
>   uvm_pagedeactivate(pg);
> - }
>   uvm_unlock_pageq();
>   }
>   simple_unlock(&anons[lcv]->an_lock);
> Index: uvm/uvm_map.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_map

Fix a swap space leak for kernel memory

[Owain Ainsworth]

This is becoming less of a problem recently due to km_alloc (which
doesn't put stuff in the kernel object) but is still an issue.

on free of va space (and backing pages) that was allocated into the
kernel object we would hit a problem if a page was swapped out (this is
generally only pipebuffers). In that case we would not free the
swapslot.

I have seen panics before where nswpgsonly and nswpgs were different
(one bigger than should be possible) this is quite possibly. why.

ariane@ has already eyeballed this, and i've been running with it for a
couple of weeks (I do hit swap).

ok?

-0-


Index: uvm_aobj.c
===
RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
retrieving revision 1.51
diff -u -p -r1.51 uvm_aobj.c
--- uvm_aobj.c  2 Jul 2010 02:08:53 -   1.51
+++ uvm_aobj.c  27 Apr 2011 12:37:35 -
@@ -1135,7 +1139,7 @@ uao_get(struct uvm_object *uobj, voff_t 
  * => aobj must be locked or have a reference count of 0.
  */
 
-void
+int
 uao_dropswap(struct uvm_object *uobj, int pageidx)
 {
int slot;
@@ -1144,6 +1148,7 @@ uao_dropswap(struct uvm_object *uobj, in
if (slot) {
uvm_swap_free(slot, 1);
}
+   return (slot);
 }
 
 
Index: uvm_aobj.h
===
RCS file: /cvs/src/sys/uvm/uvm_aobj.h,v
retrieving revision 1.12
diff -u -p -r1.12 uvm_aobj.h
--- uvm_aobj.h  22 Jul 2009 21:05:37 -  1.12
+++ uvm_aobj.h  27 Apr 2011 12:35:41 -
@@ -65,7 +65,7 @@
 
 void uao_init(void);
 int uao_set_swslot(struct uvm_object *, int, int);
-void uao_dropswap(struct uvm_object *, int);
+int uao_dropswap(struct uvm_object *, int);
 int uao_swap_off(int, int);
 
 /*
Index: uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.100
diff -u -p -r1.100 uvm_km.c
--- uvm_km.c23 Apr 2011 17:48:48 -  1.100
+++ uvm_km.c27 Apr 2011 12:40:36 -
@@ -267,36 +267,33 @@ uvm_km_pgremove(struct uvm_object *uobj,
 {
struct vm_page *pp;
voff_t curoff;
+   int slot;
UVMHIST_FUNC("uvm_km_pgremove"); UVMHIST_CALLED(maphist);
 
KASSERT(uobj->pgops == &aobj_pager);
 
for (curoff = start ; curoff < end ; curoff += PAGE_SIZE) {
pp = uvm_pagelookup(uobj, curoff);
-   if (pp == NULL)
-   continue;
-
-   UVMHIST_LOG(maphist,"  page %p, busy=%ld", pp,
-   pp->pg_flags & PG_BUSY, 0, 0);
-
-   if (pp->pg_flags & PG_BUSY) {
+   if (pp && pp->pg_flags & PG_BUSY) {
atomic_setbits_int(&pp->pg_flags, PG_WANTED);
UVM_UNLOCK_AND_WAIT(pp, &uobj->vmobjlock, 0,
"km_pgrm", 0);
simple_lock(&uobj->vmobjlock);
curoff -= PAGE_SIZE; /* loop back to us */
continue;
-   } else {
-   /* free the swap slot... */
-   uao_dropswap(uobj, curoff >> PAGE_SHIFT);
+   }
+
+   /* free the swap slot, then the page */
+   slot = uao_dropswap(uobj, curoff >> PAGE_SHIFT);
 
-   /*
-* ...and free the page; note it may be on the
-* active or inactive queues.
-*/
+   if (pp != NULL) {
uvm_lock_pageq();
uvm_pagefree(pp);
uvm_unlock_pageq();
+   } else if (slot != 0) {
+   simple_lock(&uvm.swap_data_lock);
+   uvmexp.swpgonly--;
+   simple_unlock(&uvm.swap_data_lock);
}
}
 }
-- 
First Law of Socio-Genetics:
Celibacy is not hereditary.

make atactl grok DUIDs.

[Owain Ainsworth]

millert@ wrote a diff earlier for scanffs, so that leaves atactl as the
only opendisk() caller in the tree. With this diff, the following works:

# atactl b9b455bd99e393cd

Model: C300-CTFDDAC256MAG, Rev: 0001, Serial #: 1015C860
Device type: ATA, fixed
Cylinders: 16383, heads: 16, sec/track: 63, total sectors: 500118192
Device capabilities:
ATA standby timer values
IORDY operation
IORDY disabling
Device supports the following standards:
ATA-4 ATA-5 ATA-6 ATA-7 ATA-8 
Device supports the following command sets:
NOP command
READ BUFFER command
WRITE BUFFER command
Host Protected Area feature set
Read look-ahead
Write cache
Power Management feature set
Security Mode feature set
SMART feature set
Flush Cache Ext command
Flush Cache command
Device Configuration Overlay feature set
48bit address feature set
Set Max security extension commands
Power-up in standby feature set
Advanced Power Management feature set
DOWNLOAD MICROCODE command
IDLE IMMEDIATE with UNLOAD FEATURE
SMART self-test
SMART error logging
Device has enabled the following command sets/features:
NOP command
READ BUFFER command
WRITE BUFFER command
Host Protected Area feature set
Read look-ahead
Write cache
Power Management feature set
SMART feature set
Flush Cache Ext command
Flush Cache command
Device Configuration Overlay feature set
48bit address feature set
DOWNLOAD MICROCODE command

To my testing normal usage still works.

ok?

-0-

Index: sbin/atactl/atactl.c
===
RCS file: /cvs/src/sbin/atactl/atactl.c,v
retrieving revision 1.43
diff -u -p -r1.43 atactl.c
--- sbin/atactl/atactl.c6 Apr 2011 11:36:25 -   1.43
+++ sbin/atactl/atactl.c4 May 2011 19:45:53 -
@@ -355,7 +355,6 @@ int
 main(int argc, char *argv[])
 {
struct command  *cmdp;
-   char dvname_store[MAXPATHLEN];
 
if (argc < 2)
usage();
@@ -363,23 +362,8 @@ main(int argc, char *argv[])
/*
 * Open the device
 */
-   fd = opendisk(argv[1], O_RDWR, dvname_store, sizeof(dvname_store), 0);
-   if (fd == -1) {
-   if (errno == ENOENT) {
-   /*
-* Device doesn't exist.  Probably trying to open
-* a device which doesn't use disk semantics for
-* device name.  Try again, specifying "cooked",
-* which leaves off the "r" in front of the device's
-* name.
-*/
-   fd = opendisk(argv[1], O_RDWR, dvname_store,
-   sizeof(dvname_store), 1);
-   if (fd == -1)
-   err(1, "%s", argv[1]);
-   } else
-   err(1, "%s", argv[1]);
-   }
+   if ((fd = opendev(argv[1], O_RDWR, OPENDEV_PART, NULL)) == -1)
+   err(1, "%s", argv[1]);
 
/* Skip program name and device name. */
if (argc != 2) {
-- 
Jone's Motto:
Friends come and go, but enemies accumulate.

Support for OpenGL on r600/r700. Testing required.

[Owain Ainsworth]

The following diff provides the kernel support necessary for OpenGL to
work on R600 and R700 radeon chipsets.

One caveat: the drm doesn't have interrupt support yet (this
involves another firmware (making 3 per chipset for r600+) and a rather
funky ringbuffer for interrupt events (yes, this is strange). Apparently
interrupt support should not be needed.

In practise it should be possible to write interrupt support as well,
but that will take more time and may well get fiddly fast. So, for the
time being, if you pkg_add driconf and change the following two options
then it will work ok:

Method to limit rendering latency -> busy waiting for the graphics
hardware

Synchronization with vertical refresh -> never.

To test this patch you need the bits I commited just before sending this
message (if your system has libdrm_radeon then you're off to a good
start). then do the following two things:

# cd /usr/xenocara/lib/libGL/dri/r600;
# cd ../../
# make obj
# make build

then:

# cd /usr/src/sys/dev/pci/drm
# patch < path_to_patch_from_this_email

and build your kernel as normal.

tested on i386 my matthieu@ on a radeon 3650 and myself on amd64 with a
HD4870. For me at least foobillard, openarena, gears, crack-attack and
glsfcave all worked fine.

Please note that this driver isnt' as amazingly performant as it could
be. the faster stuff is based on the kms code which I still need to find
a large period of time to sit down and write.

And before anyone asks: no I can't update the current in-tree radeon
driver yet. The problem with zaphod mode dual head being utterly hosed
on some ATOMBios cards with the newer driver is still there and having
wasted hours on it I still have no idea. Anyone who needs the newer
driver to get their card to work can mail me privately if they can't
manage to get a newer driver working themselves.

test reports to myself and matthieu please.

Cheers,

-0-

Index: files.drm
===
RCS file: /cvs/src/sys/dev/pci/drm/files.drm,v
retrieving revision 1.20
diff -u -p -r1.20 files.drm
--- files.drm   25 May 2010 17:15:49 -  1.20
+++ files.drm   1 May 2011 19:03:57 -
@@ -26,6 +26,7 @@ file  dev/pci/drm/r300_cmdbuf.c   radeondrm
 file   dev/pci/drm/r600_blit.c radeondrm
 file   dev/pci/drm/r600_blit_shaders.c radeondrm
 file   dev/pci/drm/radeon_cp.c radeondrm
+file   dev/pci/drm/radeon_cs.c radeondrm
 file   dev/pci/drm/radeon_drv.cradeondrm
 file   dev/pci/drm/radeon_irq.cradeondrm
 file   dev/pci/drm/radeon_mem.cradeondrm
Index: r600_blit.c
===
RCS file: /cvs/src/sys/dev/pci/drm/r600_blit.c,v
retrieving revision 1.1
diff -u -p -r1.1 r600_blit.c
--- r600_blit.c 27 Mar 2010 00:09:50 -  1.1
+++ r600_blit.c 1 May 2011 19:03:57 -
@@ -128,7 +128,7 @@ set_shaders(struct drm_device *dev)
 {
drm_radeon_private_t *dev_priv = dev->dev_private;
u64 gpu_addr;
-   int shader_size, i;
+   int i;
u32 *vs, *ps;
uint32_t sq_pgm_resources;
DRM_DEBUG("\n");
@@ -137,12 +137,10 @@ set_shaders(struct drm_device *dev)
vs = (u32 *) ((char *)dev->agp_buffer_map->handle + 
dev_priv->blit_vb->offset);
ps = (u32 *) ((char *)dev->agp_buffer_map->handle + 
dev_priv->blit_vb->offset + 256);
 
-   shader_size = r6xx_vs_size;
-   for (i = 0; i < shader_size; i++)
-   vs[i] = r6xx_vs[i];
-   shader_size = r6xx_ps_size;
-   for (i = 0; i < shader_size; i++)
-   ps[i] = r6xx_ps[i];
+   for (i = 0; i < r6xx_vs_size; i++)
+   vs[i] = cpu_to_le32(r6xx_vs[i]);
+   for (i = 0; i < r6xx_ps_size; i++)
+   ps[i] = cpu_to_le32(r6xx_ps[i]);
 
dev_priv->blit_vb->used = 512;
 
@@ -194,6 +192,9 @@ set_vtx_resource(drm_radeon_private_t *d
DRM_DEBUG("\n");
 
sq_vtx_constant_word2 = (((gpu_addr >> 32) & 0xff) | (16 << 8));
+#ifdef __BIG_ENDIAN
+   sq_vtx_constant_word2 |= (2 << 30);
+#endif
 
BEGIN_RING(9);
OUT_RING(CP_PACKET3(R600_IT_SET_RESOURCE, 7));
@@ -290,7 +291,11 @@ draw_auto(drm_radeon_private_t *dev_priv
OUT_RING(DI_PT_RECTLIST);
 
OUT_RING(CP_PACKET3(R600_IT_INDEX_TYPE, 0));
+#ifdef __BIG_ENDIAN
+   OUT_RING((2 << 2) | DI_INDEX_SIZE_16_BIT);
+#else
OUT_RING(DI_INDEX_SIZE_16_BIT);
+#endif
 
OUT_RING(CP_PACKET3(R600_IT_NUM_INSTANCES, 0));
OUT_RING(1);
@@ -306,7 +311,7 @@ draw_auto(drm_radeon_private_t *dev_priv
 static inline void
 set_default_state(drm_radeon_private_t *dev_priv)
 {
-   int default_state_dw, i;
+   int i;
u32 sq_config, sq_gpr_resource_mgmt_1, sq_gpr_resource_mgmt_2;
u32 sq_thread_resource_mgmt, sq_stack_resource_mgmt_1, 
sq_stack_resource_mgmt_2;
int num_ps_gprs, num_vs_gprs, num_temp_gprs, num_gs_gprs, num_es_gprs;
@@ -458,14 +463,12 @@ set_default_state(drm_radeon_p

Re: Radeon HD3000

[Owain Ainsworth]

On Sun, Apr 03, 2011 at 10:47:15PM +0100, Pedro la Peu wrote:
> Indeed, thanks Brad.
> 
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1592
> diff -u -p -r1.1592 pcidevs
> --- sys/dev/pci/pcidevs 23 Mar 2011 21:55:09 -  1.1592
> +++ sys/dev/pci/pcidevs 3 Apr 2011 21:41:11 -
> @@ -1359,6 +1359,7 @@ product ATI RADEON_HD3200_1   0x9610  Radeo
>  product ATI RADEON_HD3100  0x9611  Radeon HD 3100
>  product ATI RADEON_HD3200_20x9612  Radeon HD 3200
>  product ATI RADEON_HD3300  0x9614  Radeon HD 3300
> +product ATI RADEON_HD3000  0x9616  Radeon HD 3000
>  product ATI RADEON_HD4200_HDA  0x970f  Radeon HD 4200 HD Audio
>  product ATI RADEON_HD4200  0x9710  Radeon HD 4200
>  product ATI RADEON_HD4200_M0x9712  Mobility Radeon HD 4200
> 
> Index: sys/dev/pci/drm/radeon_drv.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 radeon_drv.c
> --- sys/dev/pci/drm/radeon_drv.c29 Sep 2010 13:32:22 -  1.51
> +++ sys/dev/pci/drm/radeon_drv.c3 Apr 2011 21:41:11 -
> @@ -500,6 +500,8 @@ const static struct drm_pcidev radeondrm
> CHIP_RV635|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
> {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3850,
> CHIP_RV670|RADEON_NEW_MEMMAP},
> +   {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3000,
> +CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
> {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3200_1,
> CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
> {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3200_2,

You even got the flags right.


Commited, thanks Pedro! Sorry it took me so long

-0-
-- 
WARNING TO ALL PERSONNEL:

Firings will continue until morale improves.

Re: du.c tree use

[Owain Ainsworth]

On Sun, May 01, 2011 at 04:21:27PM +0200, Ariane van der Steldt wrote:
> Hi,
> 
> du.c doesn't define its tree prototypes. However, if I understand man tree,
> it should.

The idea being that you're defining the rb functions without first
prototyping them

in this case RB_GENERATE_STATIC would probably be better since it is
only needed within the one file.

> 
> Ok?
> -- 
> Ariane
> 
> 
> Index: du.c
> ===
> RCS file: /cvs/src/usr.bin/du/du.c,v
> retrieving revision 1.23
> diff -u -d -p -r1.23 du.c
> --- du.c  27 Apr 2011 07:52:11 -  1.23
> +++ du.c  1 May 2011 14:10:13 -
> @@ -232,6 +232,7 @@ links_cmp(struct links_entry *e1, struct
>  
>  RB_HEAD(ltree, links_entry) links = RB_INITIALIZER(&links);
>  
> +RB_PROTOTYPE(ltree, links_entry, entry, links_cmp);
>  RB_GENERATE(ltree, links_entry, entry, links_cmp);
> 

-- 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.

Re: pmap hole handling

[Owain Ainsworth]

On Thu, Apr 21, 2011 at 01:38:35AM +0200, Ariane van der Steldt wrote:
> Hi,
> 
> MMU address space holes are at a fixed position (ofcourse).
> This diff makes sure the FIXED position flag is specified when mapping
> them in and complains loudly otherwise.
> 
> While there, check some other flag mistakes (which don't happen in the
> kernel).
> 
> This diff prepares for the vmmap replacement I wrote, but is correct
> regardless.
> 
> Ok?
> -- 
> Ariane
> 
> 
> Index: arch/sparc/sparc/pmap.c
> ===
> RCS file: /cvs/src/sys/arch/sparc/sparc/pmap.c,v
> retrieving revision 1.158
> diff -u -d -p -r1.158 pmap.c
> --- arch/sparc/sparc/pmap.c   6 Dec 2010 20:57:18 -   1.158
> +++ arch/sparc/sparc/pmap.c   20 Apr 2011 23:34:10 -
> @@ -6275,7 +6275,8 @@ pmap_remove_holes(struct vm_map *map)
>   (void)uvm_map(map, &shole, ehole - shole, NULL,
>   UVM_UNKNOWN_OFFSET, 0,
>   UVM_MAPFLAG(UVM_PROT_NONE, UVM_PROT_NONE, UVM_INH_NONE,
> -   UVM_ADV_RANDOM, UVM_FLAG_NOMERGE | UVM_FLAG_HOLE));
> +   UVM_ADV_RANDOM,
> +   UVM_FLAG_NOMERGE | UVM_FLAG_HOLE | UVM_FLAG_FIXED));
>   }
>  #endif
>  }
> Index: arch/sparc64/sparc64/pmap.c
> ===
> RCS file: /cvs/src/sys/arch/sparc64/sparc64/pmap.c,v
> retrieving revision 1.72
> diff -u -d -p -r1.72 pmap.c
> --- arch/sparc64/sparc64/pmap.c   7 Apr 2011 15:30:16 -   1.72
> +++ arch/sparc64/sparc64/pmap.c   20 Apr 2011 23:34:12 -
> @@ -3614,7 +3614,8 @@ pmap_remove_holes(struct vm_map *map)
>  
>   (void)uvm_map(map, &shole, ehole - shole, NULL, UVM_UNKNOWN_OFFSET, 0,
>   UVM_MAPFLAG(UVM_PROT_NONE, UVM_PROT_NONE, UVM_INH_NONE,
> -   UVM_ADV_RANDOM, UVM_FLAG_NOMERGE | UVM_FLAG_HOLE));
> +   UVM_ADV_RANDOM,
> +   UVM_FLAG_NOMERGE | UVM_FLAG_HOLE | UVM_FLAG_FIXED));
>  }
>  
>  #ifdef DDB
> Index: arch/vax/vax/pmap.c
> ===
> RCS file: /cvs/src/sys/arch/vax/vax/pmap.c,v
> retrieving revision 1.50
> diff -u -d -p -r1.50 pmap.c
> --- arch/vax/vax/pmap.c   30 Sep 2008 20:00:29 -  1.50
> +++ arch/vax/vax/pmap.c   20 Apr 2011 23:34:12 -
> @@ -426,7 +426,8 @@ pmap_remove_holes(struct vm_map *map)
>  
>   (void)uvm_map(map, &shole, ehole - shole, NULL, UVM_UNKNOWN_OFFSET, 0,
>   UVM_MAPFLAG(UVM_PROT_NONE, UVM_PROT_NONE, UVM_INH_NONE,
> -   UVM_ADV_RANDOM, UVM_FLAG_NOMERGE | UVM_FLAG_HOLE));
> +   UVM_ADV_RANDOM,
> +   UVM_FLAG_NOMERGE | UVM_FLAG_HOLE | UVM_FLAG_FIXED));
>  }
>  
>  void
> Index: uvm/uvm_map.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_map.c,v
> retrieving revision 1.134
> diff -u -d -p -r1.134 uvm_map.c
> --- uvm/uvm_map.c 18 Apr 2011 19:23:46 -  1.134
> +++ uvm/uvm_map.c 20 Apr 2011 23:34:12 -
> @@ -744,6 +744,14 @@ uvm_map_p(struct vm_map *map, vaddr_t *s
>   map, *startp, size, flags);
>   UVMHIST_LOG(maphist, "  uobj/offset %p/%ld", uobj, (u_long)uoffset,0,0);
>  
> + /*
> +  * Holes are incompatible with other types of mappings.
> +  */
> + if (flags & UVM_FLAG_HOLE) {
> + KASSERT(uobj == NULL && (flags & UVM_FLAG_FIXED) != 0 &&
> + (flags & (UVM_FLAG_OVERLAY | UVM_FLAG_COPYONW)) == 0);
> + }
> +

So really what this does it enforce the fact that holes should be fixed
(so the map code doesn't even attempt to move them around which is
currently a risk if almost non-existant) and the flags should enforce
that? Similarly holes can't be copy on write or overlays.

I've confirmed that this is every hole allocation in the kernel. Ok.

-0-
-- 
Barometer, n.:
An ingenious instrument which indicates what kind of weather we
are having.
-- Ambrose Bierce, "The Devil's Dictionary"

Re: invalid ata_xfer state 06: Apr 23 snapshot amd64, Lenovo Thinkpad SL500

[Owain Ainsworth]

On Sun, Apr 24, 2011 at 06:23:13PM +0200, Peter N. M. Hansteen wrote:
> After upgrading my laptop to the latest snapshot earlier today, I
> noticed these messages in dmesg output:
> 
> ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: apic 2 int 19, 
> AHCI 1.2
> ahci0: invalid ata_xfer state 06 in ahci_put_ccb, slot 31
> ahci0: invalid ata_xfer state 06 in ahci_put_ccb, slot 31
> 
> I don't remember seeing those before, but I suppose this could be
> expected after a recent change?
> 
> Full dmesg follows.

IIRC dlg@ commited a fix for this earlier on today.

-0-
-- 
Genetics explains why you look like your father, and if you don't, why
you should.

Re: Radeon HD5450

[Owain Ainsworth]

On Sat, Apr 23, 2011 at 11:07:16PM -0400, Mark Peoples wrote:
> On Sun, Apr 03, 2011 at 08:37:08AM -0400, Mark Peoples wrote:
> > The following along with an update to xf86-video-ati-6.14.1 gets me some 
> > very sexy 1920x1080 on my Radeon HD5450
> 
> the xorg driver part getting updated probably isn't going to happen any time 
> soon, but can the pci bits go in? thanks!
> 
> Index: drm/radeon_drv.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
> retrieving revision 1.51
> diff -u drm/radeon_drv.c
> --- drm/radeon_drv.c29 Sep 2010 13:32:22 -  1.51
> +++ drm/radeon_drv.c3 Apr 2011 12:23:45 -
> @@ -526,6 +526,8 @@
> CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
> {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4200_M,
> CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
> +   {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD5450,
> +   CHIP_RS880|RADEON_NEW_MEMMAP},
>  {0, 0, 0}

While this has been commited this is actually wrong.

The chip is an evergreen (cedar, specifically) not a RS880. So it is
possible that something funny can happen when using this. I'll deal with
this when I get some time.

-0-
-- 
Experience is something you don't get until just after you need it.
-- Olivier

Re: km_alloc for stack and exec

[Owain Ainsworth]

On Mon, Apr 18, 2011 at 03:47:27PM -0600, Artur Grabowski wrote:
> A repeat of an earlier diff.
> 
> Change stack and exec arguments allocation from old allocators to km_alloc(9).
> 
> //art
> 
> 
> Index: kern/kern_exec.c
> ===
> RCS file: /cvs/src/sys/kern/kern_exec.c,v
> retrieving revision 1.117
> diff -u -r1.117 kern_exec.c
> --- kern/kern_exec.c  4 Apr 2011 13:00:13 -   1.117
> +++ kern/kern_exec.c  18 Apr 2011 19:37:08 -
> @@ -227,6 +227,11 @@
>   return (error);
>  }
>  
> +struct kmem_va_mode kv_exec = {
> + .kv_map = &exec_map,
> + .kv_wait = 1
> +};
> +
>  /*
>   * exec system call
>   */
> @@ -312,7 +317,7 @@
>   /* XXX -- THE FOLLOWING SECTION NEEDS MAJOR CLEANUP */
>  
>   /* allocate an argument buffer */
> - argp = (char *) uvm_km_valloc_wait(exec_map, NCARGS);
> + argp = km_alloc(NCARGS, &kv_exec, &kp_pageable, &kd_waitok);
>  #ifdef DIAGNOSTIC
>   if (argp == NULL)
>   panic("execve: argp == NULL");
> @@ -592,7 +597,7 @@
>   splx(s);
>   }
>  
> - uvm_km_free_wakeup(exec_map, (vaddr_t) argp, NCARGS);
> + km_free(argp, NCARGS, &kv_exec, &kp_pageable);
>  
>   pool_put(&namei_pool, nid.ni_cnd.cn_pnbuf);
>   vn_close(pack.ep_vp, FREAD, cred, p);
> @@ -689,7 +694,7 @@
>   /* close and put the exec'd file */
>   vn_close(pack.ep_vp, FREAD, cred, p);
>   pool_put(&namei_pool, nid.ni_cnd.cn_pnbuf);
> - uvm_km_free_wakeup(exec_map, (vaddr_t) argp, NCARGS);
> + km_free(argp, NCARGS, &kv_exec, &kp_pageable);
>  
>   freehdr:
>   free(pack.ep_hdr, M_EXEC);
> @@ -717,7 +722,7 @@
>   free(pack.ep_emul_arg, M_TEMP);
>   pool_put(&namei_pool, nid.ni_cnd.cn_pnbuf);
>   vn_close(pack.ep_vp, FREAD, cred, p);
> - uvm_km_free_wakeup(exec_map, (vaddr_t) argp, NCARGS);
> + km_free(argp, NCARGS, &kv_exec, &kp_pageable);
>  
>  free_pack_abort:
>   free(pack.ep_hdr, M_EXEC);
> Index: kern/kern_fork.c
> ===
> RCS file: /cvs/src/sys/kern/kern_fork.c,v
> retrieving revision 1.125
> diff -u -r1.125 kern_fork.c
> --- kern/kern_fork.c  3 Apr 2011 14:56:28 -   1.125
> +++ kern/kern_fork.c  18 Apr 2011 19:37:08 -
> @@ -195,6 +195,11 @@
>  /* print the 'table full' message once per 10 seconds */
>  struct timeval fork_tfmrate = { 10, 0 };
>  
> +struct kmem_va_mode kv_fork = {
> + .kv_map = &kernel_map,
> + .kv_align = USPACE_ALIGN
> +};
> +
>  int
>  fork1(struct proc *p1, int exitsig, int flags, void *stack, size_t stacksize,
>  void (*func)(void *), void *arg, register_t *retval,
> @@ -204,7 +209,7 @@
>   uid_t uid;
>   struct vmspace *vm;
>   int count;
> - vaddr_t uaddr;
> + struct user *uaddr;
>   int s;
>   extern void endtsleep(void *);
>   extern void realitexpire(void *);
> @@ -251,10 +256,7 @@
>   return (EAGAIN);
>   }
>  
> - uaddr = uvm_km_kmemalloc_pla(kernel_map, uvm.kernel_object, USPACE,
> - USPACE_ALIGN, UVM_KMF_ZERO,
> - dma_constraint.ucr_low, dma_constraint.ucr_high,
> - 0, 0, USPACE/PAGE_SIZE);
> + uaddr = km_alloc(USPACE, &kv_fork, &kp_dma_zero, &kd_waitok);
>   if (uaddr == 0) {

As ariane said, this should be checking null (km_alloc returns void * and
uaddr is pointer)

>   chgproccnt(uid, -1);
>   nprocs--;
> Index: kern/sys_pipe.c
> ===
> RCS file: /cvs/src/sys/kern/sys_pipe.c,v
> retrieving revision 1.58
> diff -u -r1.58 sys_pipe.c
> --- kern/sys_pipe.c   14 Jan 2010 23:12:11 -  1.58
> +++ kern/sys_pipe.c   18 Apr 2011 19:37:08 -
> @@ -168,9 +168,9 @@
>  int
>  pipespace(struct pipe *cpipe, u_int size)
>  {
> - caddr_t buffer;
> + void *buffer;
>  
> - buffer = (caddr_t)uvm_km_valloc(kernel_map, size);
> + buffer = km_alloc(size, &kv_any, &kp_pageable, &kd_waitok);
>   if (buffer == NULL) {
>   return (ENOMEM);
>   }
> @@ -714,8 +714,8 @@
>   if (cpipe->pipe_buffer.size > PIPE_SIZE)
>   --nbigpipe;
>   amountpipekva -= cpipe->pipe_buffer.size;
> - uvm_km_free(kernel_map, (vaddr_t)cpipe->pipe_buffer.buffer,
> - cpipe->pipe_buffer.size);
> + km_free(cpipe->pipe_buffer.buffer, cpipe->pipe_buffer.size,
> + &kv_any, &kp_pageable);
>   cpipe->pipe_buffer.buffer = NULL;
>   }
>  }
> Index: uvm/uvm_glue.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_glue.c,v
> retrieving revision 1.58
> diff -u -r1.58 uvm_glue.c
> --- uvm/uvm_glue.c15 Apr 2011 21:47:24 -  1.58
> +++ uvm/uvm_glue.c18 Apr 2011 19:37:09 -
> @@ -361,9 +361,11 @@
>  void
>  uvm_exit(struct proc *p)
>  {
> + extern struct kmem_va_mode kv_f

Re: use uvm_pageratop instead of handrolling our own

[Owain Ainsworth]

On Fri, Apr 15, 2011 at 08:07:54PM +, Miod Vallat wrote:
> > Rename uvm_pageratop() to uvm_atop and use it in uvm_km.c to replace the 
> > exact
> > same code handrolled for a little bit of shrinkage.
> 
> Bikeshedding, but an `atop' name implies it returns a pa. Use `atopg' to
> emphasis it returns a pg.
> 
> Besides this, ok.

Agreed. change made and diff commited.

-0-
-- 
Joe's sister puts spaghetti in her shoes!

Remove and clean up callers of pmap_clear_reference and pmap_page_protect

[Owain Ainsworth]

audit callers of pmap_clear_reference() and
pmap_page_protect(,,VM_PROT_NONE) just before uvm_pagedeactivate noting
the fact that freshly deactivated pages have their reference cleared in
uvm_pagedeactivate already.

first off, clear_reference:

uvm_anon.c -> only called on swapoff. we don't really require the reference
cleared if it has been accessed. doesn't matter. and if it was just swapped in
then the page won't be deactivated and it'll be freshly cleared again. Now I
come to think about it, though deactivating something we just swapped in is
wrong, since it isn't swapped out and has no backing store. deactivated pages
mean we can dump them at will. 

uvm_aobj.c exactly the same situation as above.

uvm_fault.c -> deactivating anons due to MADV. so either it is already
deactivated and will have reference cleared, or is already deactivated and has 
been
referenced since, so the advice is bullshit anyway, or it is active and will be
cleared. (also only for UBC anyway, so this discussion was somewhat
redundant)

uvm_map.c -> only for ubc 

remove all of those redundant calls. The UBC stuff is useless now
anyway.

with pmap_page_protect, every caller of uvm_pagedeactivate first calls
pmap_page_protect. This is techinically incorrect, but done due to pmap
bugs.  move the page protect call into uvm_pagedeactivate itself and
detail with an XXX comment why this is done.

The page_protect part of this diff was commited by art a few years ago
and backed out as part of the big uvm backout and never reinstated.

ok?

-0-

Index: uvm/uvm_anon.c
===
RCS file: /cvs/src/sys/uvm/uvm_anon.c,v
retrieving revision 1.34
diff -u -p -r1.34 uvm_anon.c
--- uvm/uvm_anon.c  16 Jun 2009 23:54:57 -  1.34
+++ uvm/uvm_anon.c  1 Apr 2011 20:57:25 -
@@ -351,8 +351,6 @@ uvm_anon_pagein(struct vm_anon *anon)
 * deactivate the page (to put it on a page queue)
 */
 
-   pmap_clear_reference(pg);
-   pmap_page_protect(pg, VM_PROT_NONE);
uvm_lock_pageq();
uvm_pagedeactivate(pg);
uvm_unlock_pageq();
Index: uvm/uvm_aobj.c
===
RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
retrieving revision 1.51
diff -u -p -r1.51 uvm_aobj.c
--- uvm/uvm_aobj.c  2 Jul 2010 02:08:53 -   1.51
+++ uvm/uvm_aobj.c  1 Apr 2011 21:10:23 -
@@ -783,10 +783,6 @@ uao_flush(struct uvm_object *uobj, voff_
continue;
 
uvm_lock_pageq();
-   /* zap all mappings for the page. */
-   pmap_page_protect(pp, VM_PROT_NONE);
-
-   /* ...and deactivate the page. */
uvm_pagedeactivate(pp);
uvm_unlock_pageq();
 
@@ -1364,10 +1360,6 @@ uao_pagein_page(struct uvm_aobj *aobj, i
/*
 * deactivate the page (to put it on a page queue).
 */
-   pmap_clear_reference(pg);
-#ifndef UBC
-   pmap_page_protect(pg, VM_PROT_NONE);
-#endif
uvm_lock_pageq();
uvm_pagedeactivate(pg);
uvm_unlock_pageq();
Index: uvm/uvm_fault.c
===
RCS file: /cvs/src/sys/uvm/uvm_fault.c,v
retrieving revision 1.58
diff -u -p -r1.58 uvm_fault.c
--- uvm/uvm_fault.c 22 Jul 2009 21:05:37 -  1.58
+++ uvm/uvm_fault.c 1 Apr 2011 21:00:12 -
@@ -202,14 +202,8 @@ uvmfault_anonflush(struct vm_anon **anon
pg = anons[lcv]->an_page;
if (pg && (pg->pg_flags & PG_BUSY) == 0 && pg->loan_count == 0) 
{
uvm_lock_pageq();
-   if (pg->wire_count == 0) {
-#ifdef UBC
-   pmap_clear_reference(pg);
-#else
-   pmap_page_protect(pg, VM_PROT_NONE);
-#endif
+   if (pg->wire_count == 0)
uvm_pagedeactivate(pg);
-   }
uvm_unlock_pageq();
}
simple_unlock(&anons[lcv]->an_lock);
Index: uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.131
diff -u -p -r1.131 uvm_map.c
--- uvm/uvm_map.c   24 Dec 2010 21:49:04 -  1.131
+++ uvm/uvm_map.c   1 Apr 2011 21:00:57 -
@@ -3172,15 +3172,7 @@ uvm_map_clean(struct vm_map *map, vaddr_
}
KASSERT(pg->uanon == anon);
 
-#ifdef UBC
/* ...and deactivate the page. */
-   pmap_clear_reference(pg);
-#else
-   /* zap all mappings for the page. */
-   pmap_page_protect(pg, VM_PROT_NONE);
-
-   /* ...and deactivate the page. */
-#endif
 

A bit of paranoia for uvm objects

[Owain Ainsworth]

paranoia: check that uvm_pageinsert never inserts over an existing page.
this is invalid (and means a memory leak).

put in various places for debugging by at least myself and art more than once.
(this was an #ifdef DEBUG || 1 in vfs_biomem.c using a more expensive
checks until the hackathon, for a start)

may as well put it here where it is free to check it.

ok?

-0-

Index: uvm/uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.102
diff -u -p -r1.102 uvm_page.c
--- uvm/uvm_page.c  7 Aug 2010 03:50:02 -   1.102
+++ uvm/uvm_page.c  1 Apr 2011 20:11:20 -
@@ -156,11 +159,13 @@ static void uvm_pageremove(struct vm_pag
 __inline static void
 uvm_pageinsert(struct vm_page *pg)
 {
+   struct vm_page  *dupe;
UVMHIST_FUNC("uvm_pageinsert"); UVMHIST_CALLED(pghist);
 
KASSERT((pg->pg_flags & PG_TABLED) == 0);
-   /* XXX should we check duplicates? */   
-   RB_INSERT(uvm_objtree, &pg->uobject->memt, pg);
+   dupe = RB_INSERT(uvm_objtree, &pg->uobject->memt, pg);
+   /* not allowed to insert over another page */
+   KASSERT(dupe == NULL);
atomic_setbits_int(&pg->pg_flags, PG_TABLED);
pg->uobject->uo_npages++;
 }

-- 
Boy, n.:
A noise with dirt on it.

Remove redundant acpi event declarations

[Owain Ainsworth]

Remove the now superfluous acpi event flags. it uses the apm ones now
and has for quite some time.

ok?

-0-

Index: dev/acpi/acpivar.h
===
RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
retrieving revision 1.69
diff -u -p -r1.69 acpivar.h
--- dev/acpi/acpivar.h  2 Jan 2011 04:56:57 -   1.69
+++ dev/acpi/acpivar.h  1 Apr 2011 20:26:02 -
@@ -276,15 +276,6 @@ struct acpi_dev_rank {
 #defineACPI_IOC_GETTABLE   _IOWR('A', 1, struct acpi_table)
 #define ACPI_IOC_SETSLEEPSTATE _IOW('A', 2, int)
 
-#defineACPI_EV_PWRBTN  0x0001  /* Power button was pushed */
-#defineACPI_EV_SLPBTN  0x0002  /* Sleep button was pushed */
-
-#defineACPI_EVENT_MASK 0x0003
-
-#defineACPI_EVENT_COMPOSE(t,i) (((i) & 0x7fff) << 16 | ((t) & 
ACPI_EVENT_MASK))
-#defineACPI_EVENT_TYPE(e)  ((e) & ACPI_EVENT_MASK)
-#defineACPI_EVENT_INDEX(e) ((e) >> 16)
-
 #if defined(_KERNEL)
 struct   acpi_gas;
 int acpi_map_address(struct acpi_softc *, struct acpi_gas *, bus_addr_t, 
bus_size_t,

-- 
A copy of the universe is not what is required of art; one of the
damned things is ample.
-- Rebecca West

Remove a redundant pmap_page_protect

[Owain Ainsworth]

In uvm_pager_dropcluster in the PG_RELEASED case we specifically unbusy the page
so that uvm_anfree will free it.

in uvm_anfree, it will pmap_page_protect a page that it is going to free, so
there is no need to do so beforehand ourselves.

ok?

-0-

Index: uvm/uvm_pager.c
===
RCS file: /cvs/src/sys/uvm/uvm_pager.c,v
retrieving revision 1.57
diff -u -p -r1.57 uvm_pager.c
--- uvm/uvm_pager.c 24 Jul 2010 15:40:39 -  1.57
+++ uvm/uvm_pager.c 1 Apr 2011 21:35:23 -
@@ -749,7 +747,6 @@ uvm_pager_dropcluster(struct uvm_object 
PG_BUSY);
UVM_PAGE_OWN(ppsp[lcv], NULL);
 
-   pmap_page_protect(ppsp[lcv], VM_PROT_NONE);
simple_unlock(&ppsp[lcv]->uanon->an_lock);
/* kills anon and frees pg */
uvm_anfree(ppsp[lcv]->uanon);

-- 
While anyone can admit to themselves they were wrong, the true test is
admission to someone else.

use uvm_pageratop instead of handrolling our own

[Owain Ainsworth]

Rename uvm_pageratop() to uvm_atop and use it in uvm_km.c to replace the exact
same code handrolled for a little bit of shrinkage.

ok?

-0-

Index: uvm/uvm_glue.c
===
RCS file: /cvs/src/sys/uvm/uvm_glue.c,v
retrieving revision 1.55
diff -u -p -r1.55 uvm_glue.c
--- uvm/uvm_glue.c  2 Jul 2010 22:38:32 -   1.55
+++ uvm/uvm_glue.c  1 Apr 2011 20:40:59 -
@@ -462,3 +462,20 @@ uvm_swapout_threads(void)
pmap_collect(p->p_vmspace->vm_map.pmap);
}
 }
+
+/*
+ * uvm_atop: convert KVAs back to their page structures.
+ */
+struct vm_page *
+uvm_atop(vaddr_t kva)
+{
+   struct vm_page *pg;
+   paddr_t pa;
+   boolean_t rv;
+ 
+   rv = pmap_extract(pmap_kernel(), kva, &pa);
+   KASSERT(rv);
+   pg = PHYS_TO_VM_PAGE(pa);
+   KASSERT(pg != NULL);
+   return (pg);
+} 
Index: uvm/uvm_glue.h
===
RCS file: /cvs/src/sys/uvm/uvm_glue.h,v
retrieving revision 1.7
diff -u -p -r1.7 uvm_glue.h
--- uvm/uvm_glue.h  14 Mar 2002 01:27:18 -  1.7
+++ uvm/uvm_glue.h  1 Apr 2011 20:42:13 -
@@ -46,6 +46,8 @@
 
 void uvm_swapout_threads(void);
 
+struct vm_page *uvm_atop(vaddr_t);
+
 #endif /* _KERNEL */
 
 #endif /* _UVM_UVM_GLUE_H_ */
Index: uvm/uvm_pager.c
===
RCS file: /cvs/src/sys/uvm/uvm_pager.c,v
retrieving revision 1.57
diff -u -p -r1.57 uvm_pager.c
--- uvm/uvm_pager.c 24 Jul 2010 15:40:39 -  1.57
+++ uvm/uvm_pager.c 1 Apr 2011 20:41:25 -
@@ -91,8 +91,6 @@ void  uvm_pseg_init(struct uvm_pseg *);
 vaddr_tuvm_pseg_get(int);
 void   uvm_pseg_release(vaddr_t);
 
-struct vm_page *uvm_pageratop(vaddr_t);
-
 /*
  * uvm_pager_init: init pagers (at boot time)
  */
@@ -830,7 +828,7 @@ uvm_aio_aiodone(struct buf *bp)
 
uobj = NULL;
for (i = 0; i < npages; i++) {
-   pgs[i] = uvm_pageratop((vaddr_t)bp->b_data + (i << PAGE_SHIFT));
+   pgs[i] = uvm_atop((vaddr_t)bp->b_data + (i << PAGE_SHIFT));
UVMHIST_LOG(pdhist, "pgs[%ld] = %p", i, pgs[i],0,0);
}
uvm_pagermapout((vaddr_t)bp->b_data, npages);
@@ -905,21 +903,3 @@ freed:
}
pool_put(&bufpool, bp);
 }
-
-/*
- * uvm_pageratop: convert KVAs in the pager map back to their page
- * structures.
- */
-struct vm_page *
-uvm_pageratop(vaddr_t kva)
-{
-   struct vm_page *pg;
-   paddr_t pa;
-   boolean_t rv;
- 
-   rv = pmap_extract(pmap_kernel(), kva, &pa);
-   KASSERT(rv);
-   pg = PHYS_TO_VM_PAGE(pa);
-   KASSERT(pg != NULL);
-   return (pg);
-} 
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.86
diff -u -p -r1.86 uvm_km.c
--- uvm/uvm_km.c26 Aug 2010 16:08:24 -  1.86
+++ uvm/uvm_km.c1 Apr 2011 20:15:03 -
@@ -902,11 +902,7 @@ uvm_km_doputpage(struct uvm_km_free_page
paddr_t pa;
struct uvm_km_free_page *nextfp = fp->next;
 
-   if (!pmap_extract(pmap_kernel(), va, &pa))
-   panic("lost pa");
-   pg = PHYS_TO_VM_PAGE(pa);
-
-   KASSERT(pg != NULL);
+   pg = uvm_pageratop(va);
 
pmap_kremove(va, PAGE_SIZE);
pmap_update(kernel_map->pmap);

-- 
Abandon the search for Truth; settle for a good fantasy.

Remove some dead struct members in uvm

[Owain Ainsworth]

When I swiched the uvm code over to using a per-object tree instead of the
global hash I forgot to remove the declarations for these from struct uvm.

Fix that. (pointed out by blambert)

ok?

-0-

Index: uvm/uvm.h
===
RCS file: /cvs/src/sys/uvm/uvm.h,v
retrieving revision 1.41
diff -u -p -r1.41 uvm.h
--- uvm/uvm.h   29 Jun 2010 20:39:27 -  1.41
+++ uvm/uvm.h   1 Apr 2011 20:25:27 -
@@ -120,12 +120,6 @@ struct uvm {
struct proc *aiodoned_proc; /* daemon's pid */
struct mutex aiodoned_lock;
 
-   /* page hash */
-   struct pglist *page_hash;   /* page hash table (vp/off->page) */
-   int page_nhash; /* number of buckets */
-   int page_hashmask;  /* hash mask */
-   struct mutex hashlock;  /* lock on page_hash array */
-
/* static kernel map entry pool */
vm_map_entry_t kentry_free; /* free page pool */
simple_lock_data_t kentry_lock;

Re: Defang buffer cache for bigmem.

[Owain Ainsworth]

On Fri, Apr 01, 2011 at 07:25:40AM -0600, Bob Beck wrote:
> 
> This diff moves the buffer cache to only be allocated out of dma'able
>  memory, along with a few pieces (flags) that I will need for the next step
>  of allowing it to touch high memory.
> 
>  Appears to behave well for me under load and builds survive it with
>  the buffer cache cranked up.
> 
>  I would like to get this in and a first step as it allows me to progress,
>  and will allow others to fix some of the other problems with drivers without 
> the buffer cache getting in the way with bigmem turned on. 
> 
>  -Bob
> 
> --8<
> Index: sys/kern/vfs_bio.c
> ===
> RCS file: /cvs/src/sys/kern/vfs_bio.c,v
> retrieving revision 1.127
> diff -u -r1.127 vfs_bio.c
> --- sys/kern/vfs_bio.c13 Nov 2010 17:45:44 -  1.127
> +++ sys/kern/vfs_bio.c1 Apr 2011 08:56:34 -
> @@ -191,19 +191,43 @@
>  void
>  bufinit(void)
>  {
> + long low, high, dmapages, highpages;
>   struct bqueues *dp;
>  
>   /* XXX - for now */
>   bufhighpages = buflowpages = bufpages = bufcachepercent = bufkvm = 0;
>  
>   /*
> +  * First off, figure out how much of memory we can use. 
> +  *
> +  * XXX for now we only use dma-able memory
> +  *
> +  * XXX - this isn't completely accurate, because their may
> +  * be holes in the physical memory. This needs to be replaced
> +  * with a uvm_pmemrange function to tell us how many pages
> +  * are within a constraint range - but this is accurate enough
> +  * for now. 
> +  */
> + 
> + low = atop(dma_constraint.ucr_low);
> + high = atop(dma_constraint.ucr_high);
> + if (high >= physmem) {
> + high = physmem;
> + highpages = 0;
> + }
> + else 
> + highpages = physmem - high;
> + /* XXX highpages not used yet but will be very soon. */

``not completely accurate'' is an understatement. due to how memory
segment can work this could be off by a shittonne. specifically the
guess would likely be high which mean we'd try to overallocate buffer
cache pages.

I'm about to get on a train i'll see if I can write that pmemrange
function for you.

> + dmapages = high - low;
> +
> + /*
>* If MD code doesn't say otherwise, use 10% of kvm for mappings and
> -  * 10% physmem for pages.
> +  * 10% of dmaable pages for cache pages.
>*/
>   if (bufcachepercent == 0)
>   bufcachepercent = 10;
>   if (bufpages == 0)
> - bufpages = physmem * bufcachepercent / 100;
> + bufpages = dmapages * bufcachepercent / 100;
>  
>   bufhighpages = bufpages;
>  
> @@ -212,7 +236,7 @@
>* we will not allow uvm to steal back more than this number of
>* pages
>*/
> - buflowpages = physmem * 10 / 100;
> + buflowpages = dmapages * 10 / 100;
>  
>   /*
>* set bufbackpages to 100 pages, or 10 percent of the low water mark
> Index: sys/kern/vfs_biomem.c
> ===
> RCS file: /cvs/src/sys/kern/vfs_biomem.c,v
> retrieving revision 1.14
> diff -u -r1.14 vfs_biomem.c
> --- sys/kern/vfs_biomem.c 30 Apr 2010 21:56:39 -  1.14
> +++ sys/kern/vfs_biomem.c 1 Apr 2011 05:32:21 -
> @@ -29,10 +29,19 @@
>  vaddr_t buf_kva_start, buf_kva_end;
>  int buf_needva;
>  TAILQ_HEAD(,buf) buf_valist;
> +void buf_realloc_pages(struct buf *, struct uvm_constraint_range *);
>  
>  int buf_nkvmsleep;
> +#if 0
> +extern int needda;
> +#endif

more da droppings, do they really have to be in here?
> +extern void  uvm_pagealloc_multi(struct uvm_object *, voff_t,
> + vsize_t, int);
> +extern void  uvm_pagerealloc_multi(struct uvm_object *, 
> voff_t,
> + vsize_t, int, struct uvm_constraint_range *);
these should go in one of the uvm headers.
>  
>  extern struct bcachestats bcstats;
> +extern int needbuffer;
>  
>  /*
>   * Pages are allocated from a uvm object (we only use it for page storage,
> @@ -99,6 +108,10 @@
>  
>   s = splbio();
>   SET(bp->b_flags, B_BUSY|B_NOTMAPPED);
> + if (bp->b_data != NULL) {
> + TAILQ_REMOVE(&buf_valist, bp, b_valist);
> + bcstats.busymapped++;
> + }
>   splx(s);
>  }
>  
> @@ -170,6 +183,26 @@
>   }
>   }
>   CLR(bp->b_flags, B_BUSY|B_NOTMAPPED);
> +#if 0
> + if (ISSET(bp->b_flags, B_DAQ) && needda) {
> + wakeup(&needda);
> + }
> +#endif
> + /* Wake up any processes waiting for any buffer to become free. */
> + if (needbuffer) {
> + needbuffer--;
> + wakeup(&needbuffer);
> + }
> +
> + /*
> +  * Wake up any processes waiting for _this_ buffer to become
> +  * free.
> +  */
> +
> + if (ISSET(bp->b_flags, B_WANTED)) {
> + CLR(bp->b_fla

Re: ls(1) displays future timestamps improperly

[Owain Ainsworth]

On Mon, Mar 21, 2011 at 12:04:33PM +0100, Benny Lofgren wrote:
> Realized I was sloppy with KNF. This diff is hopefully neater looking.
>
> Regards,
> /Benny
>
> 8<8<8<8<8<8< (cut)
> Index: print.c
> ===
> RCS file: /cvs/src/bin/ls/print.c,v
> retrieving revision 1.27
> diff -u -r1.27 print.c
> --- print.c   12 Sep 2010 20:16:29 -  1.27
> +++ print.c   21 Mar 2011 10:57:38 -
> @@ -235,6 +235,7 @@
>  {
>   int i;
>   char *longstring;
> + time_t now = time(NULL);
>
>   longstring = ctime(&ftime);
>   for (i = 4; i < 11; ++i)
> @@ -244,7 +245,7 @@
>   if (f_sectime)
>   for (i = 11; i < 24; i++)
>   (void)putchar(longstring[i]);
> - else if (ftime + SIXMONTHS > time(NULL))
> + else if (ftime > now - SIXMONTHS && ftime < now + 5) // some grace secs

No personal comment on the diff, but a nitpick:

No C++ style comments please.

/* */ style only (see style(9) for more details).

>   for (i = 11; i < 16; ++i)
>   (void)putchar(longstring[i]);
>   else {
> 8<8<8<8<8<8< (cut)
>
>
> --
> internetlabbet.se / work:   +46 8 551 124 80  / "Words must
> Benny Lofgren/  mobile: +46 70 718 11 90 /   be weighed,
> /   fax:+46 8 551 124 89/not counted."
>/email:  benny -at- internetlabbet.se
>

Cheers,

-0-
--
Man 1:  Ask me the what the most important thing about telling a good
joke is.

Man 2:  OK, what is the most impo --

Man 1:  __TIMING!

Re: small drm uvm diff

[Owain Ainsworth]

On Wed, Dec 15, 2010 at 12:05:31AM -0500, Ted Unangst wrote:
> there is no reason for drm_bufs to be poking inside the vmspace on its 
> own, this is what the uvm_map_hint function is for.

Yup, that's fine.

This was in place in this initial import of this code, suprised i've not
noticed and cleaned it up yet.

Please do put it in.
> 
> Index: drm_bufs.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_bufs.c,v
> retrieving revision 1.46
> diff -u -r1.46 drm_bufs.c
> --- drm_bufs.c15 Dec 2010 04:59:52 -  1.46
> +++ drm_bufs.c15 Dec 2010 05:04:30 -
> @@ -922,7 +922,6 @@
>  {
>   struct drm_device_dma   *dma = dev->dma;
>   struct drm_buf_map  *request = data;
> - struct vmspace  *vms;
>   struct vnode*vn;
>   vaddr_t  address, vaddr;
>   voff_t   foff;
> @@ -933,8 +932,6 @@
>   if (!vfinddev(file_priv->kdev, VCHR, &vn))
>   return EINVAL;
>  
> - vms = curproc->p_vmspace;
> -
>   rw_enter_write(&dma->dma_lock);
>   dev->dma->buf_use++;/* Can't allocate more after this call */
>   rw_exit_write(&dma->dma_lock);
> @@ -960,8 +957,8 @@
>   foff = 0;
>   }
>  
> - vaddr = round_page((vaddr_t)vms->vm_daddr + BRKSIZ);
> - retcode = uvm_mmap(&vms->vm_map, &vaddr, size,
> + vaddr = uvm_map_hint(curproc, VM_PROT_READ | VM_PROT_WRITE);
> + retcode = uvm_mmap(&curproc->p_vmspace->vm_map, &vaddr, size,
>   UVM_PROT_READ | UVM_PROT_WRITE, UVM_PROT_ALL, MAP_SHARED,
>   (caddr_t)vn, foff, curproc->p_rlimit[RLIMIT_MEMLOCK].rlim_cur,
>   curproc);

-- 
In Pocataligo, Georgia, it is a violation for a woman over 200 pounds
and attired in shorts to pilot or ride in an airplane.

Re: convert netisr to real softinterrupt

[Owain Ainsworth]

On Thu, Nov 25, 2010 at 11:23:42PM +0100, Mark Kettenis wrote:
> > Date: Thu, 25 Nov 2010 12:30:39 +
> > From: Owain Ainsworth 
> > 
> > On Thu, Nov 25, 2010 at 11:50:06AM +0100, Claudio Jeker wrote:
> > > On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> > > > On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > > > > This diff was made by oga@ some time ago -- I just fixed a few 
> > > > > conflicts
> > > > > and I would really like to see this going in.
> > > > > 
> > > > > netisr needs to be made a normal C function and not this madness it
> > > > > currently is. This is necessary to imporve the packet scheduling.
> > > > > 
> > > > > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> > > > 
> > > > hi,
> > > > 
> > > > i like the diff, but why not get rid of netisr_dispatch.h?
> > > 
> > > I planned to this after this diff goes in. I did not want to change
> > > Owain's initial diff too much so I left that out for now.
> > 
> > Miod pointed out to me when I first sent this out that some archs use
> > something slightly different than this generic version.
> > 
> > For example hppa uses a specially aligned netisr variable so it can use
> > the pa-risc real atomic instructions which are quite a bit faster.
> 
> Especially on MP kernels.
> 
> > Similarly x86 uses compare-and-swap instead of test, then clear bits.
> > 
> > I meant to add some MD defines so that this could be kept (falling back
> > to the implementation in this diff)  since miod claims that it is useful
> > and significantly faster (I did not check this). I've cced miod so he
> > can answer with somewhat more authority.
> 
> The hppa and i386/amd64 approach are rather similar.  Both do an
> atomic load and clear, which happens to be the only atomic instruction
> available on hppa, and is easy to implement as an atomic swap with 0
> on i386/amd64.  But implementing this operation on other architectures
> shouldn't be much more difficult, and should work just as well as the
> proposed code that uses atomic_clearbits_int().  The MI code would
> look something like:
> 
> void
> netintr(void *unused)
> {
>   int n;
> 
>   n = atomic_load_and_clear(&netisr);
> #define DONETISR(bit, fn) \
>   do {\
>   if (n & 1 << (bit)) \
>   fn();   \
>   } while ( /* CONSTCOND */ 0)
> #include 
> }

The only other thing to note is that you may need to define a type (or
whatever) since iirc the hppa one needs a specific alignment (cacheline
to itself).

Otherwise I like this approach, it is cleaner than what I was thinking
(not knowing exactly what hppa was doing other than it was faster didn't
help ;).

-0-
-- 
Sometimes I worry about being a success in a mediocre world.
-- Lily Tomlin

Re: convert netisr to real softinterrupt

[Owain Ainsworth]

On Thu, Nov 25, 2010 at 01:41:00PM +0100, Henning Brauer wrote:
> * Owain Ainsworth  [2010-11-25 13:33]:
> > and significantly faster (I did not check this).
> 
> I really want to see a verification that this doesn't slow us down
> before it goes in.
> 
> and no, sorry, "shouldn't be slower" is not good enough.

I was referring to using the MD specific alignment and instructions as
being faster. Not the diff in general (which lacks those tweaks for x86
and hppa).

I also recall asking you (or someone with the right setup) to please do
that verification, request still stands :).

-0-
-- 
Forgetfulness, n.:
A gift of God bestowed upon debtors in compensation for their
destitution of conscience.

Re: convert netisr to real softinterrupt

[Owain Ainsworth]

On Thu, Nov 25, 2010 at 11:50:06AM +0100, Claudio Jeker wrote:
> On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> > On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > > This diff was made by oga@ some time ago -- I just fixed a few conflicts
> > > and I would really like to see this going in.
> > > 
> > > netisr needs to be made a normal C function and not this madness it
> > > currently is. This is necessary to imporve the packet scheduling.
> > > 
> > > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> > 
> > hi,
> > 
> > i like the diff, but why not get rid of netisr_dispatch.h?
> 
> I planned to this after this diff goes in. I did not want to change
> Owain's initial diff too much so I left that out for now.

My diff needed some tweaking anyway.

Miod pointed out to me when I first sent this out that some archs use
something slightly different than this generic version.

For example hppa uses a specially aligned netisr variable so it can use
the pa-risc real atomic instructions which are quite a bit faster.

Similarly x86 uses compare-and-swap instead of test, then clear bits.

I meant to add some MD defines so that this could be kept (falling back
to the implementation in this diff)  since miod claims that it is useful
and significantly faster (I did not check this). I've cced miod so he
can answer with somewhat more authority.

> 
> > also i'm not sure, but maybe netisr.c copyright should be
> > attributed to berkeley as we're using their code directly?
> 
> Are we? The current netisr.c code is a generic implementation of using
> softinterrupts to run the netisr and in the future it will get even more
> different.  Owain, what do you think? 

I think my initial mail possibly mentioned that I was unsure if the
original was needed. Put the original one in there as well if you are
unsure. I won't try and claim that I'm positive that it was entirely my
code (too long ago for a start ;).

Anyway, thanks for taking over this diff, claudio. I'm far too busy
right now to sort it out.

Ta,

-0-
-- 
Grelb's Reminder:
Eighty percent of all people consider themselves to be above
average drivers.

Re: more assertwaitok() love

[Owain Ainsworth]

On Thu, Sep 30, 2010 at 12:29:54AM +, Thordur Bjornsson wrote:
> Hi.
> 
> Try to catch more places where we sleep and are not allowed.
> 
> One thing of note, msleep() is missing in this diff, but there
> it is needed to call to sleep_setup routines with the mutex
> held, and after we release it we _will_ sleep so a sleep there
> with another mutex held will be caught by the assertwaitok()
> in mi_switch().
> 
> Also, define assertwaitok() out for !DIAGNOSTIC kernels.
> 
> Comments/OKs?
> Index: kern/kern_rwlock.c
> ===
> RCS file: /home/cvs/src/sys/kern/kern_rwlock.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 kern_rwlock.c
> --- kern/kern_rwlock.c24 Sep 2010 13:21:30 -  1.16
> +++ kern/kern_rwlock.c30 Sep 2010 00:12:12 -
> @@ -87,6 +87,8 @@ rw_enter_read(struct rwlock *rwl)
>  {
>   unsigned long owner = rwl->rwl_owner;
>  
> + assertwaitok();
> +
>   if (__predict_false((owner & RWLOCK_WRLOCK) ||
>   rw_cas(&rwl->rwl_owner, owner, owner + RWLOCK_READ_INCR)))
>   rw_enter(rwl, RW_READ);
> @@ -97,6 +99,8 @@ rw_enter_write(struct rwlock *rwl)
>  {
>   struct proc *p = curproc;
>  
> + assertwaitok();
> +
>   if (__predict_false(rw_cas(&rwl->rwl_owner, 0,
>   RW_PROC(p) | RWLOCK_WRLOCK)))
>   rw_enter(rwl, RW_WRITE);

These two are fine
> @@ -190,6 +194,9 @@ rw_enter(struct rwlock *rwl, int flags)
>   struct sleep_state sls;
>   unsigned long inc, o;
>   int error;
> +
> + if (!(flags & RW_NOSLEEP))
> + assertwaitok();

Suppose this is ok (for interlocking with mutexen), still need to be in
process context, though.

>  
>   op = &rw_ops[flags & RW_OPMASK];
>  
> Index: kern/kern_synch.c
> ===
> RCS file: /home/cvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.95
> diff -u -p -r1.95 kern_synch.c
> --- kern/kern_synch.c 29 Jun 2010 00:28:14 -  1.95
> +++ kern/kern_synch.c 29 Sep 2010 21:55:58 -
> @@ -121,6 +121,8 @@ tsleep(const volatile void *ident, int p
>   return (0);
>   }
>  
> + assertwaitok();
> +
>   sleep_setup(&sls, ident, priority, wmesg);
>   sleep_setup_timeout(&sls, timo);
>   sleep_setup_signal(&sls, priority);
> Index: kern/subr_pool.c
> ===
> RCS file: /home/cvs/src/sys/kern/subr_pool.c,v
> retrieving revision 1.98
> diff -u -p -r1.98 subr_pool.c
> --- kern/subr_pool.c  26 Sep 2010 21:03:57 -  1.98
> +++ kern/subr_pool.c  30 Sep 2010 00:03:15 -
> @@ -455,10 +455,8 @@ pool_get(struct pool *pp, int flags)
>  
>   KASSERT(flags & (PR_WAITOK | PR_NOWAIT));
>  
> -#ifdef DIAGNOSTIC
>   if ((flags & PR_WAITOK) != 0)
>   assertwaitok();
> -#endif /* DIAGNOSTIC */
>  
>   mtx_enter(&pp->pr_mtx);
>   v = pool_do_get(pp, flags);
> Index: kern/subr_xxx.c
> ===
> RCS file: /home/cvs/src/sys/kern/subr_xxx.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 subr_xxx.c
> --- kern/subr_xxx.c   28 Sep 2010 20:27:56 -  1.12
> +++ kern/subr_xxx.c   29 Sep 2010 21:55:03 -
> @@ -156,13 +156,15 @@ blktochr(dev_t dev)
>  /*
>   * Check that we're in a context where it's okay to sleep.
>   */
> +
> +#ifdef DIAGNOSTIC
>  void
>  assertwaitok(void)
>  {
>   splassert(IPL_NONE);
> -#ifdef DIAGNOSTIC
> +
>   if (curcpu()->ci_mutex_level != 0)
>   panic("assertwaitok: non-zero mutex count: %d",
>   curcpu()->ci_mutex_level);
> -#endif
>  }
> +#endif
> Index: sys/systm.h
> ===
> RCS file: /home/cvs/src/sys/sys/systm.h,v
> retrieving revision 1.86
> diff -u -p -r1.86 systm.h
> --- sys/systm.h   21 Sep 2010 01:09:10 -  1.86
> +++ sys/systm.h   30 Sep 2010 00:02:51 -
> @@ -179,7 +179,11 @@ void ttyprintf(struct tty *, const char 
>  void splassert_fail(int, int, const char *);
>  extern   int splassert_ctl;
>  
> +#ifdef DIAGNOSTIC
>  void assertwaitok(void);
> +#else
> +#define  assertwaitok()  do { /* nothing */ } while (0)
> +#endif
>  
>  void tablefull(const char *);
> 

I'm ok with this.

-0-
-- 
It is better never to have been born.  But who among us has such luck?
One in a million, perhaps.

Re: de-static uvm_swap

[Owain Ainsworth]

On Fri, Sep 24, 2010 at 10:33:28PM +, Thordur Bjornsson wrote:
> and I'd like to kill these to:

I"m fairly sure I did both of these diffs once (before c2k9), so sure.
destatic away. OK.

-0-
> 
> Index: uvm_pdaemon.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_pdaemon.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 uvm_pdaemon.c
> --- uvm_pdaemon.c 14 Oct 2009 17:53:30 -  1.55
> +++ uvm_pdaemon.c 24 Sep 2010 22:31:47 -
> @@ -96,9 +96,9 @@
>   * local prototypes
>   */
>  
> -static void  uvmpd_scan(void);
> -static boolean_t uvmpd_scan_inactive(struct pglist *);
> -static void  uvmpd_tune(void);
> +void uvmpd_scan(void);
> +boolean_tuvmpd_scan_inactive(struct pglist *);
> +void uvmpd_tune(void);
>  
>  /*
>   * uvm_wait: wait (sleep) for the page daemon to free some pages
> @@ -155,7 +155,7 @@ uvm_wait(const char *wmsg)
>   * => caller must call with page queues locked
>   */
>  
> -static void
> +void
>  uvmpd_tune(void)
>  {
>   UVMHIST_FUNC("uvmpd_tune"); UVMHIST_CALLED(pdhist);
> @@ -329,7 +329,7 @@ uvm_aiodone_daemon(void *arg)
>   * => we return TRUE if we are exiting because we met our target
>   */
>  
> -static boolean_t
> +boolean_t
>  uvmpd_scan_inactive(struct pglist *pglst)
>  {
>   boolean_t retval = FALSE;   /* assume we haven't hit target */
> 

-- 
Census Taker to Housewife: Did you ever have the measles, and, if so,
how many?

Re: Testers needed for strict locking diff; esp i386, amd64, softraid

[Owain Ainsworth]

On Thu, Sep 23, 2010 at 10:49:01PM -0700, Matthew Dempsky wrote:
> I'd like to commit this.  I've received positive reports from a few
> amd64 users and an i386 and softraid user, and all of the locking bugs
> exposed so far have already been fixed.
> 
> I plan to remove the "#define panic()" hacks and let future locking
> problems actually panic; if anyone thinks they should stay in for a
> bit longer, let me know.
> 
> ok?

ok o...@. I've wanted something like this for a while

-0-
-- 
Conscience is a mother-in-law whose visit never ends.
-- H. L. Mencken

Re: Kill suser() call in tunopen()?

[Owain Ainsworth]

On Wed, Sep 22, 2010 at 11:45:10AM +0100, Kevin Chadwick wrote:
> On Wed, 22 Sep 2010 11:25:02 +0100
> Owain Ainsworth  wrote:
> 
> > On Tue, Sep 21, 2010 at 06:32:50PM -0700, Matthew Dempsky wrote:
> > > /dev/tun* are already owned by root and mode 0600 by default, so it
> > > seems redundant to check suser() in tunopen().
> > 
> > Looks like vnd could have the same change for the same resons.
> > 
> > If so i'll whip up the requisite two-liner.
> > 
> > -0-
> > -- 
> > Computers are useless.  They can only give you answers.
> > -- Pablo Picasso
> > 
> 
> I can see potential reasons for changing the user on tun devices and
> so saw no problem at all. I wonder if it is better however to have the
> check at runtime for things like vnconfig, could having the wrong user
> jeopardise an encryption password at all?.

Reading the code, you can do VNDIOCGET, that gets you the filename,
device and inode of the vnd, that is it. The other ioctls are the
standard disk ones, create vnd (takes a key) and delete vnd.

We have device permissions for a reason, i find it questionable to
redundantly check, if you change permisions to let any man or his dog
create a vnd, you deserve what you get.

-0-
-- 
Graduate life: It's not just a job.  It's an indenture.

Re: Kill suser() call in tunopen()?

[Owain Ainsworth]

On Tue, Sep 21, 2010 at 06:32:50PM -0700, Matthew Dempsky wrote:
> /dev/tun* are already owned by root and mode 0600 by default, so it
> seems redundant to check suser() in tunopen().

Looks like vnd could have the same change for the same resons.

If so i'll whip up the requisite two-liner.

-0-
-- 
Computers are useless.  They can only give you answers.
-- Pablo Picasso

Fix VOP_* callers WRT proc usage

[Owain Ainsworth]

The mail I wrote earlier seems to have vanished from my mail queue
without trace, so here's a resend.

Several of the vn_ and VOP functions take a struct proc as an argument,
it doesn't actually ever make sense for this to be anything other than
curproc (removing the argument is part of thib's planned vnode rework,
but for now having it correct means less crashes, so is inherently good).

However, a recent vnd + softraid panic I saw lead me to find out that
several callers in the tree are calling these functions with NULL (or
even 0, ick) for the proc pointer, that is all kinda of wrong.
Especially in the case of VOP_IOCTL which ahs good reasons to expect a
valid proc pointer will always be there.

This diff is the result of systematically checking every caller of a VOP
or vn_ function that takes a proc and fixing the wrong ones. Doing so
also reminded me how nasty some of our vfs bits are.

jsing and mikeb tested the softraid bits, pea, matthieu and naddy tested
the raidframe bits. The rest is running on the machine I am typing this
mail from and has caused no problems.

thib@ has already oked this diff, but more review and tests are never a
bad thing.

so, any more oks, tests or comments?

Cheers,

-0-
--
"In short, _N is Richardian if, and only if, _N is not Richardian."

Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.213
diff -u -p -r1.213 softraid.c
--- dev/softraid.c  7 Sep 2010 17:14:06 -   1.213
+++ dev/softraid.c  20 Sep 2010 23:23:41 -
@@ -322,7 +322,7 @@ sr_meta_probe(struct sr_discipline *sd,
 * XXX leaving dev open for now; move this to attach
 * and figure out the open/close dance for unwind.
 */
-   error = VOP_OPEN(vn, FREAD | FWRITE, NOCRED, 0);
+   error = VOP_OPEN(vn, FREAD | FWRITE, NOCRED, curproc);
if (error) {
DNPRINTF(SR_D_META,"%s: sr_meta_probe can't "
"open %s\n", DEVNAME(sc), devname);
@@ -900,7 +900,7 @@ sr_meta_native_bootprobe(struct sr_softc
}

/* open device */
-   error = VOP_OPEN(vn, FREAD, NOCRED, 0);
+   error = VOP_OPEN(vn, FREAD, NOCRED, curproc);
if (error) {
DNPRINTF(SR_D_META, "%s: sr_meta_native_bootprobe open "
"failed\n", DEVNAME(sc));
@@ -909,17 +909,18 @@ sr_meta_native_bootprobe(struct sr_softc
}

/* get disklabel */
-   error = VOP_IOCTL(vn, DIOCGDINFO, (caddr_t)&label, FREAD, NOCRED, 0);
+   error = VOP_IOCTL(vn, DIOCGDINFO, (caddr_t)&label, FREAD, NOCRED,
+   curproc);
if (error) {
DNPRINTF(SR_D_META, "%s: sr_meta_native_bootprobe ioctl "
"failed\n", DEVNAME(sc));
-   VOP_CLOSE(vn, FREAD, NOCRED, 0);
+   VOP_CLOSE(vn, FREAD, NOCRED, curproc);
vput(vn);
goto done;
}

/* we are done, close device */
-   error = VOP_CLOSE(vn, FREAD, NOCRED, 0);
+   error = VOP_CLOSE(vn, FREAD, NOCRED, curproc);
if (error) {
DNPRINTF(SR_D_META, "%s: sr_meta_native_bootprobe close "
"failed\n", DEVNAME(sc));
@@ -957,7 +958,7 @@ sr_meta_native_bootprobe(struct sr_softc
"vnode for partition\n", DEVNAME(sc));
goto done;
}
-   error = VOP_OPEN(vn, FREAD, NOCRED, 0);
+   error = VOP_OPEN(vn, FREAD, NOCRED, curproc);
if (error) {
DNPRINTF(SR_D_META, "%s: sr_meta_native_bootprobe "
"open failed, partition %d\n",
@@ -969,14 +970,14 @@ sr_meta_native_bootprobe(struct sr_softc
if (sr_meta_native_read(fake_sd, rawdev, md, NULL)) {
printf("%s: native bootprobe could not read native "
"metadata\n", DEVNAME(sc));
-   VOP_CLOSE(vn, FREAD, NOCRED, 0);
+   VOP_CLOSE(vn, FREAD, NOCRED, curproc);
vput(vn);
continue;
}

/* are we a softraid partition? */
if (md->ssdi.ssd_magic != SR_MAGIC) {
-   VOP_CLOSE(vn, FREAD, NOCRED, 0);
+   VOP_CLOSE(vn, FREAD, NOCRED, curproc);
vput(vn);
continue;
}
@@ -999,7 +1000,7 @@ sr_meta_native_bootprobe(struct sr_softc
}

/* we are done, close partition */
-   VOP_CLOSE(vn, FREAD, NOCRED, 0);
+   VOP_CLOSE(vn, FREAD, NOCRED, curproc);
vput(vn);
}

@@ -1368,7 +1369,7 @@ sr_meta_native_probe(struct sr_softc *sc

/* get disklabel */
 

Re: Minor clarifications for bioctl.8 and softraid.4

[Owain Ainsworth]

On Sun, Sep 12, 2010 at 11:00:47PM -0700, Chris Palmer wrote:
> Jason McIntyre writes:
> 
> > ok, my diff below tries to collect the various bits of feedback. stuff i
> > haven't taken:
> 
> Thanks for doing this.
> 
> > - delete -> detach, for reasons given by marco
> 
> I'd still like to reconsider this.
> 
> > - `` -> "; i don't think it's worth changing
> 
> But it looks silly with the other style of quotes right next to it in the
> page:

Admittedly, from purely anecdotal evidence I am used to seeing that
quoting style in our manpages, so I would make the change for the sake
of consistency.

-0-
-- 
If the code and the comments disagree, then both are probably wrong.
-- Norm Schryer

Re: patch_bioctl_F.patch (inline)

[Owain Ainsworth]

On Sun, Sep 12, 2010 at 10:56:22PM +0200, Merlyn wrote:
> sending the patch fot bioctl
> I'm quite a newbie, so if you find some problem (and you certainly will),
> could you please explain it for me?
> there is a little change from the previous patch - parameter
> has been renamed to -t and expects the number of retries (0 means infinitely).

cvs diff -uNp, please.

-0-
-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer

Re: add rc.firsttime to rc(8)

[Owain Ainsworth]

On Thu, Sep 09, 2010 at 10:30:38PM +0200, tst wrote:
> This makes rc(8) man page tell about /etc/rc.firsttime.
> 
> tilo
> 
> 
> Index: rc.8
> ===
> RCS file: /zeug/OpenBSD/cvs/src/share/man/man8/rc.8,v
> retrieving revision 1.25
> diff -u -p -r1.25 rc.8
> --- rc.8  31 May 2007 19:19:59 -  1.25
> +++ rc.8  9 Sep 2010 20:28:04 -
> @@ -125,6 +125,11 @@ See
>  .Xr securelevel 7
>  for the effects of setting the security level.
>  .Pp
> +If 
> +.Nm rc.firsttime
> +exists, it is executed once and then deleted.
> +Any output is mailed to root.
> +.Pp
>  .Nm rc.local
>  is executed towards the end of
>  .Nm rc
> @@ -194,6 +199,8 @@ Site specific command scripts for system
>  System daemon configuration database.
>  .It /etc/rc.conf.local
>  Site specific daemon configuration database.
> +.It /etc/rc.firsttime
> +Commands run at first boot ever.

I would not use ``ever'' here.

``Commands run on the first boot after creation''

or similar.

-0-
-- 
It is the business of the future to be dangerous.
-- Hawkwind

Re: cut swap over to bufq

[Owain Ainsworth]

On Sun, Sep 05, 2010 at 09:43:30AM -0600, Bob Beck wrote:
> > Like owain said, things will get quiesced anyway. And why wouldn't want
> > to quiesce swap i/o when suspending the machine.
> >
> 
> 
> You may not want to queisce swap if you are depending on it to get you pages
> so you can finish suspending.
> 
> Basically by saying you will prevent swap is that you will make a situation
> where you ask for a page of memory and don't get it because you are
> suspending.

Nothing the kernel needs to touch is swappable. by this point the
suspend process only needs kernel stuff, userland has done running (but
it still schedulnig until we disable interrupts). We don't swap device
softcs etc, for obvious reasons.

Ok, so there is one kernel thing that is swappable: pipe buffers, but
they are not dependant for suspend (see above).

-0-
-- 
Spouse, n.:
Someone who'll stand by you through all the trouble you
wouldn't have had if you'd stayed single.

Re: cut swap over to bufq

[Owain Ainsworth]

On Sun, Sep 05, 2010 at 02:07:03PM +, Thordur I Bjornsson wrote:
> On Fri, Sep 03, 2010 at 09:11:39AM +, Thordur I Bjornsson wrote:
> > Hi gang,
> 
> Gabriel Kihlman spotted a small problem, swd_active was not
> being incremented.
> 
> Here's an updated diff.

Looks alright to me, haven't tested it yet (will do this afternoon
sometime) one comment below:

> 
> Index: sys/buf.h
> ===
> RCS file: /home/cvs/src/sys/sys/buf.h,v
> retrieving revision 1.72
> diff -u -p -r1.72 buf.h
> --- sys/buf.h 2 Sep 2010 07:05:39 -   1.72
> +++ sys/buf.h 5 Sep 2010 14:00:49 -
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define NOLIST ((struct buf *)0x87654321)
>  
> @@ -105,10 +106,18 @@ struct bufq_fifo {
>   SIMPLEQ_ENTRY(buf)  bqf_entries;
>  };
>  
> +/* Abuse bufq_fifo, for swapping to regular files. */
> +struct bufq_swapreg {
> + SIMPLEQ_ENTRY(buf)  bqf_entries;
> + struct workq_task   bqf_wqtask;
> +
> +};

BIKESHED: Perhaps this should be:

struct bufq_swapreg {
struct bufq_fifobfs_fifo;
struct workq_task   bqs_wqtask;
}

So if you ever change bufq_fifo bad things won't happen when fields
overlap.

Ta,

-0-
-- 
Perfect day for scrubbing the floor and other exciting things.

Re: cut swap over to bufq

[Owain Ainsworth]

On Sun, Sep 05, 2010 at 04:39:33PM +0200, Mark Kettenis wrote:
> > Date: Sun, 5 Sep 2010 14:07:03 +
> > From: Thordur I Bjornsson 
> > 
> > On Fri, Sep 03, 2010 at 09:11:39AM +, Thordur I Bjornsson wrote:
> > > Hi gang,
> > 
> > Gabriel Kihlman spotted a small problem, swd_active was not
> > being incremented.
> > 
> > Here's an updated diff.
> 
> Hmm, bufq means that things are quiesced; is that what we want here?

Remember this is swap to file.

Since this would feed down to a file (via the vnode layer) which itself
would then be spat down onto disk (almost certainly via a bufq), it
functionally isn't much different other than using the new shiny api.
it'll quiesce a little higher, maybe, but practically it still should do
what is expected.

This is just speaking about the concept, i'll try and find time to look
at the diff properly later today.
-0-
-- 
186,282 miles per second:

It isn't just a good idea, it's the law!

DVACT_QUIESCE for inteldrm -- TESTING NEEDED

[Owain Ainsworth]

Now that DVACT_QUIESCE is in the tree I can send this diff out.

So, rev 1.67 of intagp (agp_i810.c) was added to deal with the problem
where stuff was bound for a software fallback while we were vt switched,
so we couldn't assume that the aperture was clear.

Turns out that the 855 at least does not like this (the !stolen bits of
the bar at least are write-only), and this caused a gpu lockup on any
suspend that used that activate handler.

So this diff fixes it in a more complete way:

Firstly revert 1.67 of agp_i810.c, secondly add a DVACT_QUIESCE handler
to inteldrm, and in it we do three things:

1) set a flag that causes any ioctl or pagefault to sleep until the flag
is cleared so that we don't end up with something doing the following
(for example:)
- bind object
- do another blocking operation in the same ioctl/fault
< suspend happens here, followed by resume>
- wake up assuming that the object is still bound and continue along our
merry way

Similar problems in wireless drivers can also be properly fixed with
DVACT_QUIESCE

2) Wait for all current entrypoints to finish (so that 1) is actually
effective we need to first quiesce our callers before we continue).

3) unbind everything that is in the gtt

On resume we clear the quiet flag, and everything can continue as
expected.

So far this behaves perfectly for me on: 855 (x40 in acpi mode), gm965
(x61s) and arrandale (x201) over multiple suspend cycles.

More testing on as much as possible is needed, though.

note: on apm machine you currently need to disable apm and run in acpi
mode in order to get to this code path for suspend, this will change
soon.

Ta,
-0-
-- 
Hartley's First Law:
You can lead a horse to water, but if you can get him to float
on his back, you've got something.

Index: dev/pci/agp_i810.c
===
RCS file: /cvs/src/sys/dev/pci/agp_i810.c,v
retrieving revision 1.68
diff -u -p -r1.68 agp_i810.c
--- dev/pci/agp_i810.c  31 Aug 2010 19:20:55 -  1.68
+++ dev/pci/agp_i810.c  31 Aug 2010 20:17:40 -
@@ -80,7 +80,6 @@ struct agp_i810_softc {
struct agp_gatt *gatt;
struct vga_pci_bar  *map;
struct vga_pci_bar  *gtt_map;
-   u_int32_t   *gtt_backup;/* saved gtt for suspend */
bus_dmamap_t scrib_dmamap;
bus_addr_t   isc_apaddr;
bus_size_t   isc_apsize;/* current aperture size */
@@ -299,14 +298,6 @@ agp_i810_attach(struct device *parent, s
goto out;
}
 
-   /*
-* Backup array to save gtt contents on suspend since we may lose
-* BAR contents. Most agp drivers do not have this problem since the
-* GTT ptes are in dma memory.
-*/
-   isc->gtt_backup = malloc(sizeof(*isc->gtt_backup) *
-   (isc->isc_apsize / 4096), M_AGP, M_NOWAIT | M_ZERO); 
-
switch (isc->chiptype) {
case CHIP_I810:
/* Some i810s have on-chip memory called dcache */
@@ -548,26 +539,13 @@ agp_i810_activate(struct device *arg, in
break;
}
 
+   /*
+* Anything kept in agp over a suspend/resume cycle (and thus by X
+* over a vt switch cycle) is undefined upon resume.
+*/
switch (act) {
-   case DVACT_SUSPEND:
-   /*
-* most agp-like drivers have the GTT ptes in dma memory, so
-* just need the setup to be repeated on resume.
-* in this case the gtt is held in a BAR, and thus we should
-* restore the data on resume to make sure that we
-* don't lose any state that we are depending on.
-*/
-   if (isc->gtt_backup != NULL) {
-   bus_space_read_region_4(bst, bsh, offset,
-   isc->gtt_backup, isc->isc_apsize / 4096);
-   }
-   break;
case DVACT_RESUME:
agp_i810_configure(isc);
-   if (isc->gtt_backup != NULL) {
-   bus_space_write_region_4(bst, bsh, offset,
-   isc->gtt_backup, isc->isc_apsize / 4096);
-   }
break;
}
 
Index: dev/pci/drm/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915_drv.c,v
retrieving revision 1.91
diff -u -p -r1.91 i915_drv.c
--- dev/pci/drm/i915_drv.c  12 Aug 2010 15:13:44 -  1.91
+++ dev/pci/drm/i915_drv.c  27 Aug 2010 17:30:03 -
@@ -65,6 +65,7 @@ void  inteldrm_attach(struct device *, st
 intinteldrm_detach(struct device *, int);
 intinteldrm_activate(struct device *, int);
 intinteldrm_ioctl(struct drm_device *, u_long, caddr_t, struct drm_file *);
+intinteldrm_doioctl(struct drm_device *, u_long, caddr_t, struct drm_file 
*);
 intinteldrm_intr(void *);
 intinteldrm_ironlake_intr(

Re: Looking for testers for a simple X test

[Owain Ainsworth]

On Tue, Aug 31, 2010 at 02:54:44PM +0200, Alf Schlichting wrote:
> On Tue, Aug 31, 2010 at 10:58:08AM +0300, Oleksii Zhmyrov wrote:
> > Hi,
> > 
> > I use OpenBSD -current on my desktop with Xfce4.
> > With Option "UseSIGIO" "false" xserver refuses to start at all.
> > 
> 
> Same here, segmentation fault. I am on a radeon card too, x1950 with
> a ca. 1 week old x11.
> 
> snipplet from Xorg.0.log:
> ...
> [3357823.938] (**) Keyboard0: CustomKeycodes disabled
> [3357823.938] (II) XINPUT: Adding extended input device "Keyboard0" (type: 
> KEYBOARD)
> [3357823.938] Segmentation fault at address 0x9b641ce
> [3357823.938]
> Fatal server error:
> [3357823.938] Caught signal 11 (Segmentation fault). Server aborting
> [3357823.938]
> [3357823.938]
> ...
> 
> I can attach the rest if it is needed.

I just fixed this, please could you try again with current sources and
confirm that things are now ok?

Ta,

-0-
-- 
I do not fear computers.  I fear the lack of them.
-- Isaac Asimov

Re: is lvds

[Owain Ainsworth]

On Sat, Aug 21, 2010 at 09:21:27PM +0300, Martynas Venckus wrote:
> every time x starts i get "is lvds".  i think this is a debugging
> leftover, since the official xf86-video-intel tree never had it?
> 
> Index: i830_display.c
> ===
> RCS file: /cvs/xenocara/driver/xf86-video-intel/src/i830_display.c,v
> retrieving revision 1.10
> diff -u -r1.10 i830_display.c
> --- i830_display.c18 Jul 2010 14:47:47 -  1.10
> +++ i830_display.c21 Aug 2010 19:15:38 -
> @@ -2309,7 +2309,6 @@
> 
>   switch (intel_output->type) {
>   case I830_OUTPUT_LVDS:
> - ErrorF("is lvds\n");
>   is_lvds = TRUE;
>   lvds_bits = intel_output->lvds_bits;
>   break;

Go for it. Useful for some thing for me, but i'll write up some
conditional debugging when I need it again.

-0-
-- 
When the government bureau's remedies don't match your problem, you
modify the problem, not the remedy.

suspend code for all !intagp agp drivers. NEEDS TESTING

[Owain Ainsworth]

Other than intagp, pretty much every agp driver is almost identical,
with only small details differing. Unlike intagp, the ptes are not in a
BAR, but in dma memory. so this diff just repeats every register setting
that we do on attach at resume (including aperture size ones incase this
was reset by PSS, calling that twice on attach is the only functional
change for attach time).

sthen@ has tested this on an x31 (or was it a t31... an old thinkpad
with a radeon and a 855 agp chipset), and it helped out. For one thing
it fixes the ``no X started, suspend, resume, startx, crash'' problem
for him.  All other agp bridges still need testing though.

This diff is NOT in snapshots and will not make release unless it gets a
decent amount of testing, so please test it and let me know what your
results are.

Cheers,
-0-

Index: dev/pci/agp_ali.c
===
RCS file: /cvs/src/sys/dev/pci/agp_ali.c,v
retrieving revision 1.11
diff -u -p -r1.11 agp_ali.c
--- dev/pci/agp_ali.c   8 Apr 2010 00:23:53 -   1.11
+++ dev/pci/agp_ali.c   4 Aug 2010 20:44:40 -
@@ -59,6 +59,8 @@ struct agp_ali_softc {
 };
 
 void   agp_ali_attach(struct device *, struct device *, void *);
+intagp_ali_activate(struct device *, int);
+void   agp_ali_configure(struct agp_ali_softc *);
 intagp_ali_probe(struct device *, void *, void *);
 bus_size_t agp_ali_get_aperture(void *);
 intagp_ali_set_aperture(void *sc, bus_size_t);
@@ -67,7 +69,8 @@ void  agp_ali_unbind_page(void *, bus_add
 void   agp_ali_flush_tlb(void *);
 
 struct cfattach aliagp_ca = {
-sizeof(struct agp_ali_softc), agp_ali_probe, agp_ali_attach
+sizeof(struct agp_ali_softc), agp_ali_probe, agp_ali_attach,
+NULL, agp_ali_activate
 };
 
 struct cfdriver aliagp_cd = {
@@ -100,7 +103,6 @@ agp_ali_attach(struct device *parent, st
struct agp_gatt *gatt;
struct agp_attach_args  *aa = aux;
struct pci_attach_args  *pa = aa->aa_pa;
-   pcireg_t reg;
 
asc->asc_tag = pa->pa_tag;
asc->asc_pc = pa->pa_pc;
@@ -128,16 +130,7 @@ agp_ali_attach(struct device *parent, st
}
asc->gatt = gatt;
 
-   /* Install the gatt. */
-   reg = pci_conf_read(asc->asc_pc, asc->asc_tag, AGP_ALI_ATTBASE);
-   reg = (reg & 0xff) | gatt->ag_physical;
-   pci_conf_write(asc->asc_pc, asc->asc_tag, AGP_ALI_ATTBASE, reg);
-   
-   /* Enable the TLB. */
-   reg = pci_conf_read(asc->asc_pc, asc->asc_tag, AGP_ALI_TLBCTRL);
-   reg = (reg & ~0xff) | 0x10;
-   pci_conf_write(asc->asc_pc, asc->asc_tag, AGP_ALI_TLBCTRL, reg);
-
+   agp_ali_configure(asc);
asc->agpdev = (struct agp_softc *)agp_attach_bus(pa, &agp_ali_methods,
asc->asc_apaddr, asc->asc_apsize, &asc->dev);
return;
@@ -171,6 +164,46 @@ agp_ali_detach(struct agp_softc *sc)
return (0);
 }
 #endif
+
+int
+agp_ali_activate(struct device *arg, int act)
+{
+   struct agp_ali_softc *asc = (struct agp_ali_softc *)arg;
+
+   switch (act) {
+   case DVACT_RESUME:
+   /*
+* all the pte state is in dma memory, so we just need to
+* put the information back.
+*/
+   agp_ali_configure(asc);
+   break;
+   }
+
+   return (0);
+}
+
+void
+agp_ali_configure(struct agp_ali_softc *asc)
+{
+   pcireg_t reg;
+
+   /*
+* reset size now just in case, if it worked before then sanity
+* checking will not fail
+*/
+   (void)agp_ali_set_aperture(asc, asc->asc_apsize);
+
+   /* Install the gatt. */
+   reg = pci_conf_read(asc->asc_pc, asc->asc_tag, AGP_ALI_ATTBASE);
+   reg = (reg & 0xff) | asc->gatt->ag_physical;
+   pci_conf_write(asc->asc_pc, asc->asc_tag, AGP_ALI_ATTBASE, reg);
+   
+   /* Enable the TLB. */
+   reg = pci_conf_read(asc->asc_pc, asc->asc_tag, AGP_ALI_TLBCTRL);
+   reg = (reg & ~0xff) | 0x10;
+   pci_conf_write(asc->asc_pc, asc->asc_tag, AGP_ALI_TLBCTRL, reg);
+}
 
 #define M 1024*1024
 
Index: dev/pci/agp_amd.c
===
RCS file: /cvs/src/sys/dev/pci/agp_amd.c,v
retrieving revision 1.15
diff -u -p -r1.15 agp_amd.c
--- dev/pci/agp_amd.c   8 Apr 2010 00:23:53 -   1.15
+++ dev/pci/agp_amd.c   4 Aug 2010 20:44:34 -
@@ -76,6 +76,8 @@ struct agp_amd_softc {
 };
 
 void   agp_amd_attach(struct device *, struct device *, void *);
+intagp_amd_activate(struct device *, int);
+void   agp_amd_configure(struct agp_amd_softc *);
 intagp_amd_probe(struct device *, void *, void *);
 bus_size_t agp_amd_get_aperture(void *);
 struct agp_amd_gatt *agp_amd_alloc_gatt(bus_dma_tag_t, bus_size_t);
@@ -85,7 +87,8 @@ void  agp_amd_unbind_page(void *, bus_siz
 void   agp_amd_flush_tlb(void *);
 
 struct cfattach amdagp_ca = {
-   sizeof(struct agp_amd_softc), agp_amd_pr

Re: [PATCH] intel(4) framebuffer

[Owain Ainsworth]

On Wed, Aug 04, 2010 at 11:52:46AM -0700, Dave Del Debbio wrote:
> This upstream patch courtesy of Chris Wilson  
> both limits tied pitches to 8192 on pre-i965 and enables switching from one
> VT to another without terminating your Xsession. :)

You must have a pretty big monitor to be hitting this, this wasn't
mentioned when I was told about your issues before.

I'll get this tested here (hadn't got to this patch in my upstream
trawling yet).

-0-
> 
> Tested on a Thinkpad X301 with an Aug 3 amd64 snapshot..  
> 
> Please see
>  
> http://cgit.freedesktop.org/mesa/drm/commit/?id=726210f87d558d558022f35bc8c839e798a19f0c
> 
> --- intel_bufmgr_gem.c.orig   Wed Aug  4 06:42:44 2010
> +++ intel_bufmgr_gem.cWed Aug  4 07:07:44 2010
> @@ -252,7 +252,7 @@
>   */
>  static unsigned long
>  drm_intel_gem_bo_tile_pitch(drm_intel_bufmgr_gem *bufmgr_gem,
> - unsigned long pitch, uint32_t tiling_mode)
> + unsigned long pitch, uint32_t *tiling_mode)
>  {
>   unsigned long tile_width;
>   unsigned long i;
> @@ -260,10 +260,10 @@
>   /* If untiled, then just align it so that we can do rendering
>* to it with the 3D engine.
>*/
> - if (tiling_mode == I915_TILING_NONE)
> + if (*tiling_mode == I915_TILING_NONE)
>   return ALIGN(pitch, 64);
>  
> - if (tiling_mode == I915_TILING_X)
> + if (*tiling_mode == I915_TILING_X)
>   tile_width = 512;
>   else
>   tile_width = 128;
> @@ -272,6 +272,14 @@
>   if (bufmgr_gem->gen >= 4)
>   return ROUND_UP_TO(pitch, tile_width);
>  
> + /* The older hardware has a maximum pitch of 8192 with tiled
> + * surfaces, so fallback to untiled if it's too large.
> + */
> + if (pitch > 8192) {
> + *tiling_mode = I915_TILING_NONE;
> + return ALIGN(pitch, 64);
> +}
> +
>   /* Pre-965 needs power of two tile width */
>   for (i = tile_width; i < pitch; i <<= 1)
>   ;
> @@ -679,7 +687,7 @@
>   stride = x * cpp;
>   stride = drm_intel_gem_bo_tile_pitch(bufmgr_gem, stride, *tiling_mode);
>   size = stride * aligned_y;
> - size = drm_intel_gem_bo_tile_size(bufmgr_gem, size, tiling_mode);
> + size = drm_intel_gem_bo_tile_size(bufmgr_gem, size, *tiling_mode);
>  
>   bo = drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags);
>   if (!bo)

-- 
One way to stop a runaway horse is to bet on him.

Re: (another) Intel driver change needs testing.

[Owain Ainsworth]

On Sun, May 23, 2010 at 10:15:21AM -0600, Ted Roby wrote:
> On Sun, May 23, 2010 at 9:55 AM, Owain Ainsworth wrote:
> 
> >
> >
> >
> > You mean that the build failed? or that the corruption happened?
> >
> >
> I mean the Xenocara and kernel builds fail, depending.
> I have used 'log' to replace i915_drv.h when it was changed as well.

to my knowledge the kernel should always have build during that range.
This means that you have done something wrong.

cvs up -D "" in sys/dev/pci/drm should be
sufficient.

> I got lucky catching the April 24 snapshot, and
> having the new May 22 snapshot posted.
> 
> With all the lib changes I have had troubles doing unsupported things
> like downgrades, or make builds from my own cvs copy.
> 
> 
> 
> 
> 
> > With two variables in play that doesn't tell me anywhere near as much as
> > I would need...
> >
> >
> 
> Please advise if I'm missing some other way to get a
> Xenocara  build from May 9, 10 and 11.

cd /usr/xenocara
cvs up -D "2010/05/9 "
make bootstrap
make obj
make build


-0-
-- 
We wish you a Hare Krishna
We wish you a Hare Krishna
We wish you a Hare Krishna
And a Sun Myung Moon!
-- Maxwell Smart

Re: (another) Intel driver change needs testing.

[Owain Ainsworth]

On Sun, May 23, 2010 at 09:09:56AM -0600, Ted Roby wrote:
> On Tue, May 18, 2010 at 5:45 PM, Owain Ainsworth wrote:
> 
> >
> > Can you please use cvs to bisect which commit caused the problem? (it is
> > only three commits, will not take long). It may help me fix it to know
> > what caused it.
> >
> >
> Sorry for the late reply.
> 
> I can confirm the following:
> 
> The problem does not exist with April 24 Snapshot, and
> i915_drv.c version:
> 1.71
> 1.72
> 1.73
> 1.74
> 
> The problem does exist with May 22 snapshot and i915_drv.c version 1.75
> 
> Sorry for the different builds, but version 1.74 fails on May 22 snapshot
> and version 1.75 fails on April 24 snapshot.

You mean that the build failed? or that the corruption happened?

With two variables in play that doesn't tell me anywhere near as much as
I would need...

-0-
-- 
The two most common things in the universe are hydrogen and stupidity.
-- Harlan Ellison

Re: (another) Intel driver change needs testing.

[Owain Ainsworth]

On Tue, May 18, 2010 at 05:42:09PM -0600, Ted Roby wrote:
> On Tue, May 18, 2010 at 5:25 PM, Owain Ainsworth wrote:
> 
> >
> > I was referring to which of the three drm commits on the 10th.
> >
> >
> Oh. They were all applied.
> Unfortunately, I built everything late that night and early on the 11th.
> So, I never determined which patch caused it.
> 
> I was watching with great hopefulness from the time you
> attached pineview  to the time I saw this:
> 
> Log message:
> unifdef INTELDRM_GEM.

Can you please use cvs to bisect which commit caused the problem? (it is
only three commits, will not take long). It may help me fix it to know
what caused it.

-0-
-- 
Life is like a bowl of soup with hairs floating on it.  You have to
eat it nevertheless.
-- Flaubert

Re: (another) Intel driver change needs testing.

[Owain Ainsworth]

On Tue, May 18, 2010 at 05:02:42PM -0600, Ted Roby wrote:
> >
> > There were three, could you confirm which one you mean?
> >
> >
> (II) Loading extension GLX
> (II) LoadModule: "intel"
> (II) Loading /usr/X11R6/lib/modules/
> drivers//intel_drv.so
> (II) Module intel: vendor="X.Org Foundation"
> compiled for 1.6.5, module version = 2.9.1
> Module class: X.Org Video Driver
> ABI class: X.Org Video Driver, version 5.0

I was referring to which of the three drm commits on the 10th.

> 
> 
> 
> > Also, can you please retest with current, i commited a diff today that
> > may help.
> >
> >
> If you mean sys/dev/pci/drm/i915_drv.c
> already tested when I saw it.
> No change.

Damn.

-0-
-- 
The first myth of management is that it exists.  The second myth of
management is that success equals skill.
-- Robert Heller

Re: (another) Intel driver change needs testing.

[Owain Ainsworth]

On Tue, May 18, 2010 at 07:40:23AM -0700, J.C. Roberts wrote:
> On Mon, 17 May 2010 22:16:54 +0100 Owain Ainsworth
>  wrote:
> > For those of you new here, or termnally adsent minded, instructions
> > follow:
> > 
> 
> You've got be careful with those "termnally adsent" folks. ;)

Feh, typo ;).

> 
> With the 845G and a minimal xorg.conf (only "NoTrapSignals") I get
> the expected:
> 
>   (II) intel(0): DPMS enabled
>   (==) intel(0): Intel XvMC decoder disabled
>   (II) intel(0): Set up overlay video
>   (II) intel(0): direct rendering: DRI2 Enabled
> 
> When using:
>   Option "XvMC" "true"
> 
> It seems to become enabled, but really doesn't do anything.
> 
>   (II) intel(0): DPMS enabled
>   (==) intel(0): Intel XvMC decoder disabled
>   (II) intel(0): Set up overlay video
>   (II) intel(0): direct rendering: DRI2 Enabled

All that actually does is say that the option is turned on (defaults to
yes for 965+, no for the rest). an extra message from the decoding code
comes up in the case where it actually does something (915+ only, i'm
afraid). It is a rather stupid message, I agree.

> 
> Trying to test xvmc with `mplayer -vo xvmc` just results in:
> 
>   Error opening/initializing the selected video_out (-vo) device.

mplayer in ports doesn't support xvmc. I really ought to check what
does. Then again, it may not be hard to enable.

Thanks for testing (to everyone who has done so so far).

-0-
-- 
When the speaker and he to whom he is speaks do not understand, that is
metaphysics.
-- Voltaire

Re: (another) Intel driver change needs testing.

[Owain Ainsworth]

On Tue, May 18, 2010 at 11:01:29AM -0600, Ted Roby wrote:
> On Tue, May 18, 2010 at 8:40 AM, J.C. Roberts wrote:
> 
> > On Mon, 17 May 2010 22:16:54 +0100 Owain Ainsworth
> >  wrote:
> > > For those of you new here, or termnally adsent minded, instructions
> > > follow:
> > >
> >
> > You've got be careful with those "termnally adsent" folks. ;)
> >
> >
> absinthe-minded?
> 

Hard to get decent Absinthe in the UK, i'm afraid.

> >
> > Whether enabled or disabled in xorg.conf, (so far) it seems to have no
> > effect on the occasional/intermittent screen corruption bug seen by
> > dcoppa (915GM) and me (845G).
> >
> >
> I have a corruption artifact that affects my pidgin IM window, and
> pop-up windows like my mozilla-firefox URL history in the address bar.
> 
> It did NOT exist in a April 28 snapshot build with GEM kernel and
> intel-current.tgz drivers. I never experienced this artifact until the
> GEM commit on May 10th.

There were three, could you confirm which one you mean?

Also, can you please retest with current, i commited a diff today that
may help.

-0-
-- 
f u cn rd ths, itn tyg h myxbl cd.

(another) Intel driver change needs testing.

[Owain Ainsworth]

The diff found at http://xenocara.org/xvmc.diff could do with some
testing.

This is some stuff that I didn't backport back to 2.9.1 when I did the
intial intel driver backport pile. This contains a huge cleanup of the
XVMC code (and enabled it on 965+ by default, it is still there by an
option on lower). Otherwise there are a few small changes, but the vast
majority of it is xvmc.

With this the intel driver renderer is equal to just after intel 2.11
upstream.  Please test and report to myself and matthieu@, good feedback
or bad, when i've got this and one more thing out of the way I plan to
work on radeon dri2.

For those of you new here, or termnally adsent minded, instructions
follow:

make sure your xenocara tree is up to date.

$ cd /usr/xenocara/driver/xf86-video-intel
$ patch -E < /path/to/xvmc.diff
$ make -f Makefile.bsd-wrapper obj
$ make -f Makefile.bsd-wrapper build

restart X and robert is your mother's brother.

Cheers,

-0-
-- 
Abstainer, n.:
A weak person who yields to the temptation of denying himself a
pleasure.
-- Ambrose Bierce, "The Devil's Dictionary"

Re: New intel X driver requires testing.

[Owain Ainsworth]

On Fri, Apr 16, 2010 at 10:47:50PM -0700, russell wrote:
> Owain Ainsworth wrote:
> >On Fri, Apr 16, 2010 at 01:35:53PM -0700, russell wrote:
> >>Well it compiled, and runs, dmesg + Xorg.log follows. only Thing I
> >>"Think" i noticed is a sort of slower screen update, when updating
> >>large parts of the screen I get this crawl of updating segments down
> >>screen.
> >>
> >>regarding the kernel: GENERIC kernel with ath patches(poking around,
> >>trying to get my radio working)
> >>
> >>(EE) intel(0): [drm] Failed to detect GEM.  Kernel 2.6.28 required.
> >
> >You did not read the message that introduced this driver. It said that
> >you must have "option INTELDRM_GEM" in your kernel config. If you get
> >that message, then you did not do this.
> >
> >-0-
> 
> Well I feel stupid, sorry about that, I grabbed the wrong log file.
> because yeah the first time I added "option INTEMDRM_GEM" I was writing
> a detailed message on what I did, why it did not work etc... at
> which point I found my typo, corrected it, and everything ran just
> as it should. I then proceeded to include the first nonworking
> Xorg.log *sigh*.

Heh, happens to everyone sooner or later.

> 
> well if it is worth anything to you here is the correct Xorg.log
> I was unable verify that it was in fact using the GEM driver interface
> I assume it is as that is the code I put in and X failed to start
> when I  had the wrong option line in the kernel config.

Yes, that looks much better. So it is mostly ok?

-0-
-- 
"Here at the Phone Company, we serve all kinds of people; from
Presidents and Kings to the scum of the earth ..."

Re: New intel X driver requires testing.

[Owain Ainsworth]

On Fri, Apr 16, 2010 at 01:35:53PM -0700, russell wrote:
> Well it compiled, and runs, dmesg + Xorg.log follows. only Thing I
> "Think" i noticed is a sort of slower screen update, when updating
> large parts of the screen I get this crawl of updating segments down
> screen.
> 
> regarding the kernel: GENERIC kernel with ath patches(poking around,
> trying to get my radio working)
> 
> (EE) intel(0): [drm] Failed to detect GEM.  Kernel 2.6.28 required.

You did not read the message that introduced this driver. It said that
you must have "option INTELDRM_GEM" in your kernel config. If you get
that message, then you did not do this.

-0-
-- 
Alone, adj.:
In bad company.
-- Ambrose Bierce, "The Devil's Dictionary"

New intel X driver requires testing.

[Owain Ainsworth]

The tarball that may be found at http://xenocara.org/intel-current.tgz
contains an update to the intel 2.9.1 driver (the last one that
supported userland modesetting) with a load of backports for bugfixes
and performance improvements from drivers up to 2.11.

In order to test this, you will need INTELDRM_GEM defined in your kernel
option INTELDRM_GEM in your kernel config, or a patch to i915_drv.h in
/sys/dev/pci/drm will suffice) since this driver does not support
operation without kernel memory mamangement (it tries, but it seems
broken in many places).

build procedure assuming you have already checked out xenocara:

cd /usr/xenocara/driver
mv xf86-video-intel xf86-video-intel.cvs
tar xzf /path/to/intel-current.tgz
cd xf86-video-intel
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper build

Then reboot into a GEM kernel to test. Please test this if you have
access to the hardware because soon GEM will be the default so anything
that is broken needs to be fixed soon. If you don't test and your stuff
breaks you can consider it to be your fault.

Please let myself and matthieu@ know of any testing results, positive or
negative.

Cheers,

-0-
--
Cleveland still lives.  God must be dead.

Re: drm for r600 and r700

[Owain Ainsworth]

On Sat, Apr 10, 2010 at 02:24:43AM +0300, Sviatoslav Chagaev wrote:
> On Wed, 24 Mar 2010 02:28:24 +
> Owain Ainsworth  wrote:
> 
> > This diff doesn't have all of the pcidevs that it could have (if it
> > doesn't attach on your hardware send me the output of pcidump -v and I
> > will send an extra diff). However, this gives radeondrm(4) the right
> > bits to work on newer (r600 and r700) chipsets.
> > 
> > Please test and report back to me. It should give you 2d acceleration and
> > XVideo.
> > 
> > Cheers,
> > -0-
> 
> (dmesg is attached in the end)
> 
> 
> I installed the latest snapshot of amd64, then
> cd /usr/src
> cvs up
> added 4850 to radeon_drv.c

May I see the diff for that, please? to check it was correct. I will
then commit it.

>and disabled a driver, called 'udl' in
> GENERIC, because it depended on some .c files which should've been
> located in a nonexistent directory (dev/videomode) and compiled an MP
> kernel.

Your kernel tree is hosed. videomode does exist, as does udl.

>
> snip radeonhd X log and explanation
>
>

Unless it currently fixes a bug in the radeon driver for you, I would
generally recommend that everyone avoid radeonhd. It is essentially dead
upstream will all developement going into the radeon driver. Our in tree
version of radeon is a little old but hopefully will be updated in the
near future.

> Then I tried putting 'radeon' in /etc/X11/xorg.conf and this time X
> came up with no errors, these are the messages that were outputed on
> the terminal (somewhat different from Xorg.log, say the line 'unknown
> chip id 0x9442' doesn't appear in Xorg.log):
> 

Good.

> Each time I run xrandr, X outputs the following two lines to terminal:
> 
> Dac detection success
> Unhandled monitor type 0

spam, just ignore. would be nice to shut it up though.

> 
> Thank you for your work!
> Feel free to request any additional information, tests, log files etc.

You are welcome.

-0-
-- 
Mustgo, n.:
Any item of food that has been sitting in the refrigerator so
long it has become a science project.
-- Sniglets, "Rich Hall & Friends"

Re: pmemrange recommit (ok request)

[Owain Ainsworth]

On Sun, Mar 28, 2010 at 04:51:41PM -0700, J.C. Roberts wrote:
> On Thu, 25 Mar 2010 07:50:15 + "Owain G. ainsworth"
>  wrote:
> 
> > Ifit uses dma (grep the driver for isa_dmastart) then it would be
> > useful. current tests imply it is ok though.
> > --
> 
> Unfortunately, the ISA network cards I have here 3C509B (ep(4) isapnp)
> don't use isa_dmastart. Well, more accurately, the ISA network cards I
> can actually find. ;)
> 
> The only problem I've found is the network card occasionally stops
> working altogether, but I *seriously* doubt it has anything to do with
> either patch. It's actually a (formerly) well known problem with the
> 3C509B when using pnpisa mode:
> 
> http://www.holland-consulting.net/tech/ocep/#3c509
> 
> If I turn off the pnpisa on the card, the problem should go away.
> 
> 
> With the help of jakemsr@ I managed to get the ancient SoundBlaster ISA
> sb(4) cards working, and they do use isa_dmastart. They work very well.
> At the moment, Dave Brubeck's album "Time Out" is playing nicely enough
> via `aucat -l -m play` and `cdio cdplay` without any serious problems.
> 
> To add a bit of pressure, I tried formatting the floppy disk, mounting
> it, copying and deleting data *WHILE* the cd was playing. At worst, you
> might get a tiny, short (< 1 sec) pop or pause in the playback when
> also formatting a floppy diskette.
> 
> I believe I saw the commit log mentioning this has been committed, so I
> was wondering what further ISA devices should be tested (assuming they
> can be found)?

Enough testing has been done to show that this at least works. On the
other hand, pretty much anything that can be tested with pmemrange may
be a good idea.

Thanks for all the effort you've put in!

-0-
-- 
Everything you know is wrong!

isa bus_dma madness

[Owain Ainsworth]

Hi,

If you are testing pmemrange (you really should be), please also run
with this diff. It fixes problems with isadma on i386.

This is technically three diffs squashed together (bad oga! I know, but
I need to do real work and this should fix pmemrange).

1) when you have a wrapper function in a dmatag that just calls the
_bus_dmamem original, you don't need it, just put the original function
in the tag

2) don't trunc_page the avail_end/ISA_BOUNCE_THRESHOLD stuff (see icb
for a discussion of why this is wrong about 00:00 gmt). make i386 and
amd64 both do this the same (the amd64 way is cleaner and makes the
third diff actually possible without a lot of pain). just do
dmamem_alloc_range(0, threshold) and if that fails do a alloc_range(0,
-1) and assume we'll bounce to pick up the pieces. Also using avail_end
for alloc_range is not nice (miod has been trying to avoid these abuses
iirc), so just use (paddr_t)-1, which is equivalent since you want "any"
memory.

3) now this is the funny one. consider point 2. then considering why
using the same bloody function to allocate your bouncebuffer is just
f'ing wrong. instead allocate with alloc_range(0, threshold) to make
sure that our bouncebuffer is actually uner 16megs.

Cheers,
-0-


Index: arch//amd64/isa/isa_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/isa/isa_machdep.c,v
retrieving revision 1.20
diff -u -p -r1.20 isa_machdep.c
--- arch//amd64/isa/isa_machdep.c   10 Mar 2009 15:03:17 -  1.20
+++ arch//amd64/isa/isa_machdep.c   24 Mar 2010 01:06:52 -
@@ -128,13 +128,6 @@ void   _isa_bus_dmamap_sync(bus_dma_tag_t,
 
 int_isa_bus_dmamem_alloc(bus_dma_tag_t, bus_size_t, bus_size_t,
bus_size_t, bus_dma_segment_t *, int, int *, int);
-void   _isa_bus_dmamem_free(bus_dma_tag_t,
-   bus_dma_segment_t *, int);
-int_isa_bus_dmamem_map(bus_dma_tag_t, bus_dma_segment_t *,
-   int, size_t, caddr_t *, int);
-void   _isa_bus_dmamem_unmap(bus_dma_tag_t, caddr_t, size_t);
-paddr_t_isa_bus_dmamem_mmap(bus_dma_tag_t, bus_dma_segment_t *,
-   int, off_t, int, int);
 
 int_isa_dma_check_buffer(void *, bus_size_t, int, bus_size_t,
struct proc *);
@@ -158,10 +151,10 @@ struct bus_dma_tag isa_bus_dma_tag = {
_isa_bus_dmamap_unload,
_isa_bus_dmamap_sync,
_isa_bus_dmamem_alloc,
-   _isa_bus_dmamem_free,
-   _isa_bus_dmamem_map,
-   _isa_bus_dmamem_unmap,
-   _isa_bus_dmamem_mmap,
+   _bus_dmamem_free,
+   _bus_dmamem_map,
+   _bus_dmamem_unmap,
+   _bus_dmamem_mmap,
 };
 #endif /* NISADMA > 0 */
 
@@ -676,52 +669,10 @@ _isa_bus_dmamem_alloc(bus_dma_tag_t t, b
 
/* Otherwise try anywhere (we'll bounce later) */
error = _bus_dmamem_alloc_range(t, size, alignment, boundary,
-   segs, nsegs, rsegs, flags, 0, trunc_page(avail_end));
+   segs, nsegs, rsegs, flags, (paddr_t)0, (paddr_t)-1);
return (error);
 }
 
-/*
- * Free memory safe for ISA DMA.
- */
-void
-_isa_bus_dmamem_free(bus_dma_tag_t t, bus_dma_segment_t *segs, int nsegs)
-{
-
-   _bus_dmamem_free(t, segs, nsegs);
-}
-
-/*
- * Map ISA DMA-safe memory into kernel virtual address space.
- */
-int
-_isa_bus_dmamem_map(bus_dma_tag_t t, bus_dma_segment_t *segs, int nsegs,
-size_t size, caddr_t *kvap, int flags)
-{
-
-   return (_bus_dmamem_map(t, segs, nsegs, size, kvap, flags));
-}
-
-/*
- * Unmap ISA DMA-safe memory from kernel virtual address space.
- */
-void
-_isa_bus_dmamem_unmap(bus_dma_tag_t t, caddr_t kva, size_t size)
-{
-
-   _bus_dmamem_unmap(t, kva, size);
-}
-
-/*
- * mmap(2) ISA DMA-safe memory.
- */
-paddr_t
-_isa_bus_dmamem_mmap(bus_dma_tag_t t, bus_dma_segment_t *segs, int nsegs,
-off_t off, int prot, int flags)
-{
-
-   return (_bus_dmamem_mmap(t, segs, nsegs, off, prot, flags));
-}
-
 /**
  * ISA DMA utility functions
  **/
@@ -795,18 +746,19 @@ _isa_dma_alloc_bouncebuf(bus_dma_tag_t t
int error = 0;
 
cookie->id_bouncebuflen = round_page(size);
-   error = _isa_bus_dmamem_alloc(t, cookie->id_bouncebuflen,
+   error = _bus_dmamem_alloc_range(t, cookie->id_bouncebuflen,
NBPG, map->_dm_boundary, cookie->id_bouncesegs,
-   map->_dm_segcnt, &cookie->id_nbouncesegs, flags);
+   map->_dm_segcnt, &cookie->id_nbouncesegs, flags,
+   0, ISA_DMA_BOUNCE_THRESHOLD);
if (error)
goto out;
-   error = _isa_bus_dmamem_map(t, cookie->id_bouncesegs,
+   error = _bus_dmamem_map(t, cookie->id_bouncesegs,
cookie->id_nbouncesegs, cookie->id_bouncebuflen,
(caddr_t *)&cookie->id_bouncebuf, flags);
 
  out:
if (error) {
-   _isa_bus_dmamem_free(t, cookie->id_bouncesegs,
+   _bus_dmamem_f

Re: mprotect(2) misbehaves when len == 0?

[Owain Ainsworth]

On Fri, Feb 12, 2010 at 03:21:33PM +, Jason McIntyre wrote:
> On Fri, Feb 12, 2010 at 02:01:26PM +0000, Owain Ainsworth wrote:
> > 
> > saying that no action is taken does imply that it is not an error.
> > 
> > -0-
> > 
> > diff follows:
> > 
> > Index: sys/mprotect.2
> > ===
> > RCS file: /cvs/src/lib/libc/sys/mprotect.2,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 mprotect.2
> > --- sys/mprotect.2  31 May 2007 19:19:33 -  1.14
> > +++ sys/mprotect.2  12 Feb 2010 14:00:46 -
> > @@ -55,7 +55,7 @@ through
> >  (inclusive).
> >  If
> >  .Fa len
> > -is 0, then action will be taken on the page that contains
> > +is 0, then no action will be taken on the page that contains
> 
> personally i would be tempted to simplify this to:
> 
>   If
>   .Fa len
>   is 0, no action is taken...
> 
> jmc

Works for me.

-0-
-- 
Those who in quarrels interpose, must often wipe a bloody nose.

Re: mprotect(2) misbehaves when len == 0?

[Owain Ainsworth]

On Fri, Feb 12, 2010 at 08:44:25AM +, Jason McIntyre wrote:
> On Fri, Feb 12, 2010 at 11:27:35AM +0300, Vadim Zhukov wrote:
> > > >
> > > > Maybe it's better to say that this is not treated as error too? See
> > > > the patch at the end of this letter.
> > >
> > > i don;t know this stuff. but why would you expect an error in this
> > > case? if we are saying that if len is 0, then this happens, why do
> > > we need to say it doesn;t generate an error?
> > 
> > For example, another memory management function manual page, malloc(3), 
> > explicitly specifies that it's not an error to specify zero in "size" 
> > parameter.
> > 
> 
> can you quote me the bit of text? i cannot immediately see it.
> 
> > Such declaration make saves time from test compilation that proves "it's 
> > not an error". I think this is job for manual - avoiding such testing.
> > 
> 
> my point is that if we say that if len is 0 then no action is taken, it
> is implicit that it is not an error to do so. so again i'm asking, is it
> important to do so? could someone reading that page really think well,
> no action is taken, but will it cause an error?

I am with jmc here.

saying that no action is taken does imply that it is not an error.

-0-

diff follows:

Index: sys/mprotect.2
===
RCS file: /cvs/src/lib/libc/sys/mprotect.2,v
retrieving revision 1.14
diff -u -p -r1.14 mprotect.2
--- sys/mprotect.2  31 May 2007 19:19:33 -  1.14
+++ sys/mprotect.2  12 Feb 2010 14:00:46 -
@@ -55,7 +55,7 @@ through
 (inclusive).
 If
 .Fa len
-is 0, then action will be taken on the page that contains
+is 0, then no action will be taken on the page that contains
 .Fa addr .
 .Pp
 Not all implementations will guarantee protection on a page basis;
ksh: cd: /usr/src/sys/lib/libc - No such file or directory