All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Qemu-devel] SPARC iommu mapping
From: Joerg Platte @ 2006-04-05 18:25 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <BAY104-F2926FE4988EEFCC93C59DFFFCB0@phx.gbl>

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

Am Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl:
Hi!

> I don't have any better documentation either, I just coded against what
> Proll and Linux expect. But the theory of operation is simple. Much like

OK, I thought I was just too stupid to find good documentation :-)

> how the MMU translates CPU's virtual addresses to physical addresses for
> memory, IOMMU translates device virtual memory accesses to physical
> addresses. The VA to PA entries are found in a simple page table.

That's what I read from qemu's iommu functions.

> In the case of not finding a valid translation entry, IOMMU can't fault the
> device like normal MMU can easily fault the CPU. I don't know what should
> happen then, probably put the address to AFAR register and raise some
> interrupt, while the device (for example Ethernet controller) waiting for
> the data suffers in limbo. I think it would be strange for an OS to rely on
> this, so I guess it's a bug somewhere else. My guess for the valid bit is
> that it's used in a real IOMMU to select the entries that will be loaded to
> its internal translation buffer.

Maybe. 

> The DMA controllers for both ESP and Lance are within the same page. This
> means that in Qemu, DMA controller register accesses for either of them go
> to just one of these. It just happens to work, but maybe this causes the
> problem. You could try to confirm this by enabling also DEBUG_LANCE and see
> if there is troublesome activity in the Lance direction near the bad
> accesses.

Hmmm, I don't use the network. Just disk access. But I'll check this.

> Can you provide a test case so that I could try it as well?

I'm using the two attached programs. writetest is used inside qemu to directly 
write to /dev/sda (with "writetest /dev/sda"). readtest can then be used 
outside qemu to check the written data ("readtest imagefile"). 

Additionally, I logged the translated virtual address as mentioned in my first 
mail. The kernel is 2.6.13. 

regards,
Jörg

[-- Attachment #2: readtest.c --]
[-- Type: text/x-csrc, Size: 671 bytes --]

#include <stdio.h>


int main(int argc, char**argv) {
  FILE *fp;
  unsigned char buffer[4];
  unsigned int i,j;
  unsigned int doprint=1;
  unsigned int d=0;
  if ((fp=fopen(argv[1], "r"))) {
    for (i=0; i<10000000; i+=4) {
      if (fread(&buffer, 4, 1, fp)!=1) {
        printf("error writing at byte %d\n", i);
        break;
      }
      d=0;
      for(j=0;j<4; j++) {
        if (buffer[3-j]!=((i>>(j*8))&0xff)) {
          if (doprint) {
            printf("data differs at address %08x\n", i);
          }
          d=1;
          break;
        }
      }
      if (d) {
        doprint=0;
      } else {
        doprint=1;
      }
    }
    fclose(fp);
  }
}

[-- Attachment #3: writetest.c --]
[-- Type: text/x-csrc, Size: 289 bytes --]

#include <stdio.h>


int main(int argc, char**argv) {
  FILE *fp;
  unsigned int i;
  if ((fp=fopen(argv[1], "w"))) {
    for (i=0; i<10000000; i+=4) {
      if (fwrite(&i, 4, 1, fp)!=1) {
        printf("error writing at byte %d\n", i);
        break;
      }
    }
    fclose(fp);
  }
}

^ permalink raw reply

* [Bluez-devel] Re: how to compile and install bluez
From: Jose Antonio Rodríguez @ 2006-04-05 18:20 UTC (permalink / raw)
  To: bluez-devel

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

Sorry,

It doesn't consist in transmit video streamming, it consist in doing a
videoconference with skype

thanks for your help

[-- Attachment #2: Type: text/html, Size: 154 bytes --]

^ permalink raw reply

* CLUSTERIP refuses to answer ARP
From: Robert LeBlanc @ 2006-04-05 18:18 UTC (permalink / raw)
  To: netfilter

I just compiled a 2.6.16.1 kernel and installed iptables 1.3.5 and
CLUSTERIP is still not responding to ARP requests. Am I missing
something here?

iptables -A INPUT -i eth1 -d 192.168.0.10 -j CLUSTERIP --new --hashmode
sourceip --clustermac 01:23:45:67:89:AB --total-nodes 2 --local-node 1
echo "+2" > /proc/net/ipt_CLUSTERIP/192.168.0.10

Robert LeBlanc


^ permalink raw reply

* Re: Throttling NAT interface
From: Casey Scott @ 2006-04-05 18:17 UTC (permalink / raw)
  To: Randy Grimshaw; +Cc: netfilter

Do you think that REJECTing such packets will cause the sending 
device to reduce its transmitting speed? 

Casey

----- Original Message -----
From: Randy Grimshaw <rgrimsha@syr.edu>
To: casey@phantombsd.org
Cc: netfilter@lists.netfilter.org
Sent: Wednesday, April 5, 2006 11:11:16 AM GMT-0800
Subject: Re: Throttling NAT interface

I hope this isn't evasive, but I am still learning this stuff too.

The packets that don't match - i.e. exceed the threshold - will continue down the chain.
You can do a lot of different things with those packets as you need. You can probably match the behavior of tc if that is what you want.

<><Randy


<><Randall Grimshaw
Room 203 Machinery Hall
Syracuse University
Syracuse, NY   13244
315-443-5779
rgrimsha@syr.edu

>>> Casey Scott <casey@phantombsd.org> 4/5/2006 1:35 PM >>>
Thanks for the response. Will using iptables in that 
manner cause the firewall to just drop the packets that 
arrived after the limit has been reached? I don't want 
to have to drop packets that have already used up 
bandwidth getting to the machine, and making matters 
worse by requiring the packets to be sent again. 

Thanks,
Casey
----- Original Message -----
From: Randy Grimshaw <rgrimsha@syr.edu>
To: netfilter@lists.netfilter.org, casey@phantombsd.org 
Sent: Wednesday, April 5, 2006 10:27:48 AM GMT-0800
Subject: Re: Throttling NAT interface

Our throttle is really in the other direction but the 
idea may work for you.
iptables [traffic pattern spec] -m limit --limit 
40/second --limit-burst 60 -j LEVEL2
LEVEL2 is a user defined chain that specifies other 
restrictions or in your case NAT translations. 
The point is that you can match the traffic patterns 
that you need before applying the limit match.
hope this is helpful.
<><Randy


<><Randall Grimshaw
Room 203 Machinery Hall
Syracuse University
Syracuse, NY   13244
315-443-5779
rgrimsha@syr.edu 

>>> Casey Scott <casey@phantombsd.org> 4/5/2006 12:44 PM >>>
The gist of what I need to do is restrict the rate of
 off-network traffic coming in through a host. The host
is providing basic NAT to an internal network. I have
gotten pretty close to what I need to do with iptables
 and tc. The problem is that when an interface is throttle
 with tc, the source of the traffic doesn't matter. I don't
 want to throttle local traffic, just traffic coming through
 the machine from a WAN. The next step was to add another
NIC to the machine. Something like this:

eth0:  <local IP1>
eth1: <WAN IP>
eth2: <local IP2>

The problem is that even if  traffic destined to be routed
off network comes into eth2, which is throttle via tc, the
return traffic comes back through eth0. Since tc (tbf filter)
just controls the transmitting of an interface, I need to
force the NAT traffic to use eth2. Traffic that is meant to
stay local can use eth0. Is possible to do something like this?
How can I this host to only eth2 for NAT even though both eth0
and eth2 are in the same network?  eth0 is not throttled, which
 is why local traffic needs to use it.

TIA,
Casey






^ permalink raw reply

* Some ideas on lazy migration with swapless migration
From: Christoph Lameter @ 2006-04-05 18:17 UTC (permalink / raw)
  To: Lee Schermerhorn
  Cc: linux-mm, lhms-devel, Hirokazu Takahashi, Marcelo Tosatti,
	KAMEZAWA Hiroyuki
In-Reply-To: <1144256328.5203.36.camel@localhost.localdomain>

I think it is possible to do lazy migration without having to resort to a 
migration cache by either

A. Forbidding write to the page. The corresponding invocation to
   to do_wp_page() on a write attempt can then be used to migrate the 
   page. However, this would only work for write attempts.

B. Clear the present bit. The corresponding invocation of do_swap_page 
   may check for the type of pte and do the lazy migration and then set 
   the present bit again.

Hmm... B. would be an even better way to replace SWP_TYPE_MIGRATION and 
not use the swap code at all (which would simply take a lock on the page 
and redo the fault after releasing the lock) but it would require some 
work to get arch support for clearing and setting the present bit. 
However, there are only a few arches supporting NUMA and migration. So it 
should be doable.

Maybe the idea with the present bit can be used to further simplify 
migration:

1. Before migration clear all the present bits which guarantees
   that the faults will stall in do_swap_page() since the page is
   locked. No need to reduce the mapcount since the ptes are still there
   and can be switched back to working condition by do_swap_page().

2. do_swap_page() will lock the page (and therefore stall during 
   migration). After the page lock is obtained we check the present bit if
   it is now set then redo the fault. If not then do lazy migration if 
   needed and set the bit.

3. Migration will move the page and then replace ptes with cleared 
   present bits with ptes pointing to the new page with the present bit 
   enabled. 

Since we do not reduce the mapcount, we can use that mapcount to verify 
that it is still safe to get to the corresponding anonymous vma for 
anonymous pages. Some portions of the vm would have to be fixed up to know 
how to deal with valid ptes that are not present (fork and unmap code).

For file backed pages we would not have to remove the references anymore. 
We can migrate in the same way as the anonymous pages. We just need to 
make sure to first change the mapping. That would be an important feature 
for us because it preserves the page state in a better way. We could also 
preserve the dirty bits and accessed bits in the pte.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [Qemu-devel] SPARC iommu mapping
From: Joerg Platte @ 2006-04-05 18:14 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <BAY104-F2926FE4988EEFCC93C59DFFFCB0@phx.gbl>

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

Am Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl:
Hi!

> I don't have any better documentation either, I just coded against what
> Proll and Linux expect. But the theory of operation is simple. Much like

OK, I thought I was just too stupid to find good documentation :-)

> how the MMU translates CPU's virtual addresses to physical addresses for
> memory, IOMMU translates device virtual memory accesses to physical
> addresses. The VA to PA entries are found in a simple page table.

That's what I read from qemu's iommu functions.

> In the case of not finding a valid translation entry, IOMMU can't fault the
> device like normal MMU can easily fault the CPU. I don't know what should
> happen then, probably put the address to AFAR register and raise some
> interrupt, while the device (for example Ethernet controller) waiting for
> the data suffers in limbo. I think it would be strange for an OS to rely on
> this, so I guess it's a bug somewhere else. My guess for the valid bit is
> that it's used in a real IOMMU to select the entries that will be loaded to
> its internal translation buffer.

Maybe. 

> The DMA controllers for both ESP and Lance are within the same page. This
> means that in Qemu, DMA controller register accesses for either of them go
> to just one of these. It just happens to work, but maybe this causes the
> problem. You could try to confirm this by enabling also DEBUG_LANCE and see
> if there is troublesome activity in the Lance direction near the bad
> accesses.

Hmmm, I don't use the network. Just disk access. But I'll check this.

> Can you provide a test case so that I could try it as well?

I'm using the two attached programs. writetest is used inside qemu to directly 
write to /dev/sda (with "writetest /dev/sda"). readtest can then be used 
outside qemu to check the written data ("readtest imagefile"). 

Additionally, I logged the translated virtual address as mentioned in my first 
mail. The kernel is 2.6.13. 

regards,
Jörg

[-- Attachment #2: readtest.c --]
[-- Type: text/x-csrc, Size: 671 bytes --]

#include <stdio.h>


int main(int argc, char**argv) {
  FILE *fp;
  unsigned char buffer[4];
  unsigned int i,j;
  unsigned int doprint=1;
  unsigned int d=0;
  if ((fp=fopen(argv[1], "r"))) {
    for (i=0; i<10000000; i+=4) {
      if (fread(&buffer, 4, 1, fp)!=1) {
        printf("error writing at byte %d\n", i);
        break;
      }
      d=0;
      for(j=0;j<4; j++) {
        if (buffer[3-j]!=((i>>(j*8))&0xff)) {
          if (doprint) {
            printf("data differs at address %08x\n", i);
          }
          d=1;
          break;
        }
      }
      if (d) {
        doprint=0;
      } else {
        doprint=1;
      }
    }
    fclose(fp);
  }
}

[-- Attachment #3: writetest.c --]
[-- Type: text/x-csrc, Size: 289 bytes --]

#include <stdio.h>


int main(int argc, char**argv) {
  FILE *fp;
  unsigned int i;
  if ((fp=fopen(argv[1], "w"))) {
    for (i=0; i<10000000; i+=4) {
      if (fwrite(&i, 4, 1, fp)!=1) {
        printf("error writing at byte %d\n", i);
        break;
      }
    }
    fclose(fp);
  }
}

^ permalink raw reply

* Re: Throttling NAT interface
From: Randy Grimshaw @ 2006-04-05 18:11 UTC (permalink / raw)
  To: casey; +Cc: netfilter

I hope this isn't evasive, but I am still learning this stuff too.

The packets that don't match - i.e. exceed the threshold - will continue down the chain.
You can do a lot of different things with those packets as you need. You can probably match the behavior of tc if that is what you want.

<><Randy


<><Randall Grimshaw
Room 203 Machinery Hall
Syracuse University
Syracuse, NY   13244
315-443-5779
rgrimsha@syr.edu

>>> Casey Scott <casey@phantombsd.org> 4/5/2006 1:35 PM >>>
Thanks for the response. Will using iptables in that 
manner cause the firewall to just drop the packets that 
arrived after the limit has been reached? I don't want 
to have to drop packets that have already used up 
bandwidth getting to the machine, and making matters 
worse by requiring the packets to be sent again. 

Thanks,
Casey
----- Original Message -----
From: Randy Grimshaw <rgrimsha@syr.edu>
To: netfilter@lists.netfilter.org, casey@phantombsd.org 
Sent: Wednesday, April 5, 2006 10:27:48 AM GMT-0800
Subject: Re: Throttling NAT interface

Our throttle is really in the other direction but the 
idea may work for you.
iptables [traffic pattern spec] -m limit --limit 
40/second --limit-burst 60 -j LEVEL2
LEVEL2 is a user defined chain that specifies other 
restrictions or in your case NAT translations. 
The point is that you can match the traffic patterns 
that you need before applying the limit match.
hope this is helpful.
<><Randy


<><Randall Grimshaw
Room 203 Machinery Hall
Syracuse University
Syracuse, NY   13244
315-443-5779
rgrimsha@syr.edu 

>>> Casey Scott <casey@phantombsd.org> 4/5/2006 12:44 PM >>>
The gist of what I need to do is restrict the rate of
 off-network traffic coming in through a host. The host
is providing basic NAT to an internal network. I have
gotten pretty close to what I need to do with iptables
 and tc. The problem is that when an interface is throttle
 with tc, the source of the traffic doesn't matter. I don't
 want to throttle local traffic, just traffic coming through
 the machine from a WAN. The next step was to add another
NIC to the machine. Something like this:

eth0:  <local IP1>
eth1: <WAN IP>
eth2: <local IP2>

The problem is that even if  traffic destined to be routed
off network comes into eth2, which is throttle via tc, the
return traffic comes back through eth0. Since tc (tbf filter)
just controls the transmitting of an interface, I need to
force the NAT traffic to use eth2. Traffic that is meant to
stay local can use eth0. Is possible to do something like this?
How can I this host to only eth2 for NAT even though both eth0
and eth2 are in the same network?  eth0 is not throttled, which
 is why local traffic needs to use it.

TIA,
Casey






^ permalink raw reply

* [PATCH] Convert OSS aic23 to mutex
From: Dirk Behme @ 2006-04-05 18:10 UTC (permalink / raw)
  To: linux-omap-open-source

[-- Attachment #1: Type: text/plain, Size: 94 bytes --]


ARM: OMAP: Convert OSS aic23 to mutex.

Signed-off-by: Dirk Behme <dirk.behme_at_gmail.com>


[-- Attachment #2: omap-audio-aic23_mutex_patch.txt --]
[-- Type: text/plain, Size: 510 bytes --]

--- ./sound/oss/omap-audio-aic23.c_orig	2006-04-05 20:02:22.000000000 +0200
+++ ./sound/oss/omap-audio-aic23.c	2006-04-05 20:03:05.000000000 +0200
@@ -243,7 +243,7 @@ static audio_state_t aic23_state = {
         .hw_remove      =  __exit_p(omap_aic23_remove),
         .hw_suspend     = omap_aic23_suspend,
         .hw_resume      = omap_aic23_resume,
-	.sem	    = __SEMAPHORE_INIT(aic23_state.sem, 1),
+	.mutex	    = __MUTEX_INITIALIZER(aic23_state.mutex),
 };
 
 /* This will be defined in the audio.h */


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: [PATCH] add support for XCHG instruction accessingAPIC
From: Keir Fraser @ 2006-04-05 18:06 UTC (permalink / raw)
  To: Jiang, Yunhong; +Cc: xen-devel, Boris Ostrovsky
In-Reply-To: <FFEFE1749526634699CD3AC2EDB7627A017A7F0B@pdsmsx406>


On 5 Apr 2006, at 17:50, Jiang, Yunhong wrote:

> I think the reason we don't take any lock here is; we are sure this is 
> just used for local APIC range. However, if in future someone adds 
> another MMIO range or if IOAPIC is accessed with XCHG (will this 
> happen?), this may have potential issue.
>
> So I'd suggest adding comments that we didn't take any lock here, or 
> add a check to make sure the range is on local APIC range.

There is a comment in the patch I applied, and that section of code is 
specific to LAPIC handling.

  -- Keir

^ permalink raw reply

* Re: [PATCH] crypto: add alignment handling to digest layer
From: Herbert Xu @ 2006-04-05 18:05 UTC (permalink / raw)
  To: Atsushi Nemoto; +Cc: linux-kernel, linux-crypto, akpm
In-Reply-To: <20060404.000407.41198995.anemo@mba.ocn.ne.jp>

On Tue, Apr 04, 2006 at 12:04:07AM +0900, Atsushi Nemoto wrote:
>
> @@ -38,12 +39,24 @@ static void update(struct crypto_tfm *tf
>  			unsigned int bytes_from_page = min(l, ((unsigned int)
>  							   (PAGE_SIZE)) - 
>  							   offset);
> -			char *p = crypto_kmap(pg, 0) + offset;
> +			char *src = crypto_kmap(pg, 0);
> +			char *p = src + offset;
>  
> +			if (unlikely(offset & alignmask)) {
> +				unsigned int bytes =
> +					alignmask + 1 - (offset & alignmask);
> +				bytes = min(bytes, bytes_from_page);
> +				tfm->__crt_alg->cra_digest.dia_update
> +						(crypto_tfm_ctx(tfm), p,
> +						 bytes);

Don't we need to copy this to an aligned buffer?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: alsa cvs broken
From: Rene Herman @ 2006-04-05 18:04 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: Jaroslav Kysela, James Courtier-Dutton, alsa-devel
In-Reply-To: <s5hzmj0nu9q.wl%tiwai@suse.de>

Takashi Iwai wrote:

> Jaroslav Kysela wrote:

>> Note that most of other developers are sending us standard unified diffs 
>> (and this way will remain). If you use internally for development GIT
>> or HG is another thing. We will maintain the ALSA GIT tree as well for the 
>> kernel development, but our code is not only kernel code.
> 
> I think Rene's point is :
> 
> - git gets more popular than hg (not only for kernels like Keith's
>   case)
> - developers are too lazy to install hg extra only for ALSA

Well, not so much "lazy" though :-) All's fine and well if you do this 
stuff for a living but if you're the peripheral type that just submits 
the occasional bugfix, an unfamiliar development environment will not 
help bring you _beyond_ that occasional unidiff point to more active 
involvement.

My vote for GIT was just that though, one vote...

Rene.





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* Re: [linux-lvm] pvmove to smaller PVs
From: Alasdair G Kergon @ 2006-04-05 18:03 UTC (permalink / raw)
  To: LVM general discussion and development
In-Reply-To: <1144259900.32119.11.camel@pc7.dolda2000.com>

On Wed, Apr 05, 2006 at 07:58:19PM +0200, Fredrik Tolf wrote:
> However, is there a "canonical" way to check where PEs have been
> allocated inside PVs? 

lvs -o+devices
gives start PEs in parentheses

Alasdair
-- 
agk@redhat.com

^ permalink raw reply

* [ALSA - driver 0002005]: problems with make
From: bugtrack @ 2006-04-05 17:59 UTC (permalink / raw)
  To: alsa-devel


The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2005> 
======================================================================
Reported By:                mramirez
Assigned To:                perex
======================================================================
Project:                    ALSA - driver
Issue ID:                   2005
Category:                   0_compilation problem_!!!
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Distribution:               Fedora Core 5
Kernel Version:             2.6.15-1.2054_FC5smp
======================================================================
Date Submitted:             04-05-2006 19:59 CEST
Last Modified:              04-05-2006 19:59 CEST
======================================================================
Summary:                    problems with make
Description: 
I've dowload the cvs version of alsa, and try install on my laptop, but the
make process exit whit a bad status.
======================================================================

Issue History
Date Modified  Username       Field                    Change              
======================================================================
04-05-06 19:59 mramirez       New Issue                                    
04-05-06 19:59 mramirez       Distribution              => Fedora Core 5   
04-05-06 19:59 mramirez       Kernel Version            => 2.6.15-1.2054_FC5smp
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* Re: [linux-lvm] pvmove to smaller PVs
From: Fredrik Tolf @ 2006-04-05 17:58 UTC (permalink / raw)
  To: LVM general discussion and development
In-Reply-To: <20060405174425.GX4197@agk.surrey.redhat.com>

On Wed, 2006-04-05 at 18:44 +0100, Alasdair G Kergon wrote:
> On Wed, Apr 05, 2006 at 07:34:18PM +0200, Fredrik Tolf wrote:
> > Can pvmove not just divide that storage into three "partitions", 
> 
> There's no logic to do that yet.  It can only move complete sets of
> contiguous extents.
> 
> > Is there a way for me to tell it to do so?
> 
> As you found: break up contiguous extents explicitly on
> the command line by telling it to move smaller parts that it
> can handle.

I see. I guess I'll just have to do that then. It's not *that* bad,
after all. :)

However, is there a "canonical" way to check where PEs have been
allocated inside PVs? I think I can check /etc/lvm/backup/vgname. I'm
just getting the feeling that that's kind of ugly.

Thanks for your reply!

Fredrik Tolf

^ permalink raw reply

* Re: [linux-lvm] pvmove to smaller PVs
From: Matt P @ 2006-04-05 17:57 UTC (permalink / raw)
  To: LVM general discussion and development
In-Reply-To: <20060405174425.GX4197@agk.surrey.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

I'm no expert, mostly just a lurker on this list, but couldn't you SoftRAID
the 4 120GB's together then PV move the 300GB to the logical disk?

On 4/5/06, Alasdair G Kergon <agk@redhat.com> wrote:
>
> On Wed, Apr 05, 2006 at 07:34:18PM +0200, Fredrik Tolf wrote:
> > Can pvmove not just divide that storage into three "partitions",
>
> There's no logic to do that yet.  It can only move complete sets of
> contiguous extents.
>
> > Is there a way for me to tell it to do so?
>
> As you found: break up contiguous extents explicitly on
> the command line by telling it to move smaller parts that it
> can handle.
>
> Use '--alloc anywhere' if you need to move data within a single PV.
>
> Alasdair
> --
> agk@redhat.com
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 1454 bytes --]

^ permalink raw reply

* Re: rsync resetting contexts in /var/www
From: Stephen Smalley @ 2006-04-05 17:56 UTC (permalink / raw)
  To: J. Simonetti; +Cc: SELinux@tycho.nsa.gov
In-Reply-To: <1144234218.7521.70.camel@jeroen.office.denit.net>

On Wed, 2006-04-05 at 12:50 +0200, J. Simonetti wrote:
> Hello list,
> 
> I'm running into a problem with selinux on FC4
> (selinux-policy-targeted-1.27.1-2.22).
> 
> I'm using rsync to build a local fedora mirror. I'm rsyncing
> to /var/www/mirror with has a context of
> root:object_r:httpd_sys_content_t
> 
> However rsync seems to insist on writing the files synched in this
> directory as root:object_r:var_t.
> This results in a 403 error when trying to access the files via the web
> because apache can't read the files.
> 
> Is there a way for me to force rsync to create files in a certain
> context other then running chcon -R everytime rsync finishes?

rsync -X should preserve extended attributes, including the SELinux
attribute, from the original files.  Not sure if that addresses your
issue or not.  In the absence of -X, rsync should just be creating the
new files with the default behavior, i.e. they should just inherit from
the parent directory.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply

* Re: snd_pcm_hw_params_get_period_size() returning 0
From: Carlos Munoz @ 2006-04-05 17:53 UTC (permalink / raw)
  To: Jaroslav Kysela; +Cc: Takashi Iwai, Lee Revell, alsa-devel
In-Reply-To: <44317977.2060007@kenati.com>

Carlos Munoz wrote:

> Jaroslav Kysela wrote:
>
>> On Mon, 3 Apr 2006, Takashi Iwai wrote:
>>
>>  
>>
>>> At Mon, 03 Apr 2006 10:46:34 -0700,
>>> Carlos Munoz wrote:
>>>   
>>>
>>>> Takashi Iwai wrote:
>>>>
>>>>     
>>>>
>>>>> At Fri, 31 Mar 2006 18:20:42 -0800,
>>>>> Carlos Munoz wrote:
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>> Lee Revell wrote:
>>>>>>
>>>>>>  
>>>>>>         
>>>>>>
>>>>>>> On Fri, 2006-03-31 at 17:00 -0800, Carlos Munoz wrote:
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>           
>>>>>>>
>>>>>>>> Does any one know why
>>>>>>>> snd_pcm_hw_params_get_period_size() would be returning 0 ? Is 
>>>>>>>> it something the driver did/didn't do ?
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>      
>>>>>>>>             
>>>>>>>
>>>>>>> Argh, please disregard last message, that's not how the hw_params
>>>>>>> callback works :-(
>>>>>>>
>>>>>>> Lee
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>           
>>>>>>
>>>>>> Hi Lee,
>>>>>>
>>>>>> I digged further and this is what I found.
>>>>>>
>>>>>> snd_pcm_hw_params_get_period_size(...., int *val) does retrieve 
>>>>>> the correct period size and updates val with it. However, val 
>>>>>> does not match the address passed to it. I mean the caller of 
>>>>>> snd_pcm_hw_params_get_period_size(.... 0x41becc) passes the 
>>>>>> address of where the period size is to be stored as 0x41becc but 
>>>>>> snd_pcm_hw_params_get_period_size() gets 0x7b83c0d8 and that's 
>>>>>> where it puts the period size.
>>>>>>
>>>>>> This is on the Renesas SH7343 processor. alsa-lib is a dynamic 
>>>>>> library. Should I expect the variable address be the same ?
>>>>>>  
>>>>>>         
>>>>>
>>>>> No.  They must be different.  The value is stored to the original
>>>>> address only when no error returns.  Unless that, a temporary 
>>>>> variable
>>>>> is used.  That's why you see two distinct addresses.
>>>>>
>>>>>
>>>>> Takashi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>
>>>> Hi Takashi,
>>>>
>>>> I understand what you are saying. However, this is not the case 
>>>> here. The original address is wrong. I print the value of val (not 
>>>> _val) passed to snd_pcm_hw_params_get_period_size() and it is 
>>>> wrong. See the code:
>>>>
>>>> #ifndef DOXYGEN
>>>> int INTERNAL(snd_pcm_hw_params_get_period_size)(const 
>>>> snd_pcm_hw_params_t *params, snd_pcm_uframes_t *val, int *dir)
>>>> #else
>>>> int snd_pcm_hw_params_get_period_size(const snd_pcm_hw_params_t 
>>>> *params, snd_pcm_uframes_t *val, int *dir)
>>>> #endif
>>>> {
>>>>    unsigned int _val;
>>>>    printf("alsa-lib:snd_pcm_hw_params_get_period_size() - params=%p 
>>>> val=%p dir=%p\n",
>>>>           params, val, dir);
>>>>    int err = snd_pcm_hw_param_get(params, 
>>>> SND_PCM_HW_PARAM_PERIOD_SIZE, &_val, dir);
>>>>    if (err >= 0)
>>>>        *val = _val;
>>>>
>>>>    return err;
>>>> }
>>>>
>>>>
>>>> This printf shows val has an incorrect value (dir is also 
>>>> incorrect). I don't think it's related to the alsa-lib but maybe a 
>>>> problem with our build tool chain.
>>>>     
>>>
>>> OK, let me know if it turnes out to be a bug in alsa-lib :)
>>>   
>>
>>
>> Or binutils. What does 'nm aplay | grep 
>> snd_pcm_hw_params_get_period_size' show? Also, you might try to 
>> configure alsa-lib with --with-versioned=no .
>>
>>  
>>
> Hi Jaroslav,
>
> Yes, using --with-versioned=no solved the problem. Now everything 
> works. What does --with-versioned=no do ?
>
> By the way the output of nm is the same for alsa-lib built  with and 
> without the --with-versioned=no switch.
>
> nm aplay | grep snd_pcm_hw_params_get_period_size
>         U snd_pcm_hw_params_get_period_size@@ALSA_0.9.0rc4
>
Well... it's not as perfect as I thought. To get it to work, I need to 
link the alsa-utils (aplay) with an alsa-lib that has versioned enabled 
(--with-versioned=no is not passed to configure). But then, the run time 
alsa-lib must be one compiled with '--with-versioned=no'. Does anyone 
know what's going on ?

Thanks,


Carlos


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* [PATCH] Make saved environment available for remove event rules
From: Andrey Borzenkov @ 2006-04-05 17:51 UTC (permalink / raw)
  To: linux-hotplug


[-- Attachment #1.1: Type: text/plain, Size: 477 bytes --]

The patch assures that saved environment is available when processing
rules for 'remove' event. It enables mathing on previously set variables.
Among others it makes REMOVE_CMD really works (Debian bug 360855).

This is slightly modified version of patch from this thread:
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=114416867706787&w=2

Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>

---
Patch attached due to kmail customarily mangling long lines :(

-andrey

[-- Attachment #1.2: make_save_environment_avaialble_for_remove_rules.diff --]
[-- Type: text/x-diff, Size: 1989 bytes --]

Subject: [PATCH] Make saved environment available for remove event rules

From: Andrey Borzenkov <arvidjaar@mail.ru>

The patch assures that saved environment is available when processing
rules for 'remove' event. It enables mathing on previously set variables.
Among others it makes REMOVE_CMD really works (Debian bug 360855).

This is slightly modified version of patch from this thread:
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=114416867706787&w=2

Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>

---

 udev_device.c |    7 ++++---
 udev_remove.c |    2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/udev_device.c b/udev_device.c
index 5db2709..6ee6b13 100644
--- a/udev_device.c
+++ b/udev_device.c
@@ -101,6 +101,10 @@ int udev_device_event(struct udev_rules 
 	if (major(udev->devt) != 0 && strcmp(udev->action, "remove") == 0) {
 		struct name_entry *name_loop;
 
+		udev_db_get_device(udev, udev->dev->devpath);
+		/* restore stored persistent data */
+		list_for_each_entry(name_loop, &udev->env_list, node)
+			putenv(name_loop->name);
 		udev_rules_get_run(rules, udev);
 		if (udev->ignore_device) {
 			info("device event will be ignored");
@@ -109,9 +113,6 @@ int udev_device_event(struct udev_rules 
 		/* get data from db, remove db-entry, delete node */
 		retval = udev_remove_device(udev);
 
-		/* restore stored persistent data */
-		list_for_each_entry(name_loop, &udev->env_list, node)
-			putenv(name_loop->name);
 		return retval;
 	}
 
diff --git a/udev_remove.c b/udev_remove.c
index 6de6cf5..f4c9ab6 100644
--- a/udev_remove.c
+++ b/udev_remove.c
@@ -119,7 +119,7 @@ int udev_remove_device(struct udevice *u
 	if (major(udev->devt) == 0)
 		return 0;
 
-	if (udev_db_get_device(udev, udev->dev->devpath) == 0) {
+	if (udev->name[0] != '\0') {
 		if (udev->ignore_remove) {
 			dbg("remove event for '%s' requested to be ignored by rule", udev->name);
 			return 0;

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply related

* [parisc-linux] [PATCH] e100_probe using ioremap
From: Gustavo Zacarias @ 2006-04-05 17:50 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 136 bytes --]


e100_probe in drivers/net/e100.c is using ioremap instead of 
ioremap_nocache.
Fix attached.

-- 
Gustavo Zacarias
Gentoo/SPARC monkey

[-- Attachment #2: e100_ioremap.diff --]
[-- Type: text/x-patch, Size: 593 bytes --]

diff -Nura linux-2.6.16-pa11/drivers/net/e100.c linux-2.6.16-pa11-e100/drivers/net/e100.c
--- linux-2.6.16-pa11/drivers/net/e100.c	2006-03-20 02:53:29.000000000 -0300
+++ linux-2.6.16-pa11-e100/drivers/net/e100.c	2006-04-05 14:48:09.000000000 -0300
@@ -2607,7 +2607,7 @@
 	SET_MODULE_OWNER(netdev);
 	SET_NETDEV_DEV(netdev, &pdev->dev);
 
-	nic->csr = ioremap(pci_resource_start(pdev, 0), sizeof(struct csr));
+	nic->csr = ioremap_nocache(pci_resource_start(pdev, 0), sizeof(struct csr));
 	if(!nic->csr) {
 		DPRINTK(PROBE, ERR, "Cannot map device registers, aborting.\n");
 		err = -ENOMEM;

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

^ permalink raw reply

* Re: [Alsa-devel] [2.6.17-rc1] ALSA oops with multiple OSS clients
From: Lee Revell @ 2006-04-05 17:44 UTC (permalink / raw)
  To: Luca; +Cc: linux-kernel, perex, alsa-devel
In-Reply-To: <20060405173002.GA5306@dreamland.darkstar.lan>

On Wed, 2006-04-05 at 19:30 +0200, Luca wrote:
> Hello,
> I've a reproducible OOPS when starting multiple OSS clients.
> To reproduce I do this:
> mpg123 song.mp3
> mpg123 song.mp3 (another time)
> 
> At this point the song restart from the beginning (i.e. I think that 
> the second mpg123 takes over the device). When the second instance
> terminates the song I get the following OOPS:

Known bug, please try the patch:

http://bugzilla.kernel.org/show_bug.cgi?id=6329

Lee


^ permalink raw reply

* Re: [2.6.17-rc1] ALSA oops with multiple OSS clients
From: Lee Revell @ 2006-04-05 17:44 UTC (permalink / raw)
  To: Luca; +Cc: linux-kernel, perex, alsa-devel
In-Reply-To: <20060405173002.GA5306@dreamland.darkstar.lan>

On Wed, 2006-04-05 at 19:30 +0200, Luca wrote:
> Hello,
> I've a reproducible OOPS when starting multiple OSS clients.
> To reproduce I do this:
> mpg123 song.mp3
> mpg123 song.mp3 (another time)
> 
> At this point the song restart from the beginning (i.e. I think that 
> the second mpg123 takes over the device). When the second instance
> terminates the song I get the following OOPS:

Known bug, please try the patch:

http://bugzilla.kernel.org/show_bug.cgi?id=6329

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* Re: [linux-lvm] pvmove to smaller PVs
From: Alasdair G Kergon @ 2006-04-05 17:44 UTC (permalink / raw)
  To: LVM general discussion and development
In-Reply-To: <1144258458.32119.8.camel@pc7.dolda2000.com>

On Wed, Apr 05, 2006 at 07:34:18PM +0200, Fredrik Tolf wrote:
> Can pvmove not just divide that storage into three "partitions", 

There's no logic to do that yet.  It can only move complete sets of
contiguous extents.

> Is there a way for me to tell it to do so?

As you found: break up contiguous extents explicitly on
the command line by telling it to move smaller parts that it
can handle.

Use '--alloc anywhere' if you need to move data within a single PV.

Alasdair
-- 
agk@redhat.com

^ permalink raw reply

* Re: [Lhms-devel] [RFC 0/6] Swapless Page Migration V1: Overview
From: Christoph Lameter @ 2006-04-05 17:43 UTC (permalink / raw)
  To: Lee Schermerhorn
  Cc: linux-mm, lhms-devel, Hirokazu Takahashi, Marcelo Tosatti,
	KAMEZAWA Hiroyuki
In-Reply-To: <1144256328.5203.36.camel@localhost.localdomain>

On Wed, 5 Apr 2006, Lee Schermerhorn wrote:

> > We never allow a faulting in of the new page before migration is 
> > complete. The replacing of the swap ptes with real ptes was always done 
> > after migration was complete. Same thing here.
> 
> Unless we're talking about different things [happens], my migrate-on-
> fault patches do this.  Pages are unmapped from ptes and left hanging in
> the cache until some task touches them.  Then the migration occurs, if

Well you can only umap file backed pages. These are still working the same 
way. Anonymous pages can only be remapped in a different way not unmapped.
"unmap" of anonymous pages in todays kernels really means remap to swap 
space.

If you put the anonymous pages on swap then you can still have the old 
behavior but then you would require swap space.

> In any case, I don't think we want to be walking reverse maps and other
> task's pte's in one task's page fault path.  Perhaps "migrate-on-fault"
> and "auto-migration" are not going to go anywhere, but if they do, we'll
> need something like the existing swap/migration cache behavior, where
> the temporary ptes reference a single [reference counted] cache entry
> that points at either the old or new page.

No we certainly do not want to walk reverse maps in critical sections of 
the code.

I think the opportunistic lazy migration that we were talking about before 
would be fine with this scheme. You just check the refcount during the 
fault and then migrate the page if this would establish the first 
mapcount.

Pushing pages into the migration cache from the scheduler in order to 
migrate them later when references are to be reestablished will no longer 
work.
 
Would not swap be a more appropriate mechanism there? I mean the 
functionality that you want is almost exactly the same as swap. The 
checking of the mapcounts can then work the same way as opportunistic lazy 
migration.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: H.323 conntrack/NAT helper update for 2.6.17-rc1
From: Jing Min Zhao @ 2006-04-05 17:40 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel
In-Reply-To: <4433F9FF.6050709@trash.net>


----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jing Min Zhao" <zhaojingmin@hotmail.com>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Wednesday, April 05, 2006 1:10 PM
Subject: Re: H.323 conntrack/NAT helper update for 2.6.17-rc1


> 
> Applied, thanks. A couple of comments though:
> 
> - I've split your patches into the logical changes, this is prefered
>  to "version-updates". Ideally you just send one patch per change.
>
OK, I will.
 
> - whitespace changes:
> 
> -               /* ip_nat_mangle_udp_packet uses skb_make_writable() to copy
> -                * or pull everything in a linear buffer, so we can safely
> +               /* ip_nat_mangle_udp_packet uses skb_make_writable() to
> copy
> +                * or pull everything in a linear buffer, so we can safely
> 
> Please try to avoid such things, except for seperated patches that
> _remove_ whitespace :)
>
I did check trailing spaces by checking the diff file. But I still missed 
something :(
 
> - I've changed default_rrq_timeout to unsigned because it is assigned
>  to an unsigned member.
>
Thank you. According to the ASN file, it should be unsigned. I knew
this but just simply forgot it. Forgive my carelessness.
 
> - Changelogs in the source-code: its your choice, but I personally
>  prefer to avoid changelogs in the source files, they tend to
>  grow pretty fast and you are mostly not interested in them. If
>  you are, you can use the git history.
>
I'll try.
 
> Thanks again.
> 
>
I'm sorry it wasted you so much time on these careless mistakes.

Thank you for your great work and your time!

Best regards,

Jing Min Zhao

^ permalink raw reply

* Re: [patch 2.6.16-mm2 10/9] sched throttle tree extract - kill interactive task feedback loop
From: Mike Galbraith @ 2006-04-05 17:38 UTC (permalink / raw)
  To: Ingo Molnar, Andrew Morton; +Cc: lkml, Peter Williams, Nick Piggin, Con Kolivas
In-Reply-To: <1143883915.7617.77.camel@homer>

Greetings,

The patch below stops interactive tasks from feeding off each other
during round-robin.

With this 10th patch in place, a busy server with _default_ throttle
settings (ie tunables may now be mostly unneeded) looks like this:

[root]:# w
 18:38:00 up 23 min,  2 users,  load average: 10.07, 9.94, 7.50
USER     TTY        LOGIN@   IDLE   JCPU   PCPU  WHAT
root     tty1      18:15   22:12  30.89s 30.84s  top d1
root     pts/0     18:20    0.00s  0.07s  0.00s  w
[root]:# time netstat|grep :81|wc -l
   1758

real    0m0.304s
user    0m0.144s
sys     0m0.135s
[root]:# time netstat|grep :81|wc -l
   1776

real    0m0.306s
user    0m0.118s
sys     0m0.163s
[root]:# time netstat|grep :81|wc -l
   1799

real    0m0.493s
user    0m0.146s
sys     0m0.141s
[root]:#

My desktop still feels just peachy.

Signed-off-by: Mike Galbraith <efault@gmx.de>

--- linux-2.6.16-mm2/kernel/sched.c-9.export_tunables	2006-03-31 13:37:09.000000000 +0200
+++ linux-2.6.16-mm2/kernel/sched.c	2006-04-05 19:22:01.000000000 +0200
@@ -3480,7 +3480,7 @@ go_idle:
 	queue = array->queue + idx;
 	next = list_entry(queue->next, task_t, run_list);
 
-	if (!rt_task(next) && interactive_sleep(next->sleep_type)) {
+	if (!TASK_INTERACTIVE(next) && interactive_sleep(next->sleep_type)) {
 		unsigned long long delta = now - next->timestamp;
 		if (unlikely((long long)(now - next->timestamp) < 0))
 			delta = 0;



^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.