Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages

[Andrew Morton]

On Thu, 25 Jan 2007 23:44:58 + (GMT)
Mel Gorman <[EMAIL PROTECTED]> wrote:

> The following 8 patches against 2.6.20-rc4-mm1 create a zone called
> ZONE_MOVABLE

Argh.  These surely get all tangled up with the
make-zones-optional-by-adding-zillions-of-ifdef patches:

deal-with-cases-of-zone_dma-meaning-the-first-zone.patch
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set-reduce-config_zone_dma-ifdefs.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
set-config_zone_dma-for-arches-with-generic_isa_dma.patch
zoneid-fix-up-calculations-for-zoneid_pgshift.patch

My objections to those patches:

- They add zillions of ifdefs

- They make the VM's behaviour diverge between different platforms and
  between differen configs on the same platforms, and hence degrade
  maintainability and increase complexity.

- We kicked around some quite different ways of implementing the same
  things, but nothing came of it.  iirc, one was to remove the hard-coded
  zones altogether and rework all the MM to operate in terms of

for (idx = 0; idx < NUMBER_OF_ZONES; idx++)
...

- I haven't seen any hard numbers to justify the change.

So I want to drop them all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bugfixes: PCI devices get assigned redundant IRQs

[Xavier Bestel]

On Fri, 2007-01-26 at 11:50 +0100, Andreas Block wrote:

>   u8 pin, slot;
> - int irq;
> + int irq = 0;

Aren't there platforms for which irq = 0 is a valid irq ?

Xav


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] lumpy reclaim v2

[Andrew Morton]

On Thu, 14 Dec 2006 20:57:34 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:

> On Wed, 6 Dec 2006 16:59:35 +
> Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> 
> > +   tmp = __pfn_to_page(pfn);
> 
> ia64 doesn't implement __page_to_pfn.  Why did you not use page_to_pfn()?

Poke.  I'm still a no-compile on ia64.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Juju

[Stefan Richter]

Pete Zaitcev wrote:
> On Fri, 26 Jan 2007 03:35:19 +0100, Stefan Richter <[EMAIL PROTECTED]> wrote:
>> The target wrote an SBP-2 status block into our memory. The status block
>> contains the FireWire bus address of the ORB to which it belongs. [...]
> 
> I see. SRP has a more flexible tag which can be used to look up
> the just completed command more effectively. But if we only submit
> one, it's a moot point of course.

And indeed, in the SBP-2 realm the ORB's address is actually the tag of
the SCSI task.

>> [...] Since there aren't many
>> mapped ORBs per target, a linked list is a reasonable data structure to
>> search over.
> 
> Righto. I'm used to having thousands of oustanding commands in arrays.

If I ever get to fix sbp2's handling of dynamically appended ORB lists,
the next step would be to measure which queue depth is optimal for
different hardware and different workloads. (Certainly much less than
thousands for typical SBP-2 target(s)+initiator(s) setups.)
-- 
Stefan Richter
-=-=-=== ---= ==-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bugfixes: PCI devices get assigned redundant IRQs

[Andreas Block]

Hi,

I'm currently working on a port to a CPCI board with a MPC5200.
When testing the PCI interrupt routing, I discovered the following:
Even devices which don't use interrupts (-> PCI Spec.: Interrupt Pin  
Register is zero),
get an interrupt assigned (this is at least true for most of the  
PPC-targets I looked at).

The cause is pretty obvious in drivers/pci/setup-irq.c.
I guess at least in an ideal world with correctly designed hardware, the  
code should

rather look as in the patch below.
Of course it doesn't hurt anybody to have an unuseable IRQ assigned to a
PCI-to-PCI-bridge (or something alike), but to me it seems a bit strange.
Please correct me, if I'm mislead.

The patch below is tested on the above mentioned CPCI-MPC5200 board and is  
compiler

tested with the latest git-repository kernel on x86.

Best regards,
Andreas

---

Don't assign IRQs to devices, which don't need any

---
commit 2133d61f0bc119d4a06d453b8e79980912a151f0
tree 59ff1b5f7c1ec41780907edd90a35c10a64e3996
parent 99abfeafb5f2eea1bb481330ff37343e1133c924
author Andreas Block <[EMAIL PROTECTED]> Thu, 25 Jan 2007  
17:12:48 +0100
committer Andreas Block <[EMAIL PROTECTED]> Thu, 25 Jan  
2007 17:12:48 +0100


 drivers/pci/setup-irq.c |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
index a251289..568f187 100644
--- a/drivers/pci/setup-irq.c
+++ b/drivers/pci/setup-irq.c
@@ -24,7 +24,7 @@ pdev_fixup_irq(struct pci_dev *dev,
   int (*map_irq)(struct pci_dev *, u8, u8))
 {
u8 pin, slot;
-   int irq;
+   int irq = 0;

/* If this device is not on the primary bus, we need to figure out
   which interrupt pin it will come in on.   We know which slot it
@@ -33,16 +33,18 @@ pdev_fixup_irq(struct pci_dev *dev,
   apply the swizzle function.  */

pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
-   /* Cope with 0 and illegal. */
-   if (pin == 0 || pin > 4)
+   /* Cope with illegal. */
+   if (pin > 4)
pin = 1;

-   /* Follow the chain of bridges, swizzling as we go.  */
-   slot = (*swizzle)(dev, );
+   if (pin != 0) {
+   /* Follow the chain of bridges, swizzling as we go.  */
+   slot = (*swizzle)(dev, );

-   irq = (*map_irq)(dev, slot, pin);
-   if (irq == -1)
-   irq = 0;
+   irq = (*map_irq)(dev, slot, pin);
+   if (irq == -1)
+   irq = 0;
+   }
dev->irq = irq;

pr_debug("PCI: fixup irq: (%s) got %d\n",

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks

[xiphmont]

On 1/25/07, Greg KH <[EMAIL PROTECTED]> wrote:

I want to do just a little more testing here (Takashi reminded me I
have a bit more testing of my own to do).


Can you give me the 'tree /sys/class/sound' output?

Once I verify it's 'all good' (actually, I'm stalling; not in front of
the machine with the patches right now.


Does it work properly with old versions of hald now?


Yes.  I still need to make doubly sure I didn't break the new sysfs tree though.


Is there anything else left to fix?


Once that testing is done, no.  But don't trust the two patches I sent
yet, I'll resumbit the patch resulting from more thorough testing in a
few hours (much thanks to Takashi for giving me the parent device
feedback I was trolling for).

Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Limit the size of the pagecache

[Andrew Morton]

On Wed, 24 Jan 2007 15:03:23 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:

> 
> Yeah, it will be failing at order=4, because the allocator won't try
> very hard reclaim pagecache pages at that cutoff point. This needs to
> be fixed in the allocator.

A simple and perhaps sufficient fix for this nommu problem would be to replace
the magic "3" in __alloc_pages() with a tunable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6

[Hans-Peter Nilsson]

Just some trivial patches to make sure the existing drivers in
the official tree don't *silently* fail with the introduction of
default_tx_word.  Never tested in any way.  Not sure if this is
all, for example I didn't look in arch/*.

Signed-off-by: Hans-Peter Nilsson <[EMAIL PROTECTED]>

diff -upr a/drivers/spi/pxa2xx_spi.c b/drivers/spi/pxa2xx_spi.c
--- a/drivers/spi/pxa2xx_spi.c  2007-01-26 10:38:49.0 +0100
+++ b/drivers/spi/pxa2xx_spi.c  2007-01-26 11:17:49.0 +0100
@@ -1077,6 +1077,9 @@ static int setup(struct spi_device *spi)
if (!spi->bits_per_word)
spi->bits_per_word = 8;
 
+   if (spi->default_tx_word != 0)
+   return -EINVAL;
+
if (drv_data->ssp_type != PXA25x_SSP
&& (spi->bits_per_word < 4 || spi->bits_per_word > 32)) {
dev_err(>dev, "failed setup: ssp_type=%d, bits/wrd=%d "
diff -upr a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
--- a/drivers/spi/spi_mpc83xx.c 2007-01-26 10:38:49.0 +0100
+++ b/drivers/spi/spi_mpc83xx.c 2007-01-26 11:19:01.553401939 +0100
@@ -238,6 +238,9 @@ static int mpc83xx_spi_setup(struct spi_
struct mpc83xx_spi *mpc83xx_spi;
int retval;
 
+   if (spi->default_tx_word != 0)
+   return -EINVAL;
+
if (!spi->max_speed_hz)
return -EINVAL;
 
diff -upr a/drivers/spi/spi_s3c24xx.c b/drivers/spi/spi_s3c24xx.c
--- a/drivers/spi/spi_s3c24xx.c 2007-01-26 10:38:49.0 +0100
+++ b/drivers/spi/spi_s3c24xx.c 2007-01-26 11:19:19.014017640 +0100
@@ -153,6 +153,9 @@ static int s3c24xx_spi_setup(struct spi_
 {
int ret;
 
+   if (spi->default_tx_word != 0)
+   return -EINVAL;
+
if (!spi->bits_per_word)
spi->bits_per_word = 8;
 

brgds, H-P
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6

[Hans-Peter Nilsson]

> From: David Brownell <[EMAIL PROTECTED]>
> Date: Thu, 25 Jan 2007 05:02:56 -0800

> On Wednesday 24 January 2007 8:52 pm, Hans-Peter Nilsson wrote:
> > (Please CC me on replies, I'm not subscribed to LKML or the SPI list.  
> > Thanks.)
> > 
> > The SD/MMC SPI-based protocol isn't really duplex.  In the
> > normal case there's either information transmitted or received,
> > not both simultaneously.  The unused data is always 0xff; ones.
> > Unfortunately, the SPI framework leaves outgoing data for a
> > left-out tx_buf just as "undefined"
> 
> In current kernels that's actually changed.  The value to be shifted
> out is now specified ... as all-zeroes, which is what various chips
> need to receive, and various (half-duplex/Microwire) controllers seem
> to be doing in any case.
> 
> If that's an issue -- and MMC-over-SPI needs to specify some other
> value --

Well, it *is* specified as ones (0xff).  Curiously enough, I
can't point to a statement in the "Simplified Physical Layer
Specification 2.0".  It's likely specified in the "7.5 SPI Bus
Timing Diagrams", which is "blank for the Simplified
Specification".  If you look at SanDisk's OEM documents for
"MultiMediaCard"/ "Reduced-Size MultiMediaCard" v1.3, you can
see that *that* document nicely complements the "Simplified
Specification", and specifies it as 0xff (see "5.23 SPI Bus
Timing Diagrams").  FWIW, I found this referenced from somewhere
I-forgot when I STFW'd for SD/MMC SPI documentation or Linux
drivers, so I'm not "ratting them out" for providing
documentation withheld elsewhere. :-} Besides, I think they're
one of those making the rules for the SDcard organization.

...and anyway, I just *had* to try: well, it doesn't work with 0. :-)

> I think a better way to package this would be to define a new
> flag for spi->mode, since controller drivers are already supposed
> to be checking that to make sure they handle all the options which
> have been specified.

But it's unspecified what the controller drivers should do with
flags don't recognize (should they refuse? warn? ignore? - I see
they all ignore) so with that suggestion, we'll have a situation
where drivers wouldn't know about the new flag and would
silently not work.

Perhaps it can be "legislated" or at least strongly suggested
that SPI drivers must return -EINVAL for flags in spi->mode that
they don't recognise?  Typically, for 2.6.19 flags, in their
master-setup method:

  if (spi->mode & ~(SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST))
return -EINVAL;

(I think I'll do exactly that with the drivers I wrote.)

>  That flag could work in conjunction with
> a byte

Or why not a 32-bit word!  If controllers can only handle non-0
values for bits_per_word <= 8, they can check for that.  (Before
you suggest a 64-bit value, consider that the 64-bit-ness would
supposedly be rarely used and the value is likely to be looked
up in inner loops like for the bitbanged driver.  Ok, there are
ways around that, it's just that I don't think a 64-bit value
would be more useful than the implications.  We can always
change it when a use-case appears.  I guess that implies having
it a u8, but typically the 32 vs 8 bit difference is much less
than 64 vs 32.  Toolshed alert!)

> provided in the spi_device, that would be used instead of
> zero.  (Some folk have noted that when debugging, it's easier if
> the pattern there is neither all-ones nor all-zeroes ... something
> that a digital scope will show is easier to work with.)

FWIW, I defined it as a single bit in that patch, because that's
what my HW can do when the transmitter is disabled - and because
MOSI *is* a single-valued signal. ;-)  Also, I made it
per-transfer, which for mmc_spi wouldn't mean much, only perhaps
to possibly drop all-zero buffers, which of course implied that
someone would have to scan them first anyway (i.e. no fewer
memory accesses), so I guess I had no serious use-case.

Still, making it a u32 (or u8), with spi->bits_per_word
specifying the actual length, makes sense for example to
implementations around a shift-register but with no DMA.  A
controller can return -EINVAL (shouldn't that be -ENOSYS?) if it
finds a default_tx_word it can't support simply enough.  If we
define returning -EINVAL as always ok and that the driver/client
part is responsible for a fallback, I think we have agreement.

While I was looking, I noticed that the memory-layout of
non-8-bit words for SPI is a bit unclear.  The endianness of
data shifted out doesn't really define endianness in memory or
whether 24-bit words bytes are in order {hi, med, low, pad} or
indeed {pad, low, med, hi or whatever combination.  For a LE
architecture, storing data as LE in memory makes sense, and both
with and without padding makes sense too.  Perhaps best to just
document that it's undefined?

> then please re-issue this patch against 2.6.20, including
> the update to the bitbang driver ("reference implementation").

I used patch-2.6.20-rc6; I see not too many SPI 

Re: [PATCH] init: support preset lpj value as config option

[Andrew Morton]

On Thu, 25 Jan 2007 10:24:59 -0800
Tim Bird <[EMAIL PROTECTED]> wrote:

> Paul Mundt wrote:
> > On Wed, Jan 24, 2007 at 04:12:18PM -0800, Tim Bird wrote:
> >> This patch provides a config option for preset lpj, which means
> >> the value can be easily preserved, and conveyed between developers
> >> in a config file.
> >>
> > This seems excessive, it's already possible to set the preset lpj on the
> > kernel command line, and virtually every one of the embedded
> > architectures supports setting the kernel command line as a config
> > option. Is there any reason why you can't simply set it there as a
> > default instead? It's all going to be .config resident in the end
> > anyways.
> 
> i386 is missing CONFIG_CMDLINE support, and this architecture
> is used in embedded.

So if we add CONFIG_CMDLINE we fix this problem and we bring i386 into line
with other platforms.  It's all good.

>  I think many other x86 derivatives are
> also missing .config-based command line support.  CELF has
> worked to get patches submitted to fix this, but so far these
> haven't been accepted.

You have?



To whom?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: unfixed regression in 2.6.20-rc6 (since 2.6.19)

[Rainer Weikusat]

Greg KH <[EMAIL PROTECTED]> writes:
> On Thu, Jan 25, 2007 at 04:20:55PM +0100, Rainer Weikusat wrote:
>> 2.6.19 introduced changes to the UHCI handling of interrupt URBs that
>> caused at least some keyspan USB-to-serial converters to fail,

[...]

> I copied you when this patch was added to my tree,

The only thing I received was a 'this patch has been dropped from
the MM-tree because something happened' message.

> as I had reworked it to be a bit more acceptable (no pointer
> arithmatic, proper coding style, use the newer macros for endpoint
> detection, etc.),

You have basically done a couple of (functionally) totally pointless
changes, like

- not using iterator-style array traversals, but indexed ones
  instead

- doing the calculation to determine the endpoint type in
  three different places instead of in one place, because the
  somewhat silly endpoint classification interfaces enforces
  this

- not using a single switch-statement but an if-else-cascade,
  again due to limitations of that interface

- replacing the while-loop with an identical for-loop

The net effect of these changes is that an optimizing compiler will
have to work somewhat more to remove all the redundant stuff that
was added. As for 'proper coding style', the code conforms to what is
documented as 'proper kernel coding style'. If this assumption of mine
is incorrect, I'd be happy to hear about reasons why this would be so,
to take them into account for eventual future patches.

> I this patch does not work, please let me know, and I will be glad
> to work to fix it.

I think I'll just resend the working one in this case. But the logic
appears to be identical, so I do not so a reason why it shouldn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

fsync occasionally very slow

[Matthew Kirk]

Hi

I am working on an application that fsync(2) files and directories as
needed.I’m seeing intermittent stalls on fsync that can last many
seconds.  The file system is mounted ext3, however I have reproduced the
problem with ext2.  The as scheduler is in use.   I have also tried
deadline.  I have tried 2.6.12.3 (what I’m currently deploying on – yes, I
know it’s old) and 2.6.15 (highest kernel I could easily get to run).  I
have reproduced the problem on both machines with high performance raid
controllers and without.  I haven’t been able to find any reported issues
that describe this problem in a relatively recent kernel (though I did find
some comments about 2.0).

In the original application, data is received from another machine via many
threads.  These threads all write occasionally, usually in chunks of about
1K or 100K (I have also tried using 10M chunks, though some percentage are
still very small).   Half of all files are in the 10-15MB range.  The other
half are very small.  There are also log files that get appended to
regularly. Except for logs, we fsync right before each file is closed.  We
also fsync directories.  Everything is on a single large stripe.  In the
regular application, fsync can happen from any of a number of threads. 

In the application, if one call to fsync blocks, other threads that
subsequently call fsync while the first one is blocked appear to also block.
Once the first thread's fsync releases, the others appear to release too.

I’m not 100% sure it’s fsync vs. some other file system issue.  When I
instrument my code I find that about 90% of the stalls are on fsync, with
the remainder being on other file system operations (e.g. write).  If I
disable fsync in the application I still see stalls, though a little less
frequently.

When running I see what appear to be normal numbers of pdflush jobs (range
2-8, usually 4-5).  When I get application stalls the system is still
otherwise responsive.  I can still start processes, write files, etc.
Typically there are 4-5 pdflushes during stalls too.  CPU utilization (user)
is about 10% and I/O wait is 60-70%.  According to iostat, although blocks
are sometimes getting written during these stalls, they frequently are not.

I have reproduced what I think is the same problem in the stand-alone,
single-threaded source code attached, which opens files, writes to them, and
then only when done writing all files, fsyncs them and closes them in the
order in which they were written. In the standalone application, the first
files that get written take virtually no time to fsync (already flushed),
then once files start to be flushed time will increase, however at least one
file will take a couple seconds to flush, where the others will be in the
range of a few thousandths of a second.

I’m not sure where to go with this now and would appreciate any insights you
have.

Thanks!
Matt Kirk


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
const unsigned int bigsize = 10248576;
const unsigned int smallsize = 10248576;

char *buff;
int main (int argc, const char *argv[]) { 
   int q;
   int innerloop = 100;
   int outerloop = 1000;
   int dofsync = 1;
   if (argc > 1) { 
  dofsync=(atoi(argv[1]));
   }
   if (argc > 2) { 
  innerloop=(atoi(argv[2]));
   }
   if (argc == 4) {
  outerloop=(atoi(argv[3]));
   }
   buff = new char[bigsize];
   memset(buff, 1, bigsize);
   int fd[innerloop];
   for (int r = 0; r < outerloop; r++) { 
  struct timeval starttimer,endtimer;
  gettimeofday(, NULL);
  int count;
  for (int q = 0; q < innerloop; q++) {
 std::stringstream s; 
 s << "file_" << q+(r*outerloop);
 fd[q] = open(s.str().c_str(), O_RDWR+O_CREAT+O_APPEND);
 if (fd[q] == -1) { std::cout << "Failed to open " << s.str() << "
due to " << errno << std::endl; return(0); }
 if (q % 4 != 1) { 
count = write(fd[q],(void*) buff, bigsize);
if (count != bigsize) { std::cout << "write returned " << count
<< " with errno " << errno << std::endl; return (0); }
 } else { 
count = write(fd[q],(void*) buff, smallsize);
if (count != smallsize) { 
   std::cout << "write returned " << count << " with errno " <<
errno << std::endl; 
   return (0);
} 
 }
  }

  for (int q = 0; q < innerloop; q++) {
 struct timeval mytimer, mytimer2;
 gettimeofday(, NULL);
 if (dofsync) { 
count = fsync(fd[q]);
 } else { 
count = fdatasync(fd[q]);
 }
 gettimeofday(, NULL);
 if (mytimer.tv_usec > mytimer2.tv_usec) {
mytimer2.tv_sec -= (mytimer.tv_sec+1);
mytimer2.tv_usec += (100-mytimer.tv_usec);
 } else { 
mytimer2.tv_sec -= mytimer.tv_sec;
mytimer2.tv_usec -= mytimer.tv_usec;
 }
 
 if (count != 0) { 

Re: + make-good_sigevent-non-static.patch added to -mm tree

[Sébastien Dugué]

On Fri, 26 Jan 2007 13:08:01 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote:

> On 01/26, S?bastien Dugu? wrote:
> >
> > On Thu, 25 Jan 2007 18:43:24 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > 
> > > SИbastien DuguИ wrote:
> > > >
> > > > +struct task_struct *good_sigevent(sigevent_t *event)
> > > > +{
> > > > +   struct task_struct *task = current->group_leader;
> > > > +
> > > > +   if ((event->sigev_notify & SIGEV_THREAD_ID) == SIGEV_THREAD_ID) 
> > > > {
> > > > +   task = find_task_by_pid(event->sigev_notify_thread_id);
> > > > +
> > > > +   if (!task || task->tgid != current->tgid)
> > > > +   return NULL;
> > > > +   } else if (event->sigev_notify == SIGEV_SIGNAL) {
> > > 
> > > No, no, we can't use "else" here,
> > > 
> > > > +   if (event->sigev_signo <= 0 || event->sigev_signo > 
> > > > SIGRTMAX)
> > > 
> > > because we skip the check above in SIGEV_THREAD_ID case.
> > 
> >   Right, will fix this.
> > 
> > > 
> > > This way any user can crash the kernel with a minimal effort.
> > 
> >   Well I tried, no crash, just the signal failing to be delivered.
> 
>   sigaddset:
> 
>   set->sig[sig / _NSIG_BPW] |= 1UL << (sig % _NSIG_BPW);
> 
> This writes to ->sig[event->sigev_signo / _NSIG_BPW] location, so we can
> corrupt the memory if ->sigev_signo > _NSIG.

  Gawd, right.

> 
> Btw, since you are exporting this function, may I suggest to rename it?
> No, I can't suggest a better name :) But "good_sigevent" is a bit confusing
> imho.

  I agree, there was a discussion concerning this a while back but nothing came
out of it and I left it as is.

  I will try to find something more suggestive.

  Thanks,

  Sébastien.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Limit the size of the pagecache

[Andrew Morton]

On Wed, 24 Jan 2007 14:15:10 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:

> - One for stability
>   When a customer constructs their detabase(Oracle), the system often goes to 
> oom.
>   This is because that the system cannot allocate DMA_ZOME memory for 32bit 
> device.
>   (USB or e100)
>   Not allowing to use almost all pages as page cache (for temporal use) will 
> be some help.
>   (Note: construction DB on ext3so all writes are serialized and the 
> system couldn't
>free page cache.)

I'm surprised that any reasonable driver has a dependency on ZONE_DMA.  Are
you sure?  Send full oom-killer output, please.


> - One for tuing.
>   Sometimes our cutomer requests us to limit size of page-cache.
>   
>   Many cutomers's memory usage reaches 99.x%. (this is very common situation.)
>   If almost all memories are used by page-cache, and we can think we can free 
> it.
>   But the customer cannot estimate what amount of page-cache can be freed 
> (without 
>   perfromance regression).
>   
>   When a cutomer wants to add a new application, he tunes the system.
>   But memory usage is always 99%.
>   page-cache limitation is useful when the customer tunes his system and find
>   sets of data and page-cache. 
>   (Of course, we can use some other complicated resource management system 
> for this.)
>   This will allow the users to decide that they need extra memory or not.
> 
>   And...some customers want to keep memory Free as much as possible.
>   99% memory usage makes insecure them ;)

Tell them to do "echo 3 > /proc/sys/vm/drop_caches", then wait three minutes?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Alan]

> Also, many ISA-only drivers actually have hardcoded PIO numbers (eg 
> "0x1f0").

Bad example - 0x1F0 is one of those that leaked into the PCI world as
well 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] namespaces: fix exit race by splitting exit

[Oleg Nesterov]

On 01/26, Daniel Hokka Zakrisson wrote:
>
> Serge E. Hallyn wrote:
> > Ok, could you verify that the following patch at least solves
> > the oopsing?
> >
> > (I can't reproduce the oops with Daniel's test prog)
> >
> > thanks,
> > -serge
> 
> Indeed, this patch solves the oopsing, but so did the last one. I think I
> finally managed to figure out why too, as release_task would be called
> with current referring to the parent process, or whoever is reaping the
> process with the last reference to the namespace. Right?

Not always. The task can do release_task() on itself if it is sub-thread,
or its parent ignores SIGCHLD.

Anyway I think your explanation is correct for this particular test-case.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA ahci Bug in 2.6.19.x

[Alan]

> The only difference is that I don't see the "ACPI: PCI Interrupt
> :00:0f.0[B] -> GSI
> 21 (level, low) -> IRQ 19" printk. The driver is AHCI but the device
> is a VIA chip.
> 
> I'll get a caputre of the boot log when I find my serial cable. This
> could be related to the VIA PIC quirks that was changed by Alan.

Stuff a printk in and check by all means but _in theory_ the VIA quirk
shouldn't touch IRQ > 15 as those are not PIC but APIC routed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] namespaces: fix exit race by splitting exit

[Daniel Hokka Zakrisson]

Serge E. Hallyn wrote:
> Ok, could you verify that the following patch at least solves
> the oopsing?
>
> (I can't reproduce the oops with Daniel's test prog)
>
> thanks,
> -serge

Indeed, this patch solves the oopsing, but so did the last one. I think I
finally managed to figure out why too, as release_task would be called
with current referring to the parent process, or whoever is reaping the
process with the last reference to the namespace. Right?

Regardless, I have to say I prefer this patch.

-- 
Daniel Hokka Zakrisson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + make-good_sigevent-non-static.patch added to -mm tree

[Oleg Nesterov]

On 01/26, S?bastien Dugu? wrote:
>
> On Thu, 25 Jan 2007 18:43:24 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> 
> > SИbastien DuguИ wrote:
> > >
> > > +struct task_struct *good_sigevent(sigevent_t *event)
> > > +{
> > > + struct task_struct *task = current->group_leader;
> > > +
> > > + if ((event->sigev_notify & SIGEV_THREAD_ID) == SIGEV_THREAD_ID) {
> > > + task = find_task_by_pid(event->sigev_notify_thread_id);
> > > +
> > > + if (!task || task->tgid != current->tgid)
> > > + return NULL;
> > > + } else if (event->sigev_notify == SIGEV_SIGNAL) {
> > 
> > No, no, we can't use "else" here,
> > 
> > > + if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)
> > 
> > because we skip the check above in SIGEV_THREAD_ID case.
> 
>   Right, will fix this.
> 
> > 
> > This way any user can crash the kernel with a minimal effort.
> 
>   Well I tried, no crash, just the signal failing to be delivered.

sigaddset:

set->sig[sig / _NSIG_BPW] |= 1UL << (sig % _NSIG_BPW);

This writes to ->sig[event->sigev_signo / _NSIG_BPW] location, so we can
corrupt the memory if ->sigev_signo > _NSIG.

Btw, since you are exporting this function, may I suggest to rename it?
No, I can't suggest a better name :) But "good_sigevent" is a bit confusing
imho.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel 2.6.19.2 New RAID 5 Bug (oops when writing Samba -> RAID5)

[Justin Piszcz]

On Fri, 26 Jan 2007, Andrew Morton wrote:

> On Wed, 24 Jan 2007 18:37:15 -0500 (EST)
> Justin Piszcz <[EMAIL PROTECTED]> wrote:
> 
> > > Without digging too deeply, I'd say you've hit the same bug Sami Farin and
> > > others
> > > have reported starting with 2.6.19: pages mapped with kmap_atomic() become
> > > unmapped
> > > during memcpy() or similar operations.  Try disabling preempt -- that 
> > > seems to
> > > be the
> > > common factor.
> > > 
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > > the body of a message to [EMAIL PROTECTED]
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > 
> > > 
> > 
> > After I run some other tests, I am going to re-run this test and see if it 
> > OOPSes again with PREEMPT off.
> 
> Strange.  The below debug patch might catch it - please run with this
> applied.  
> 
> 
> --- a/arch/i386/mm/highmem.c~kmap_atomic-debugging
> +++ a/arch/i386/mm/highmem.c
> @@ -30,7 +30,43 @@ void *kmap_atomic(struct page *page, enu
>  {
>   enum fixed_addresses idx;
>   unsigned long vaddr;
> + static unsigned warn_count = 10;
>  
> + if (unlikely(warn_count == 0))
> + goto skip;
> +
> + if (unlikely(in_interrupt())) {
> + if (in_irq()) {
> + if (type != KM_IRQ0 && type != KM_IRQ1 &&
> + type != KM_BIO_SRC_IRQ && type != KM_BIO_DST_IRQ &&
> + type != KM_BOUNCE_READ) {
> + WARN_ON(1);
> + warn_count--;
> + }
> + } else if (!irqs_disabled()) {  /* softirq */
> + if (type != KM_IRQ0 && type != KM_IRQ1 &&
> + type != KM_SOFTIRQ0 && type != KM_SOFTIRQ1 &&
> + type != KM_SKB_SUNRPC_DATA &&
> + type != KM_SKB_DATA_SOFTIRQ &&
> + type != KM_BOUNCE_READ) {
> + WARN_ON(1);
> + warn_count--;
> + }
> + }
> + }
> +
> + if (type == KM_IRQ0 || type == KM_IRQ1 || type == KM_BOUNCE_READ) {
> + if (!irqs_disabled()) {
> + WARN_ON(1);
> + warn_count--;
> + }
> + } else if (type == KM_SOFTIRQ0 || type == KM_SOFTIRQ1) {
> + if (irq_count() == 0 && !irqs_disabled()) {
> + WARN_ON(1);
> + warn_count--;
> + }
> + }
> +skip:
>   /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
>   pagefault_disable();
>   if (!PageHighMem(page))
> _
> 
> 

The RAID5 bug may be hard to trigger, I have only made it happen once so 
far (but only tried it once, don't like locking up the raid :)), I will 
re-run the test after applying this patch.

Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] suspend/resume debugging: device filter

[Pavel Machek]

Hi!

> > it might be better to do this centrally in sysfs, via a per-device 
> > attribute, to individually enable suspend and resume on a per device 
> > basis, but my sysfs-fu is not strong enough for that now ;-)
> 
> Here's a (compile tested only) patch that does this on a per-device
> basis, which is smaller, and should work just as well as your patch.
> 
> It creates a new file in the power/ directory for every device called
> "can_suspend".  Write a '0' to it to prevent that device from being
> suspended.

Maybe we could just introduce debug_flags?

> +static ssize_t can_suspend_store(struct device *dev,
> +  struct device_attribute *attr,
> +  const char *buf, size_t n)
> +{
> + if (!n)
> + return -EINVAL;
> +
> + switch (buf[0]) {
> + case 'y':
> + case 'Y':
> + case '1':
> + dev->no_suspend = 0;
> + break;
> + case 'n':
> + case 'N':
> + case '0':
> + dev->no_suspend = 1;
> + break;

default: return -EINVAL ?

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + make-good_sigevent-non-static.patch added to -mm tree

[Sébastien Dugué]

On Thu, 25 Jan 2007 18:43:24 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote:

> SИbastien DuguИ wrote:
> >
> > +struct task_struct *good_sigevent(sigevent_t *event)
> > +{
> > +   struct task_struct *task = current->group_leader;
> > +
> > +   if ((event->sigev_notify & SIGEV_THREAD_ID) == SIGEV_THREAD_ID) {
> > +   task = find_task_by_pid(event->sigev_notify_thread_id);
> > +
> > +   if (!task || task->tgid != current->tgid)
> > +   return NULL;
> > +   } else if (event->sigev_notify == SIGEV_SIGNAL) {
> 
> No, no, we can't use "else" here,
> 
> > +   if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)
> 
> because we skip the check above in SIGEV_THREAD_ID case.

  Right, will fix this.

> 
> This way any user can crash the kernel with a minimal effort.

  Well I tried, no crash, just the signal failing to be delivered.

  Thanks,

  Sébastien.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Pavel Machek]

Hi!
> >
> >>But I still believe it can be out.
> >>
> >> Do you believe it could be a user-space daemon or 
> >what?
> >
> >Yes, what prevents userspace daemon watching 
> >/dev/input/event* to
> >provide this functionality?
> >Pavel
> ---
> 
> One possible argument is to allow integrating 
> "input-like" user events
> with other kinds of system-level events that you might 
> want to have
> treated like user activity. For instance, our definition 
> of user
> activity includes: button presses, opening-closing the 
> cover (on a
> phone), and plugging in or removing memory cards, 
> accessories, or
> cables. We actually use a mix of kernel and user-space 
> monitoring,

Well... input already has 'pseudokey' for lid, and yes, you
probably can monitor cover, memory cards and cables from userspace,
already... as you do. Cover, and maybe even cards/cables could be
integrated with input infrastructure, too.

(Still waiting for you to start selling those cool phones in czech
republic :-).

> A user-space monitor also has more opportunity for races 
> - for
> instance, deciding that the inactivity timeout has 
> occurred between
> the time that the user does something and the time that 
> the kernel
> gets a notification up to user space.

Same races are inside kernel, too.

> My own hot button is making sure that the definition of 
> what
> constitutes user activity is managed in exactly one 
> place, whether in
> the kernel or not. My naive model would be to put the 
> response at user
> level, but to provide a single point of definition in 
> the kernel (say,
> /dev/useractivity or the equivalent) that the user-level 
> daemon could
> listen to.

Actually, I believe right solution is to provide one, unified,
monitoring daemon, using whatever interfaces are available. (+ add
missing functionality to the kernel, if neccessary).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] ARM: Convert to use shared APM emulation.

[Pavel Machek]

Hi!

> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
> 
>  arch/arm/Kconfig   |   29 ++
>  arch/arm/common/sharpsl_pm.c   |2 -
>  arch/arm/kernel/Makefile   |1 
>  arch/arm/mach-pxa/corgi_pm.c   |2 -
>  arch/arm/mach-pxa/sharpsl_pm.c |2 -
>  arch/arm/mach-pxa/spitz_pm.c   |2 -
>  include/asm-arm/apm.h  |   64 
> -
>  7 files changed, 8 insertions(+), 94 deletions(-)

Maybe you should delete apm.c, too?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit

[Pavel Machek]

Hi!

> > > Should we introduce per-arch asm/elf.h files to hold the relevant flag 
> > > definitions then?
> > 
> > On some architectures there are no bits left.  On others you'd need to go
> > through whomever maintains the relevant psABI to get a bit officially
> > allocated.  Really, it is very bad idea to use e_flags for this.
> 
> How does one find the relevant maintainers?

Andi Kleen maintains both i386 and x86-64, so it should be easy.

(Ouch and make it one patch, it is too short to split...)

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel 2.6.19.2 New RAID 5 Bug (oops when writing Samba -> RAID5)

[Andrew Morton]

On Wed, 24 Jan 2007 18:37:15 -0500 (EST)
Justin Piszcz <[EMAIL PROTECTED]> wrote:

> > Without digging too deeply, I'd say you've hit the same bug Sami Farin and
> > others
> > have reported starting with 2.6.19: pages mapped with kmap_atomic() become
> > unmapped
> > during memcpy() or similar operations.  Try disabling preempt -- that seems 
> > to
> > be the
> > common factor.
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > 
> 
> After I run some other tests, I am going to re-run this test and see if it 
> OOPSes again with PREEMPT off.

Strange.  The below debug patch might catch it - please run with this
applied.  


--- a/arch/i386/mm/highmem.c~kmap_atomic-debugging
+++ a/arch/i386/mm/highmem.c
@@ -30,7 +30,43 @@ void *kmap_atomic(struct page *page, enu
 {
enum fixed_addresses idx;
unsigned long vaddr;
+   static unsigned warn_count = 10;
 
+   if (unlikely(warn_count == 0))
+   goto skip;
+
+   if (unlikely(in_interrupt())) {
+   if (in_irq()) {
+   if (type != KM_IRQ0 && type != KM_IRQ1 &&
+   type != KM_BIO_SRC_IRQ && type != KM_BIO_DST_IRQ &&
+   type != KM_BOUNCE_READ) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   } else if (!irqs_disabled()) {  /* softirq */
+   if (type != KM_IRQ0 && type != KM_IRQ1 &&
+   type != KM_SOFTIRQ0 && type != KM_SOFTIRQ1 &&
+   type != KM_SKB_SUNRPC_DATA &&
+   type != KM_SKB_DATA_SOFTIRQ &&
+   type != KM_BOUNCE_READ) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   }
+   }
+
+   if (type == KM_IRQ0 || type == KM_IRQ1 || type == KM_BOUNCE_READ) {
+   if (!irqs_disabled()) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   } else if (type == KM_SOFTIRQ0 || type == KM_SOFTIRQ1) {
+   if (irq_count() == 0 && !irqs_disabled()) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   }
+skip:
/* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
pagefault_disable();
if (!PageHighMem(page))
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA ahci Bug in 2.6.19.x

[Stefan Priebe - FH]

Hi!

acpi=off does not help i've already tried that.


Ok here some outputs:
1.) complete dmesg with 2.6.16.27 (works)

Linux version 2.6.16.27amd ([EMAIL PROTECTED]) (gcc version 3.3.5 
(Debian 1:3.3.5-13)) #6 SMP Sat Aug 26 14:29:07 CEST 2006

BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 3bfb (usable)
 BIOS-e820: 3bfb - 3bfbe000 (ACPI data)
 BIOS-e820: 3bfbe000 - 3bfe (ACPI NVS)
 BIOS-e820: 3bfe - 3c00 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fecc - fecc1000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
ACPI: RSDP (v002 ACPIAM) @ 
0x000fa850
ACPI: XSDT (v001 A M I  OEMXSDT  0x12000527 MSFT 0x0097) @ 
0x3bfb0100
ACPI: FADT (v003 A M I  OEMFACP  0x12000527 MSFT 0x0097) @ 
0x3bfb0290
ACPI: MADT (v001 A M I  OEMAPIC  0x12000527 MSFT 0x0097) @ 
0x3bfb0390
ACPI: MCFG (v001 A M I  OEMMCFG  0x12000527 MSFT 0x0097) @ 
0x3bfb0400
ACPI: OEMB (v001 A M I  AMI_OEM  0x12000527 MSFT 0x0097) @ 
0x3bfbe040
ACPI: DSDT (v001  A0339 A0339000 0x INTL 0x02002026) @ 
0x

Scanning NUMA topology in Northbridge 24
Number of nodes 1
Node 0 MemBase  Limit 3bfb
NUMA: Using 63 for the hash shift.
Using node hash shift of 63
Bootmem setup node 0 -3bfb
On node 0 totalpages: 240991
  DMA zone: 2709 pages, LIFO batch:0
  DMA32 zone: 238282 pages, LIFO batch:31
  Normal zone: 0 pages, LIFO batch:0
  HighMem zone: 0 pages, LIFO batch:0
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:15 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23
ACPI: IOAPIC (id[0x02] address[0xfecc] gsi_base[24])
IOAPIC[1]: apic_id 2, version 3, address 0xfecc, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 3c00:c2c0)
Checking aperture...
CPU 0: aperture @ f000 size 128 MB
Built 1 zonelists
Kernel command line: root=/dev/sda6 ro rootflags=quota Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2400.214 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 962212k/982720k available (2939k kernel code, 20120k reserved, 
1327k data, 220k init)
Calibrating delay using timer specific routine.. 4810.51 BogoMIPS 
(lpj=9621030)

Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0(1) -> Node 0 -> Core 0
Using local APIC timer interrupts.
result 12501128
Detected 12.501 MHz APIC timer.
Brought up 1 CPUs
testing NMI watchdog ... OK.
migration_cost=0
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
PCI: Using MMCONFIG at e000
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is :01:00.0
PCI: Transparent bridge - :00:13.1
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NBPG._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NBP0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P7._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PA._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 *14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, 
disabled.

ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Fri, 2007-01-26 at 00:51 -0800, Andrew Morton wrote:

> A patch against next -mm would suit, thanks.
> 
> (But we already use atomic_long_t in generic code?)

but there is currently no atomic_long_{inc,dec}_return, or any
atomic_long_*_return function for that matter.

Mathieu adds these missing functions.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Andrew Morton]

On Fri, 26 Jan 2007 09:03:37 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:

> On Thu, 2007-01-25 at 22:04 -0800, Andrew Morton wrote:
> > On Thu, 25 Jan 2007 21:31:43 -0800 (PST)
> > Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > 
> > > On Thu, 25 Jan 2007, Andrew Morton wrote:
> > > 
> > > > atomic_t is 32-bit.  Put 16TB of memory under writeback and blam.
> > > 
> > > We have systems with 8TB main memory and are able to get to 16TB.
> > 
> > But I bet you don't use 4k pages on 'em ;)
> > 
> > > Better change it now.
> > 
> > yup.
> 
> I can change to atomic_long_t but that would make this patch depend on
> Mathieu Desnoyers' atomic.h patch series.
> 
> Do I send out a -v5 with this, or should I send an incremental patch
> once that hits your tree?

A patch against next -mm would suit, thanks.

(But we already use atomic_long_t in generic code?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Fri, 2007-01-26 at 09:00 +0100, Peter Zijlstra wrote:
> On Thu, 2007-01-25 at 21:02 -0800, Andrew Morton wrote:
> > On Thu, 25 Jan 2007 16:32:28 +0100
> > Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > 
> > > +long congestion_wait_interruptible(int rw, long timeout)
> > > +{
> > > + long ret;
> > > + DEFINE_WAIT(wait);
> > > + wait_queue_head_t *wqh = _wqh[rw];
> > > +
> > > + prepare_to_wait(wqh, , TASK_INTERRUPTIBLE);
> > > + if (signal_pending(current))
> > > + ret = -ERESTARTSYS;
> > > + else
> > > + ret = io_schedule_timeout(timeout);
> > > + finish_wait(wqh, );
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(congestion_wait_interruptible);
> > 
> > I think this can share code with congestion_wait()?
> > 
> > static long __congestion_wait(int rw, long timeout, int state)
> > {
> > long ret;
> > DEFINE_WAIT(wait);
> > wait_queue_head_t *wqh = _wqh[rw];
> > 
> > prepare_to_wait(wqh, , state);
> > ret = io_schedule_timeout(timeout);
> > finish_wait(wqh, );
> > return ret;
> > }
> > 
> > long congestion_wait_interruptible(int rw, long timeout)
> > {
> > long ret = __congestion_wait(rw, timeout);
> > 
> > if (signal_pending(current))
> > ret = -ERESTARTSYS;
> > return ret;
> > }
> > 
> > it's only infinitesimally less efficient..
> 
> All the other _interruptible functions check signal_pending before
> calling schedule. Which seems to make sense since its called in a loop
> anyway, and if the loop condition turns false when interrupted you might
> as well just finish up instead of bailing out.
> 
> However if you'd rather see your version, who am I to object ;-)

ok, first wake up, then reply to emails :-)

How about this:

long congestion_wait_interruptible(int rw, long timeout)
{
long ret;

if (signal_pending(current))
ret = -ERESTARTSYS;
else
ret = congestion_wait(rw, timeout);
return ret;
}
EXPORT_SYMBOL(congestion_wait_interruptible);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [i2c] [PATCH] Add support for OneForAll remote JP1 parallel port interface

[Jean Delvare]

Hi Jonathan,

On Thu, 25 Jan 2007 18:41:39 +, Jonathan McDowell wrote:
> This simple patch adds support to i2c-parport for the OneForAll remote
> JP1 parallel port interfaces which can be found detailed at:
> 
> http://www.hifi-remote.com/jp1/hardware.shtml
> 
> These allow access to the internal configuration EEPROM on various
> remote controls and there are a variety of Windows tools that make use
> of this hardware. I have tested this patch with the "simple" parallel
> port device and a OneForAll URC-7562 and confirmed that the data read
> using the eeprom i2c driver matches that returned by the Windows "IR"
> JP1 tool.
> 
> Signed-Off-By: Jonathan McDowell <[EMAIL PROTECTED]>

Patch applied, thanks.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Thu, 2007-01-25 at 22:04 -0800, Andrew Morton wrote:
> On Thu, 25 Jan 2007 21:31:43 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, 25 Jan 2007, Andrew Morton wrote:
> > 
> > > atomic_t is 32-bit.  Put 16TB of memory under writeback and blam.
> > 
> > We have systems with 8TB main memory and are able to get to 16TB.
> 
> But I bet you don't use 4k pages on 'em ;)
> 
> > Better change it now.
> 
> yup.

I can change to atomic_long_t but that would make this patch depend on
Mathieu Desnoyers' atomic.h patch series.

Do I send out a -v5 with this, or should I send an incremental patch
once that hits your tree?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rft] r8169: merge release 6.001.00 of Realtek's driver - take #1

[Jeff Garzik]

Francois Romieu wrote:

Untested, straight from the "release early" dept. You have been warned.

Realtek's driver restricts itself to 0x8169 and 0x8167.
It won't be surprising if it breaks on anything else until
I merge the new 0x8168 and 0x8136 bits.

Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>


FWIW I would like to see if we can train RealTek to directly submit 
kernel patches, and try to mentor them into helping you maintain the 
RealTek stuff.


Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: what kernel version embeds r1000 (RTL8168 Eth NICs)

[Boris B. Zhmurov]

Hello, Bernhard Walle.

On 25.01.2007 12:36 you said the following:


* Mihamina Rakotomandimby (R12y) <[EMAIL PROTECTED]> [2007-01-25 02:36]:

Hello,
I would like to know what version of the kernel will||had embed(ed) the
r1000 driver.


The r8169 driver which is in the kernel should have the same
functionality.



No, it shouldn't and it hasn't. RTL8168 and RTL8167 support was added in
2.6.19.


--
boris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[David Miller]

From: David Woodhouse <[EMAIL PROTECTED]>
Date: Fri, 26 Jan 2007 13:09:40 +0800

> My question was about _how_ you think this should be achieved in this
> particular case. You didn't like the suggestion that we should put your
> new special-case hack into the resource code... where/how _do_ you
> suggest that it's done, so that we can protect those poor driver authors
> from the number zero?

Just set some high bit in the arch code that creates the resources,
then when you interpret them in arch code simply clear the bit.

That's effectively what happens on sparc64 since all non-memory
physical addressing occurs at the top of the physical address
space.  But you don't need that layout, you can fake it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[David Miller]

From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 25 Jan 2007 22:18:21 -0800 (PST)

> So on sparc64, "ioport_resource" really is just a container for the actual 
> per-domain resource buckets that the hardware (within that domain) will 
> then do the resource allocation from. Afaik.
> 
> But you should actaully verify that with somebody like Davem if you 
> _really_ care.  I cc'd him in case he wants to pipe up and perhaps prove 
> me wrong.

They are all physical addresses of the I/O locations.

It just so happens that all the non-memory physicall addresses
have some high bit set.

So it all works out, but not intentionally, it's merely a side
effect of how the physical address space is layed out.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[David Miller]

From: Greg KH <[EMAIL PROTECTED]>
Date: Thu, 25 Jan 2007 22:17:56 -0800

> On Thu, Jan 25, 2007 at 10:28:49PM -0500, Theodore Tso wrote:
> > On Fri, Jan 26, 2007 at 06:16:13AM +0530, Sunil Naidu wrote:
> > > Good thoughts ;-)  I too believe in this - Where there is a Will,
> > > there is a Way! That's the reason why I have proposed India as the
> > > location for KS 2007, am still awaiting for the response from Theodore
> > > Tso.
> > 
> > I did give you a response.  Find a way to pay for 80+ kernel summit
> > invitees to travel to India (preferably in business class :-), and
> > we'll talk.  That's not realistic?  Well, then perhaps having the
> > concept of holding Kernel Summit in India is not realistic.
> 
> Does this mean that the attendees of the 2007 summit in England all get
> business class tickets to travel to it?
> 
> Sounds good to me!

Yeah, it seems like Ted is using unfair apples-to-oranges comparisons
here.

People all went to Australia mostly in cattle class just fine.  Just
put an extra day on one side to recover from jet lag, you don't need
business class to accomplish that.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Thu, 2007-01-25 at 21:02 -0800, Andrew Morton wrote:
> On Thu, 25 Jan 2007 16:32:28 +0100
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> 
> > +long congestion_wait_interruptible(int rw, long timeout)
> > +{
> > +   long ret;
> > +   DEFINE_WAIT(wait);
> > +   wait_queue_head_t *wqh = _wqh[rw];
> > +
> > +   prepare_to_wait(wqh, , TASK_INTERRUPTIBLE);
> > +   if (signal_pending(current))
> > +   ret = -ERESTARTSYS;
> > +   else
> > +   ret = io_schedule_timeout(timeout);
> > +   finish_wait(wqh, );
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL(congestion_wait_interruptible);
> 
> I think this can share code with congestion_wait()?
> 
> static long __congestion_wait(int rw, long timeout, int state)
> {
>   long ret;
>   DEFINE_WAIT(wait);
>   wait_queue_head_t *wqh = _wqh[rw];
> 
>   prepare_to_wait(wqh, , state);
>   ret = io_schedule_timeout(timeout);
>   finish_wait(wqh, );
>   return ret;
> }
> 
> long congestion_wait_interruptible(int rw, long timeout)
> {
>   long ret = __congestion_wait(rw, timeout);
> 
>   if (signal_pending(current))
>   ret = -ERESTARTSYS;
>   return ret;
> }
> 
> it's only infinitesimally less efficient..

All the other _interruptible functions check signal_pending before
calling schedule. Which seems to make sense since its called in a loop
anyway, and if the loop condition turns false when interrupted you might
as well just finish up instead of bailing out.

However if you'd rather see your version, who am I to object ;-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] incorrect direct io error handling (v3)

[Dmitriy Monakhov]

Andrew Morton <[EMAIL PROTECTED]> writes:

> On Wed, 24 Jan 2007 22:05:06 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
>
>> incorrect direct io error handling (v3)
>> Changes from v2:
>>  - Remove BUG_ON(!mutex_is_locked(..)) for non blkdev.
>>  - vmtruncate() called from generic_file_aio_write().
>>  - depends on patch titled:
>>[PATH][RFC] mm: Move common segments checks to separate function
>
> drat, I skipped that patch due to rejects, and because Nick is working on
> things in the same area.
>
[skip]
>>  if ((written >= 0 || written == -EIOCBQUEUED) &&
>>  ((file->f_flags & O_SYNC) || IS_SYNC(inode))) {
>> @@ -2365,6 +2366,17 @@ ssize_t generic_file_aio_write(struct ki
>>  >ki_pos);
>>  mutex_unlock(>i_mutex);
>>  
>> +if (unlikely(ret < 0 && (file->f_flags & O_DIRECT))) {
>> +ssize_t cnt = generic_segment_checks(nr_segs, iov, VERIFY_READ);
>> +loff_t isize = i_size_read(inode);
>> +/*
>> + * generic_file_direct_write() may have instantiated a few 
>> + * blocks outside i_size.  Trim these off again.
>> + */
>> +if (cnt > 0 && (pos + cnt > isize))
>> +vmtruncate(inode, isize);
>> +}
>> +
>
> vmtruncate() really wants i_mutex to be held.  Can't we do that here?
Yepp 110% true, baaahh . it looks like my brain was't clear at the time i
wrote this. We have to do vmtruncate() brfore droping i_mutex , right after
__generic_file_aio_write_nolock() call , i'm sorry to waste your time. 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Thu, 2007-01-25 at 21:02 -0800, Andrew Morton wrote:
 On Thu, 25 Jan 2007 16:32:28 +0100
 Peter Zijlstra [EMAIL PROTECTED] wrote:
 
  +long congestion_wait_interruptible(int rw, long timeout)
  +{
  +   long ret;
  +   DEFINE_WAIT(wait);
  +   wait_queue_head_t *wqh = congestion_wqh[rw];
  +
  +   prepare_to_wait(wqh, wait, TASK_INTERRUPTIBLE);
  +   if (signal_pending(current))
  +   ret = -ERESTARTSYS;
  +   else
  +   ret = io_schedule_timeout(timeout);
  +   finish_wait(wqh, wait);
  +   return ret;
  +}
  +EXPORT_SYMBOL(congestion_wait_interruptible);
 
 I think this can share code with congestion_wait()?
 
 static long __congestion_wait(int rw, long timeout, int state)
 {
   long ret;
   DEFINE_WAIT(wait);
   wait_queue_head_t *wqh = congestion_wqh[rw];
 
   prepare_to_wait(wqh, wait, state);
   ret = io_schedule_timeout(timeout);
   finish_wait(wqh, wait);
   return ret;
 }
 
 long congestion_wait_interruptible(int rw, long timeout)
 {
   long ret = __congestion_wait(rw, timeout);
 
   if (signal_pending(current))
   ret = -ERESTARTSYS;
   return ret;
 }
 
 it's only infinitesimally less efficient..

All the other _interruptible functions check signal_pending before
calling schedule. Which seems to make sense since its called in a loop
anyway, and if the loop condition turns false when interrupted you might
as well just finish up instead of bailing out.

However if you'd rather see your version, who am I to object ;-)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[David Miller]

From: Greg KH [EMAIL PROTECTED]
Date: Thu, 25 Jan 2007 22:17:56 -0800

 On Thu, Jan 25, 2007 at 10:28:49PM -0500, Theodore Tso wrote:
  On Fri, Jan 26, 2007 at 06:16:13AM +0530, Sunil Naidu wrote:
   Good thoughts ;-)  I too believe in this - Where there is a Will,
   there is a Way! That's the reason why I have proposed India as the
   location for KS 2007, am still awaiting for the response from Theodore
   Tso.
  
  I did give you a response.  Find a way to pay for 80+ kernel summit
  invitees to travel to India (preferably in business class :-), and
  we'll talk.  That's not realistic?  Well, then perhaps having the
  concept of holding Kernel Summit in India is not realistic.
 
 Does this mean that the attendees of the 2007 summit in England all get
 business class tickets to travel to it?
 
 Sounds good to me!

Yeah, it seems like Ted is using unfair apples-to-oranges comparisons
here.

People all went to Australia mostly in cattle class just fine.  Just
put an extra day on one side to recover from jet lag, you don't need
business class to accomplish that.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[David Miller]

From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 25 Jan 2007 22:18:21 -0800 (PST)

 So on sparc64, ioport_resource really is just a container for the actual 
 per-domain resource buckets that the hardware (within that domain) will 
 then do the resource allocation from. Afaik.
 
 But you should actaully verify that with somebody like Davem if you 
 _really_ care.  I cc'd him in case he wants to pipe up and perhaps prove 
 me wrong.

They are all physical addresses of the I/O locations.

It just so happens that all the non-memory physicall addresses
have some high bit set.

So it all works out, but not intentionally, it's merely a side
effect of how the physical address space is layed out.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[David Miller]

From: David Woodhouse [EMAIL PROTECTED]
Date: Fri, 26 Jan 2007 13:09:40 +0800

 My question was about _how_ you think this should be achieved in this
 particular case. You didn't like the suggestion that we should put your
 new special-case hack into the resource code... where/how _do_ you
 suggest that it's done, so that we can protect those poor driver authors
 from the number zero?

Just set some high bit in the arch code that creates the resources,
then when you interpret them in arch code simply clear the bit.

That's effectively what happens on sparc64 since all non-memory
physical addressing occurs at the top of the physical address
space.  But you don't need that layout, you can fake it.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: what kernel version embeds r1000 (RTL8168 Eth NICs)

[Boris B. Zhmurov]

Hello, Bernhard Walle.

On 25.01.2007 12:36 you said the following:


* Mihamina Rakotomandimby (R12y) [EMAIL PROTECTED] [2007-01-25 02:36]:

Hello,
I would like to know what version of the kernel will||had embed(ed) the
r1000 driver.


The r8169 driver which is in the kernel should have the same
functionality.



No, it shouldn't and it hasn't. RTL8168 and RTL8167 support was added in
2.6.19.


--
boris

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Thu, 2007-01-25 at 22:04 -0800, Andrew Morton wrote:
 On Thu, 25 Jan 2007 21:31:43 -0800 (PST)
 Christoph Lameter [EMAIL PROTECTED] wrote:
 
  On Thu, 25 Jan 2007, Andrew Morton wrote:
  
   atomic_t is 32-bit.  Put 16TB of memory under writeback and blam.
  
  We have systems with 8TB main memory and are able to get to 16TB.
 
 But I bet you don't use 4k pages on 'em ;)
 
  Better change it now.
 
 yup.

I can change to atomic_long_t but that would make this patch depend on
Mathieu Desnoyers' atomic.h patch series.

Do I send out a -v5 with this, or should I send an incremental patch
once that hits your tree?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [i2c] [PATCH] Add support for OneForAll remote JP1 parallel port interface

[Jean Delvare]

Hi Jonathan,

On Thu, 25 Jan 2007 18:41:39 +, Jonathan McDowell wrote:
 This simple patch adds support to i2c-parport for the OneForAll remote
 JP1 parallel port interfaces which can be found detailed at:
 
 http://www.hifi-remote.com/jp1/hardware.shtml
 
 These allow access to the internal configuration EEPROM on various
 remote controls and there are a variety of Windows tools that make use
 of this hardware. I have tested this patch with the simple parallel
 port device and a OneForAll URC-7562 and confirmed that the data read
 using the eeprom i2c driver matches that returned by the Windows IR
 JP1 tool.
 
 Signed-Off-By: Jonathan McDowell [EMAIL PROTECTED]

Patch applied, thanks.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Fri, 2007-01-26 at 09:00 +0100, Peter Zijlstra wrote:
 On Thu, 2007-01-25 at 21:02 -0800, Andrew Morton wrote:
  On Thu, 25 Jan 2007 16:32:28 +0100
  Peter Zijlstra [EMAIL PROTECTED] wrote:
  
   +long congestion_wait_interruptible(int rw, long timeout)
   +{
   + long ret;
   + DEFINE_WAIT(wait);
   + wait_queue_head_t *wqh = congestion_wqh[rw];
   +
   + prepare_to_wait(wqh, wait, TASK_INTERRUPTIBLE);
   + if (signal_pending(current))
   + ret = -ERESTARTSYS;
   + else
   + ret = io_schedule_timeout(timeout);
   + finish_wait(wqh, wait);
   + return ret;
   +}
   +EXPORT_SYMBOL(congestion_wait_interruptible);
  
  I think this can share code with congestion_wait()?
  
  static long __congestion_wait(int rw, long timeout, int state)
  {
  long ret;
  DEFINE_WAIT(wait);
  wait_queue_head_t *wqh = congestion_wqh[rw];
  
  prepare_to_wait(wqh, wait, state);
  ret = io_schedule_timeout(timeout);
  finish_wait(wqh, wait);
  return ret;
  }
  
  long congestion_wait_interruptible(int rw, long timeout)
  {
  long ret = __congestion_wait(rw, timeout);
  
  if (signal_pending(current))
  ret = -ERESTARTSYS;
  return ret;
  }
  
  it's only infinitesimally less efficient..
 
 All the other _interruptible functions check signal_pending before
 calling schedule. Which seems to make sense since its called in a loop
 anyway, and if the loop condition turns false when interrupted you might
 as well just finish up instead of bailing out.
 
 However if you'd rather see your version, who am I to object ;-)

ok, first wake up, then reply to emails :-)

How about this:

long congestion_wait_interruptible(int rw, long timeout)
{
long ret;

if (signal_pending(current))
ret = -ERESTARTSYS;
else
ret = congestion_wait(rw, timeout);
return ret;
}
EXPORT_SYMBOL(congestion_wait_interruptible);


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Andrew Morton]

On Fri, 26 Jan 2007 09:03:37 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:

 On Thu, 2007-01-25 at 22:04 -0800, Andrew Morton wrote:
  On Thu, 25 Jan 2007 21:31:43 -0800 (PST)
  Christoph Lameter [EMAIL PROTECTED] wrote:
  
   On Thu, 25 Jan 2007, Andrew Morton wrote:
   
atomic_t is 32-bit.  Put 16TB of memory under writeback and blam.
   
   We have systems with 8TB main memory and are able to get to 16TB.
  
  But I bet you don't use 4k pages on 'em ;)
  
   Better change it now.
  
  yup.
 
 I can change to atomic_long_t but that would make this patch depend on
 Mathieu Desnoyers' atomic.h patch series.
 
 Do I send out a -v5 with this, or should I send an incremental patch
 once that hits your tree?

A patch against next -mm would suit, thanks.

(But we already use atomic_long_t in generic code?)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfs: fix congestion control -v4

[Peter Zijlstra]

On Fri, 2007-01-26 at 00:51 -0800, Andrew Morton wrote:

 A patch against next -mm would suit, thanks.
 
 (But we already use atomic_long_t in generic code?)

but there is currently no atomic_long_{inc,dec}_return, or any
atomic_long_*_return function for that matter.

Mathieu adds these missing functions.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA ahci Bug in 2.6.19.x

[Stefan Priebe - FH]

Hi!

acpi=off does not help i've already tried that.


Ok here some outputs:
1.) complete dmesg with 2.6.16.27 (works)

Linux version 2.6.16.27amd ([EMAIL PROTECTED]) (gcc version 3.3.5 
(Debian 1:3.3.5-13)) #6 SMP Sat Aug 26 14:29:07 CEST 2006

BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 3bfb (usable)
 BIOS-e820: 3bfb - 3bfbe000 (ACPI data)
 BIOS-e820: 3bfbe000 - 3bfe (ACPI NVS)
 BIOS-e820: 3bfe - 3c00 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fecc - fecc1000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
ACPI: RSDP (v002 ACPIAM) @ 
0x000fa850
ACPI: XSDT (v001 A M I  OEMXSDT  0x12000527 MSFT 0x0097) @ 
0x3bfb0100
ACPI: FADT (v003 A M I  OEMFACP  0x12000527 MSFT 0x0097) @ 
0x3bfb0290
ACPI: MADT (v001 A M I  OEMAPIC  0x12000527 MSFT 0x0097) @ 
0x3bfb0390
ACPI: MCFG (v001 A M I  OEMMCFG  0x12000527 MSFT 0x0097) @ 
0x3bfb0400
ACPI: OEMB (v001 A M I  AMI_OEM  0x12000527 MSFT 0x0097) @ 
0x3bfbe040
ACPI: DSDT (v001  A0339 A0339000 0x INTL 0x02002026) @ 
0x

Scanning NUMA topology in Northbridge 24
Number of nodes 1
Node 0 MemBase  Limit 3bfb
NUMA: Using 63 for the hash shift.
Using node hash shift of 63
Bootmem setup node 0 -3bfb
On node 0 totalpages: 240991
  DMA zone: 2709 pages, LIFO batch:0
  DMA32 zone: 238282 pages, LIFO batch:31
  Normal zone: 0 pages, LIFO batch:0
  HighMem zone: 0 pages, LIFO batch:0
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:15 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23
ACPI: IOAPIC (id[0x02] address[0xfecc] gsi_base[24])
IOAPIC[1]: apic_id 2, version 3, address 0xfecc, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 3c00:c2c0)
Checking aperture...
CPU 0: aperture @ f000 size 128 MB
Built 1 zonelists
Kernel command line: root=/dev/sda6 ro rootflags=quota Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2400.214 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 962212k/982720k available (2939k kernel code, 20120k reserved, 
1327k data, 220k init)
Calibrating delay using timer specific routine.. 4810.51 BogoMIPS 
(lpj=9621030)

Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0(1) - Node 0 - Core 0
Using local APIC timer interrupts.
result 12501128
Detected 12.501 MHz APIC timer.
Brought up 1 CPUs
testing NMI watchdog ... OK.
migration_cost=0
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
PCI: Using MMCONFIG at e000
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is :01:00.0
PCI: Transparent bridge - :00:13.1
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NBPG._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NBP0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P7._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PA._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 *14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, 
disabled.

ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices

Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit

[Pavel Machek]

Hi!

   Should we introduce per-arch asm/elf.h files to hold the relevant flag 
   definitions then?
  
  On some architectures there are no bits left.  On others you'd need to go
  through whomever maintains the relevant psABI to get a bit officially
  allocated.  Really, it is very bad idea to use e_flags for this.
 
 How does one find the relevant maintainers?

Andi Kleen maintains both i386 and x86-64, so it should be easy.

(Ouch and make it one patch, it is too short to split...)

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Pavel Machek]

Hi!
 
 But I still believe it can be out.
 
  Do you believe it could be a user-space daemon or 
 what?
 
 Yes, what prevents userspace daemon watching 
 /dev/input/event* to
 provide this functionality?
 Pavel
 ---
 
 One possible argument is to allow integrating 
 input-like user events
 with other kinds of system-level events that you might 
 want to have
 treated like user activity. For instance, our definition 
 of user
 activity includes: button presses, opening-closing the 
 cover (on a
 phone), and plugging in or removing memory cards, 
 accessories, or
 cables. We actually use a mix of kernel and user-space 
 monitoring,

Well... input already has 'pseudokey' for lid, and yes, you
probably can monitor cover, memory cards and cables from userspace,
already... as you do. Cover, and maybe even cards/cables could be
integrated with input infrastructure, too.

(Still waiting for you to start selling those cool phones in czech
republic :-).

 A user-space monitor also has more opportunity for races 
 - for
 instance, deciding that the inactivity timeout has 
 occurred between
 the time that the user does something and the time that 
 the kernel
 gets a notification up to user space.

Same races are inside kernel, too.

 My own hot button is making sure that the definition of 
 what
 constitutes user activity is managed in exactly one 
 place, whether in
 the kernel or not. My naive model would be to put the 
 response at user
 level, but to provide a single point of definition in 
 the kernel (say,
 /dev/useractivity or the equivalent) that the user-level 
 daemon could
 listen to.

Actually, I believe right solution is to provide one, unified,
monitoring daemon, using whatever interfaces are available. (+ add
missing functionality to the kernel, if neccessary).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] ARM: Convert to use shared APM emulation.

[Pavel Machek]

Hi!

 Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
 
  arch/arm/Kconfig   |   29 ++
  arch/arm/common/sharpsl_pm.c   |2 -
  arch/arm/kernel/Makefile   |1 
  arch/arm/mach-pxa/corgi_pm.c   |2 -
  arch/arm/mach-pxa/sharpsl_pm.c |2 -
  arch/arm/mach-pxa/spitz_pm.c   |2 -
  include/asm-arm/apm.h  |   64 
 -
  7 files changed, 8 insertions(+), 94 deletions(-)

Maybe you should delete apm.c, too?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + make-good_sigevent-non-static.patch added to -mm tree

[Sébastien Dugué]

On Thu, 25 Jan 2007 18:43:24 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:

 SИbastien DuguИ wrote:
 
  +struct task_struct *good_sigevent(sigevent_t *event)
  +{
  +   struct task_struct *task = current-group_leader;
  +
  +   if ((event-sigev_notify  SIGEV_THREAD_ID) == SIGEV_THREAD_ID) {
  +   task = find_task_by_pid(event-sigev_notify_thread_id);
  +
  +   if (!task || task-tgid != current-tgid)
  +   return NULL;
  +   } else if (event-sigev_notify == SIGEV_SIGNAL) {
 
 No, no, we can't use else here,
 
  +   if (event-sigev_signo = 0 || event-sigev_signo  SIGRTMAX)
 
 because we skip the check above in SIGEV_THREAD_ID case.

  Right, will fix this.

 
 This way any user can crash the kernel with a minimal effort.

  Well I tried, no crash, just the signal failing to be delivered.

  Thanks,

  Sébastien.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] suspend/resume debugging: device filter

[Pavel Machek]

Hi!

  it might be better to do this centrally in sysfs, via a per-device 
  attribute, to individually enable suspend and resume on a per device 
  basis, but my sysfs-fu is not strong enough for that now ;-)
 
 Here's a (compile tested only) patch that does this on a per-device
 basis, which is smaller, and should work just as well as your patch.
 
 It creates a new file in the power/ directory for every device called
 can_suspend.  Write a '0' to it to prevent that device from being
 suspended.

Maybe we could just introduce debug_flags?

 +static ssize_t can_suspend_store(struct device *dev,
 +  struct device_attribute *attr,
 +  const char *buf, size_t n)
 +{
 + if (!n)
 + return -EINVAL;
 +
 + switch (buf[0]) {
 + case 'y':
 + case 'Y':
 + case '1':
 + dev-no_suspend = 0;
 + break;
 + case 'n':
 + case 'N':
 + case '0':
 + dev-no_suspend = 1;
 + break;

default: return -EINVAL ?

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + make-good_sigevent-non-static.patch added to -mm tree

[Oleg Nesterov]

On 01/26, S?bastien Dugu? wrote:

 On Thu, 25 Jan 2007 18:43:24 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:
 
  SИbastien DuguИ wrote:
  
   +struct task_struct *good_sigevent(sigevent_t *event)
   +{
   + struct task_struct *task = current-group_leader;
   +
   + if ((event-sigev_notify  SIGEV_THREAD_ID) == SIGEV_THREAD_ID) {
   + task = find_task_by_pid(event-sigev_notify_thread_id);
   +
   + if (!task || task-tgid != current-tgid)
   + return NULL;
   + } else if (event-sigev_notify == SIGEV_SIGNAL) {
  
  No, no, we can't use else here,
  
   + if (event-sigev_signo = 0 || event-sigev_signo  SIGRTMAX)
  
  because we skip the check above in SIGEV_THREAD_ID case.
 
   Right, will fix this.
 
  
  This way any user can crash the kernel with a minimal effort.
 
   Well I tried, no crash, just the signal failing to be delivered.

sigaddset:

set-sig[sig / _NSIG_BPW] |= 1UL  (sig % _NSIG_BPW);

This writes to -sig[event-sigev_signo / _NSIG_BPW] location, so we can
corrupt the memory if -sigev_signo  _NSIG.

Btw, since you are exporting this function, may I suggest to rename it?
No, I can't suggest a better name :) But good_sigevent is a bit confusing
imho.

Oleg.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] namespaces: fix exit race by splitting exit

[Daniel Hokka Zakrisson]

Serge E. Hallyn wrote:
 Ok, could you verify that the following patch at least solves
 the oopsing?

 (I can't reproduce the oops with Daniel's test prog)

 thanks,
 -serge

Indeed, this patch solves the oopsing, but so did the last one. I think I
finally managed to figure out why too, as release_task would be called
with current referring to the parent process, or whoever is reaping the
process with the last reference to the namespace. Right?

Regardless, I have to say I prefer this patch.

-- 
Daniel Hokka Zakrisson
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA ahci Bug in 2.6.19.x

[Alan]

 The only difference is that I don't see the ACPI: PCI Interrupt
 :00:0f.0[B] - GSI
 21 (level, low) - IRQ 19 printk. The driver is AHCI but the device
 is a VIA chip.
 
 I'll get a caputre of the boot log when I find my serial cable. This
 could be related to the VIA PIC quirks that was changed by Alan.

Stuff a printk in and check by all means but _in theory_ the VIA quirk
shouldn't touch IRQ  15 as those are not PIC but APIC routed.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] namespaces: fix exit race by splitting exit

[Oleg Nesterov]

On 01/26, Daniel Hokka Zakrisson wrote:

 Serge E. Hallyn wrote:
  Ok, could you verify that the following patch at least solves
  the oopsing?
 
  (I can't reproduce the oops with Daniel's test prog)
 
  thanks,
  -serge
 
 Indeed, this patch solves the oopsing, but so did the last one. I think I
 finally managed to figure out why too, as release_task would be called
 with current referring to the parent process, or whoever is reaping the
 process with the last reference to the namespace. Right?

Not always. The task can do release_task() on itself if it is sub-thread,
or its parent ignores SIGCHLD.

Anyway I think your explanation is correct for this particular test-case.

Oleg.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Alan]

 Also, many ISA-only drivers actually have hardcoded PIO numbers (eg 
 0x1f0).

Bad example - 0x1F0 is one of those that leaked into the PCI world as
well 8)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Limit the size of the pagecache

[Andrew Morton]

On Wed, 24 Jan 2007 14:15:10 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:

 - One for stability
   When a customer constructs their detabase(Oracle), the system often goes to 
 oom.
   This is because that the system cannot allocate DMA_ZOME memory for 32bit 
 device.
   (USB or e100)
   Not allowing to use almost all pages as page cache (for temporal use) will 
 be some help.
   (Note: construction DB on ext3so all writes are serialized and the 
 system couldn't
free page cache.)

I'm surprised that any reasonable driver has a dependency on ZONE_DMA.  Are
you sure?  Send full oom-killer output, please.


 - One for tuing.
   Sometimes our cutomer requests us to limit size of page-cache.
   
   Many cutomers's memory usage reaches 99.x%. (this is very common situation.)
   If almost all memories are used by page-cache, and we can think we can free 
 it.
   But the customer cannot estimate what amount of page-cache can be freed 
 (without 
   perfromance regression).
   
   When a cutomer wants to add a new application, he tunes the system.
   But memory usage is always 99%.
   page-cache limitation is useful when the customer tunes his system and find
   sets of data and page-cache. 
   (Of course, we can use some other complicated resource management system 
 for this.)
   This will allow the users to decide that they need extra memory or not.
 
   And...some customers want to keep memory Free as much as possible.
   99% memory usage makes insecure them ;)

Tell them to do echo 3  /proc/sys/vm/drop_caches, then wait three minutes?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

fsync occasionally very slow

[Matthew Kirk]

Hi

I am working on an application that fsync(2) files and directories as
needed.I’m seeing intermittent stalls on fsync that can last many
seconds.  The file system is mounted ext3, however I have reproduced the
problem with ext2.  The as scheduler is in use.   I have also tried
deadline.  I have tried 2.6.12.3 (what I’m currently deploying on – yes, I
know it’s old) and 2.6.15 (highest kernel I could easily get to run).  I
have reproduced the problem on both machines with high performance raid
controllers and without.  I haven’t been able to find any reported issues
that describe this problem in a relatively recent kernel (though I did find
some comments about 2.0).

In the original application, data is received from another machine via many
threads.  These threads all write occasionally, usually in chunks of about
1K or 100K (I have also tried using 10M chunks, though some percentage are
still very small).   Half of all files are in the 10-15MB range.  The other
half are very small.  There are also log files that get appended to
regularly. Except for logs, we fsync right before each file is closed.  We
also fsync directories.  Everything is on a single large stripe.  In the
regular application, fsync can happen from any of a number of threads. 

In the application, if one call to fsync blocks, other threads that
subsequently call fsync while the first one is blocked appear to also block.
Once the first thread's fsync releases, the others appear to release too.

I’m not 100% sure it’s fsync vs. some other file system issue.  When I
instrument my code I find that about 90% of the stalls are on fsync, with
the remainder being on other file system operations (e.g. write).  If I
disable fsync in the application I still see stalls, though a little less
frequently.

When running I see what appear to be normal numbers of pdflush jobs (range
2-8, usually 4-5).  When I get application stalls the system is still
otherwise responsive.  I can still start processes, write files, etc.
Typically there are 4-5 pdflushes during stalls too.  CPU utilization (user)
is about 10% and I/O wait is 60-70%.  According to iostat, although blocks
are sometimes getting written during these stalls, they frequently are not.

I have reproduced what I think is the same problem in the stand-alone,
single-threaded source code attached, which opens files, writes to them, and
then only when done writing all files, fsyncs them and closes them in the
order in which they were written. In the standalone application, the first
files that get written take virtually no time to fsync (already flushed),
then once files start to be flushed time will increase, however at least one
file will take a couple seconds to flush, where the others will be in the
range of a few thousandths of a second.

I’m not sure where to go with this now and would appreciate any insights you
have.

Thanks!
Matt Kirk


#include errno.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include sys/time.h
#include fcntl.h
#include string
#include iostream
#include ostream
#include sstream
const unsigned int bigsize = 10248576;
const unsigned int smallsize = 10248576;

char *buff;
int main (int argc, const char *argv[]) { 
   int q;
   int innerloop = 100;
   int outerloop = 1000;
   int dofsync = 1;
   if (argc  1) { 
  dofsync=(atoi(argv[1]));
   }
   if (argc  2) { 
  innerloop=(atoi(argv[2]));
   }
   if (argc == 4) {
  outerloop=(atoi(argv[3]));
   }
   buff = new char[bigsize];
   memset(buff, 1, bigsize);
   int fd[innerloop];
   for (int r = 0; r  outerloop; r++) { 
  struct timeval starttimer,endtimer;
  gettimeofday(starttimer, NULL);
  int count;
  for (int q = 0; q  innerloop; q++) {
 std::stringstream s; 
 s  file_  q+(r*outerloop);
 fd[q] = open(s.str().c_str(), O_RDWR+O_CREAT+O_APPEND);
 if (fd[q] == -1) { std::cout  Failed to open   s.str()  
due to   errno  std::endl; return(0); }
 if (q % 4 != 1) { 
count = write(fd[q],(void*) buff, bigsize);
if (count != bigsize) { std::cout  write returned   count
  with errno   errno  std::endl; return (0); }
 } else { 
count = write(fd[q],(void*) buff, smallsize);
if (count != smallsize) { 
   std::cout  write returned   count   with errno  
errno  std::endl; 
   return (0);
} 
 }
  }

  for (int q = 0; q  innerloop; q++) {
 struct timeval mytimer, mytimer2;
 gettimeofday(mytimer, NULL);
 if (dofsync) { 
count = fsync(fd[q]);
 } else { 
count = fdatasync(fd[q]);
 }
 gettimeofday(mytimer2, NULL);
 if (mytimer.tv_usec  mytimer2.tv_usec) {
mytimer2.tv_sec -= (mytimer.tv_sec+1);
mytimer2.tv_usec += (100-mytimer.tv_usec);
 } else { 
mytimer2.tv_sec -= mytimer.tv_sec;
mytimer2.tv_usec -= 

Re: + make-good_sigevent-non-static.patch added to -mm tree

[Sébastien Dugué]

On Fri, 26 Jan 2007 13:08:01 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:

 On 01/26, S?bastien Dugu? wrote:
 
  On Thu, 25 Jan 2007 18:43:24 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:
  
   SИbastien DuguИ wrote:
   
+struct task_struct *good_sigevent(sigevent_t *event)
+{
+   struct task_struct *task = current-group_leader;
+
+   if ((event-sigev_notify  SIGEV_THREAD_ID) == SIGEV_THREAD_ID) 
{
+   task = find_task_by_pid(event-sigev_notify_thread_id);
+
+   if (!task || task-tgid != current-tgid)
+   return NULL;
+   } else if (event-sigev_notify == SIGEV_SIGNAL) {
   
   No, no, we can't use else here,
   
+   if (event-sigev_signo = 0 || event-sigev_signo  
SIGRTMAX)
   
   because we skip the check above in SIGEV_THREAD_ID case.
  
Right, will fix this.
  
   
   This way any user can crash the kernel with a minimal effort.
  
Well I tried, no crash, just the signal failing to be delivered.
 
   sigaddset:
 
   set-sig[sig / _NSIG_BPW] |= 1UL  (sig % _NSIG_BPW);
 
 This writes to -sig[event-sigev_signo / _NSIG_BPW] location, so we can
 corrupt the memory if -sigev_signo  _NSIG.

  Gawd, right.

 
 Btw, since you are exporting this function, may I suggest to rename it?
 No, I can't suggest a better name :) But good_sigevent is a bit confusing
 imho.

  I agree, there was a discussion concerning this a while back but nothing came
out of it and I left it as is.

  I will try to find something more suggestive.

  Thanks,

  Sébastien.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: unfixed regression in 2.6.20-rc6 (since 2.6.19)

[Rainer Weikusat]

Greg KH [EMAIL PROTECTED] writes:
 On Thu, Jan 25, 2007 at 04:20:55PM +0100, Rainer Weikusat wrote:
 2.6.19 introduced changes to the UHCI handling of interrupt URBs that
 caused at least some keyspan USB-to-serial converters to fail,

[...]

 I copied you when this patch was added to my tree,

The only thing I received was a 'this patch has been dropped from
the MM-tree because something happened' message.

 as I had reworked it to be a bit more acceptable (no pointer
 arithmatic, proper coding style, use the newer macros for endpoint
 detection, etc.),

You have basically done a couple of (functionally) totally pointless
changes, like

- not using iterator-style array traversals, but indexed ones
  instead

- doing the calculation to determine the endpoint type in
  three different places instead of in one place, because the
  somewhat silly endpoint classification interfaces enforces
  this

- not using a single switch-statement but an if-else-cascade,
  again due to limitations of that interface

- replacing the while-loop with an identical for-loop

The net effect of these changes is that an optimizing compiler will
have to work somewhat more to remove all the redundant stuff that
was added. As for 'proper coding style', the code conforms to what is
documented as 'proper kernel coding style'. If this assumption of mine
is incorrect, I'd be happy to hear about reasons why this would be so,
to take them into account for eventual future patches.

 I this patch does not work, please let me know, and I will be glad
 to work to fix it.

I think I'll just resend the working one in this case. But the logic
appears to be identical, so I do not so a reason why it shouldn't.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] init: support preset lpj value as config option

[Andrew Morton]

On Thu, 25 Jan 2007 10:24:59 -0800
Tim Bird [EMAIL PROTECTED] wrote:

 Paul Mundt wrote:
  On Wed, Jan 24, 2007 at 04:12:18PM -0800, Tim Bird wrote:
  This patch provides a config option for preset lpj, which means
  the value can be easily preserved, and conveyed between developers
  in a config file.
 
  This seems excessive, it's already possible to set the preset lpj on the
  kernel command line, and virtually every one of the embedded
  architectures supports setting the kernel command line as a config
  option. Is there any reason why you can't simply set it there as a
  default instead? It's all going to be .config resident in the end
  anyways.
 
 i386 is missing CONFIG_CMDLINE support, and this architecture
 is used in embedded.

So if we add CONFIG_CMDLINE we fix this problem and we bring i386 into line
with other platforms.  It's all good.

  I think many other x86 derivatives are
 also missing .config-based command line support.  CELF has
 worked to get patches submitted to fix this, but so far these
 haven't been accepted.

You have?

looks at inbox

To whom?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6

[Hans-Peter Nilsson]

 From: David Brownell [EMAIL PROTECTED]
 Date: Thu, 25 Jan 2007 05:02:56 -0800

 On Wednesday 24 January 2007 8:52 pm, Hans-Peter Nilsson wrote:
  (Please CC me on replies, I'm not subscribed to LKML or the SPI list.  
  Thanks.)
  
  The SD/MMC SPI-based protocol isn't really duplex.  In the
  normal case there's either information transmitted or received,
  not both simultaneously.  The unused data is always 0xff; ones.
  Unfortunately, the SPI framework leaves outgoing data for a
  left-out tx_buf just as undefined
 
 In current kernels that's actually changed.  The value to be shifted
 out is now specified ... as all-zeroes, which is what various chips
 need to receive, and various (half-duplex/Microwire) controllers seem
 to be doing in any case.
 
 If that's an issue -- and MMC-over-SPI needs to specify some other
 value --

Well, it *is* specified as ones (0xff).  Curiously enough, I
can't point to a statement in the Simplified Physical Layer
Specification 2.0.  It's likely specified in the 7.5 SPI Bus
Timing Diagrams, which is blank for the Simplified
Specification.  If you look at SanDisk's OEM documents for
MultiMediaCard/ Reduced-Size MultiMediaCard v1.3, you can
see that *that* document nicely complements the Simplified
Specification, and specifies it as 0xff (see 5.23 SPI Bus
Timing Diagrams).  FWIW, I found this referenced from somewhere
I-forgot when I STFW'd for SD/MMC SPI documentation or Linux
drivers, so I'm not ratting them out for providing
documentation withheld elsewhere. :-} Besides, I think they're
one of those making the rules for the SDcard organization.

...and anyway, I just *had* to try: well, it doesn't work with 0. :-)

 I think a better way to package this would be to define a new
 flag for spi-mode, since controller drivers are already supposed
 to be checking that to make sure they handle all the options which
 have been specified.

But it's unspecified what the controller drivers should do with
flags don't recognize (should they refuse? warn? ignore? - I see
they all ignore) so with that suggestion, we'll have a situation
where drivers wouldn't know about the new flag and would
silently not work.

Perhaps it can be legislated or at least strongly suggested
that SPI drivers must return -EINVAL for flags in spi-mode that
they don't recognise?  Typically, for 2.6.19 flags, in their
master-setup method:

  if (spi-mode  ~(SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST))
return -EINVAL;

(I think I'll do exactly that with the drivers I wrote.)

  That flag could work in conjunction with
 a byte

Or why not a 32-bit word!  If controllers can only handle non-0
values for bits_per_word = 8, they can check for that.  (Before
you suggest a 64-bit value, consider that the 64-bit-ness would
supposedly be rarely used and the value is likely to be looked
up in inner loops like for the bitbanged driver.  Ok, there are
ways around that, it's just that I don't think a 64-bit value
would be more useful than the implications.  We can always
change it when a use-case appears.  I guess that implies having
it a u8, but typically the 32 vs 8 bit difference is much less
than 64 vs 32.  Toolshed alert!)

 provided in the spi_device, that would be used instead of
 zero.  (Some folk have noted that when debugging, it's easier if
 the pattern there is neither all-ones nor all-zeroes ... something
 that a digital scope will show is easier to work with.)

FWIW, I defined it as a single bit in that patch, because that's
what my HW can do when the transmitter is disabled - and because
MOSI *is* a single-valued signal. ;-)  Also, I made it
per-transfer, which for mmc_spi wouldn't mean much, only perhaps
to possibly drop all-zero buffers, which of course implied that
someone would have to scan them first anyway (i.e. no fewer
memory accesses), so I guess I had no serious use-case.

Still, making it a u32 (or u8), with spi-bits_per_word
specifying the actual length, makes sense for example to
implementations around a shift-register but with no DMA.  A
controller can return -EINVAL (shouldn't that be -ENOSYS?) if it
finds a default_tx_word it can't support simply enough.  If we
define returning -EINVAL as always ok and that the driver/client
part is responsible for a fallback, I think we have agreement.

While I was looking, I noticed that the memory-layout of
non-8-bit words for SPI is a bit unclear.  The endianness of
data shifted out doesn't really define endianness in memory or
whether 24-bit words bytes are in order {hi, med, low, pad} or
indeed {pad, low, med, hi or whatever combination.  For a LE
architecture, storing data as LE in memory makes sense, and both
with and without padding makes sense too.  Perhaps best to just
document that it's undefined?

 then please re-issue this patch against 2.6.20, including
 the update to the bitbang driver (reference implementation).

I used patch-2.6.20-rc6; I see not too many SPI things changed
besides defining the previously undefined as 0.  I 

[PATCH 2/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6

[Hans-Peter Nilsson]

Just some trivial patches to make sure the existing drivers in
the official tree don't *silently* fail with the introduction of
default_tx_word.  Never tested in any way.  Not sure if this is
all, for example I didn't look in arch/*.

Signed-off-by: Hans-Peter Nilsson [EMAIL PROTECTED]

diff -upr a/drivers/spi/pxa2xx_spi.c b/drivers/spi/pxa2xx_spi.c
--- a/drivers/spi/pxa2xx_spi.c  2007-01-26 10:38:49.0 +0100
+++ b/drivers/spi/pxa2xx_spi.c  2007-01-26 11:17:49.0 +0100
@@ -1077,6 +1077,9 @@ static int setup(struct spi_device *spi)
if (!spi-bits_per_word)
spi-bits_per_word = 8;
 
+   if (spi-default_tx_word != 0)
+   return -EINVAL;
+
if (drv_data-ssp_type != PXA25x_SSP
 (spi-bits_per_word  4 || spi-bits_per_word  32)) {
dev_err(spi-dev, failed setup: ssp_type=%d, bits/wrd=%d 
diff -upr a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
--- a/drivers/spi/spi_mpc83xx.c 2007-01-26 10:38:49.0 +0100
+++ b/drivers/spi/spi_mpc83xx.c 2007-01-26 11:19:01.553401939 +0100
@@ -238,6 +238,9 @@ static int mpc83xx_spi_setup(struct spi_
struct mpc83xx_spi *mpc83xx_spi;
int retval;
 
+   if (spi-default_tx_word != 0)
+   return -EINVAL;
+
if (!spi-max_speed_hz)
return -EINVAL;
 
diff -upr a/drivers/spi/spi_s3c24xx.c b/drivers/spi/spi_s3c24xx.c
--- a/drivers/spi/spi_s3c24xx.c 2007-01-26 10:38:49.0 +0100
+++ b/drivers/spi/spi_s3c24xx.c 2007-01-26 11:19:19.014017640 +0100
@@ -153,6 +153,9 @@ static int s3c24xx_spi_setup(struct spi_
 {
int ret;
 
+   if (spi-default_tx_word != 0)
+   return -EINVAL;
+
if (!spi-bits_per_word)
spi-bits_per_word = 8;
 

brgds, H-P
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Limit the size of the pagecache

[Andrew Morton]

On Wed, 24 Jan 2007 15:03:23 +1100
Nick Piggin [EMAIL PROTECTED] wrote:

 
 Yeah, it will be failing at order=4, because the allocator won't try
 very hard reclaim pagecache pages at that cutoff point. This needs to
 be fixed in the allocator.

A simple and perhaps sufficient fix for this nommu problem would be to replace
the magic 3 in __alloc_pages() with a tunable.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel 2.6.19.2 New RAID 5 Bug (oops when writing Samba - RAID5)

[Andrew Morton]

On Wed, 24 Jan 2007 18:37:15 -0500 (EST)
Justin Piszcz [EMAIL PROTECTED] wrote:

  Without digging too deeply, I'd say you've hit the same bug Sami Farin and
  others
  have reported starting with 2.6.19: pages mapped with kmap_atomic() become
  unmapped
  during memcpy() or similar operations.  Try disabling preempt -- that seems 
  to
  be the
  common factor.
  
  
  -
  To unsubscribe from this list: send the line unsubscribe linux-raid in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
  
 
 After I run some other tests, I am going to re-run this test and see if it 
 OOPSes again with PREEMPT off.

Strange.  The below debug patch might catch it - please run with this
applied.  


--- a/arch/i386/mm/highmem.c~kmap_atomic-debugging
+++ a/arch/i386/mm/highmem.c
@@ -30,7 +30,43 @@ void *kmap_atomic(struct page *page, enu
 {
enum fixed_addresses idx;
unsigned long vaddr;
+   static unsigned warn_count = 10;
 
+   if (unlikely(warn_count == 0))
+   goto skip;
+
+   if (unlikely(in_interrupt())) {
+   if (in_irq()) {
+   if (type != KM_IRQ0  type != KM_IRQ1 
+   type != KM_BIO_SRC_IRQ  type != KM_BIO_DST_IRQ 
+   type != KM_BOUNCE_READ) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   } else if (!irqs_disabled()) {  /* softirq */
+   if (type != KM_IRQ0  type != KM_IRQ1 
+   type != KM_SOFTIRQ0  type != KM_SOFTIRQ1 
+   type != KM_SKB_SUNRPC_DATA 
+   type != KM_SKB_DATA_SOFTIRQ 
+   type != KM_BOUNCE_READ) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   }
+   }
+
+   if (type == KM_IRQ0 || type == KM_IRQ1 || type == KM_BOUNCE_READ) {
+   if (!irqs_disabled()) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   } else if (type == KM_SOFTIRQ0 || type == KM_SOFTIRQ1) {
+   if (irq_count() == 0  !irqs_disabled()) {
+   WARN_ON(1);
+   warn_count--;
+   }
+   }
+skip:
/* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
pagefault_disable();
if (!PageHighMem(page))
_

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel 2.6.19.2 New RAID 5 Bug (oops when writing Samba - RAID5)

[Justin Piszcz]

On Fri, 26 Jan 2007, Andrew Morton wrote:

 On Wed, 24 Jan 2007 18:37:15 -0500 (EST)
 Justin Piszcz [EMAIL PROTECTED] wrote:
 
   Without digging too deeply, I'd say you've hit the same bug Sami Farin and
   others
   have reported starting with 2.6.19: pages mapped with kmap_atomic() become
   unmapped
   during memcpy() or similar operations.  Try disabling preempt -- that 
   seems to
   be the
   common factor.
   
   
   -
   To unsubscribe from this list: send the line unsubscribe linux-raid in
   the body of a message to [EMAIL PROTECTED]
   More majordomo info at  http://vger.kernel.org/majordomo-info.html
   
   
  
  After I run some other tests, I am going to re-run this test and see if it 
  OOPSes again with PREEMPT off.
 
 Strange.  The below debug patch might catch it - please run with this
 applied.  
 
 
 --- a/arch/i386/mm/highmem.c~kmap_atomic-debugging
 +++ a/arch/i386/mm/highmem.c
 @@ -30,7 +30,43 @@ void *kmap_atomic(struct page *page, enu
  {
   enum fixed_addresses idx;
   unsigned long vaddr;
 + static unsigned warn_count = 10;
  
 + if (unlikely(warn_count == 0))
 + goto skip;
 +
 + if (unlikely(in_interrupt())) {
 + if (in_irq()) {
 + if (type != KM_IRQ0  type != KM_IRQ1 
 + type != KM_BIO_SRC_IRQ  type != KM_BIO_DST_IRQ 
 + type != KM_BOUNCE_READ) {
 + WARN_ON(1);
 + warn_count--;
 + }
 + } else if (!irqs_disabled()) {  /* softirq */
 + if (type != KM_IRQ0  type != KM_IRQ1 
 + type != KM_SOFTIRQ0  type != KM_SOFTIRQ1 
 + type != KM_SKB_SUNRPC_DATA 
 + type != KM_SKB_DATA_SOFTIRQ 
 + type != KM_BOUNCE_READ) {
 + WARN_ON(1);
 + warn_count--;
 + }
 + }
 + }
 +
 + if (type == KM_IRQ0 || type == KM_IRQ1 || type == KM_BOUNCE_READ) {
 + if (!irqs_disabled()) {
 + WARN_ON(1);
 + warn_count--;
 + }
 + } else if (type == KM_SOFTIRQ0 || type == KM_SOFTIRQ1) {
 + if (irq_count() == 0  !irqs_disabled()) {
 + WARN_ON(1);
 + warn_count--;
 + }
 + }
 +skip:
   /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
   pagefault_disable();
   if (!PageHighMem(page))
 _
 
 

The RAID5 bug may be hard to trigger, I have only made it happen once so 
far (but only tried it once, don't like locking up the raid :)), I will 
re-run the test after applying this patch.

Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] incorrect direct io error handling (v3)

[Dmitriy Monakhov]

Andrew Morton [EMAIL PROTECTED] writes:

 On Wed, 24 Jan 2007 22:05:06 +0300
 Dmitriy Monakhov [EMAIL PROTECTED] wrote:

 incorrect direct io error handling (v3)
 Changes from v2:
  - Remove BUG_ON(!mutex_is_locked(..)) for non blkdev.
  - vmtruncate() called from generic_file_aio_write().
  - depends on patch titled:
[PATH][RFC] mm: Move common segments checks to separate function

 drat, I skipped that patch due to rejects, and because Nick is working on
 things in the same area.

[skip]
  if ((written = 0 || written == -EIOCBQUEUED) 
  ((file-f_flags  O_SYNC) || IS_SYNC(inode))) {
 @@ -2365,6 +2366,17 @@ ssize_t generic_file_aio_write(struct ki
  iocb-ki_pos);
  mutex_unlock(inode-i_mutex);
  
 +if (unlikely(ret  0  (file-f_flags  O_DIRECT))) {
 +ssize_t cnt = generic_segment_checks(nr_segs, iov, VERIFY_READ);
 +loff_t isize = i_size_read(inode);
 +/*
 + * generic_file_direct_write() may have instantiated a few 
 + * blocks outside i_size.  Trim these off again.
 + */
 +if (cnt  0  (pos + cnt  isize))
 +vmtruncate(inode, isize);
 +}
 +

 vmtruncate() really wants i_mutex to be held.  Can't we do that here?
Yepp 110% true, baaahh . it looks like my brain was't clear at the time i
wrote this. We have to do vmtruncate() brfore droping i_mutex , right after
__generic_file_aio_write_nolock() call , i'm sorry to waste your time. 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks

[xiphmont]

On 1/25/07, Greg KH [EMAIL PROTECTED] wrote:

I want to do just a little more testing here (Takashi reminded me I
have a bit more testing of my own to do).


Can you give me the 'tree /sys/class/sound' output?

Once I verify it's 'all good' (actually, I'm stalling; not in front of
the machine with the patches right now.


Does it work properly with old versions of hald now?


Yes.  I still need to make doubly sure I didn't break the new sysfs tree though.


Is there anything else left to fix?


Once that testing is done, no.  But don't trust the two patches I sent
yet, I'll resumbit the patch resulting from more thorough testing in a
few hours (much thanks to Takashi for giving me the parent device
feedback I was trolling for).

Monty
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Juju

[Stefan Richter]

Pete Zaitcev wrote:
 On Fri, 26 Jan 2007 03:35:19 +0100, Stefan Richter [EMAIL PROTECTED] wrote:
 The target wrote an SBP-2 status block into our memory. The status block
 contains the FireWire bus address of the ORB to which it belongs. [...]
 
 I see. SRP has a more flexible tag which can be used to look up
 the just completed command more effectively. But if we only submit
 one, it's a moot point of course.

And indeed, in the SBP-2 realm the ORB's address is actually the tag of
the SCSI task.

 [...] Since there aren't many
 mapped ORBs per target, a linked list is a reasonable data structure to
 search over.
 
 Righto. I'm used to having thousands of oustanding commands in arrays.

If I ever get to fix sbp2's handling of dynamically appended ORB lists,
the next step would be to measure which queue depth is optimal for
different hardware and different workloads. (Certainly much less than
thousands for typical SBP-2 target(s)+initiator(s) setups.)
-- 
Stefan Richter
-=-=-=== ---= ==-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bugfixes: PCI devices get assigned redundant IRQs

[Andreas Block]

Hi,

I'm currently working on a port to a CPCI board with a MPC5200.
When testing the PCI interrupt routing, I discovered the following:
Even devices which don't use interrupts (- PCI Spec.: Interrupt Pin  
Register is zero),
get an interrupt assigned (this is at least true for most of the  
PPC-targets I looked at).

The cause is pretty obvious in drivers/pci/setup-irq.c.
I guess at least in an ideal world with correctly designed hardware, the  
code should

rather look as in the patch below.
Of course it doesn't hurt anybody to have an unuseable IRQ assigned to a
PCI-to-PCI-bridge (or something alike), but to me it seems a bit strange.
Please correct me, if I'm mislead.

The patch below is tested on the above mentioned CPCI-MPC5200 board and is  
compiler

tested with the latest git-repository kernel on x86.

Best regards,
Andreas

---

Don't assign IRQs to devices, which don't need any

---
commit 2133d61f0bc119d4a06d453b8e79980912a151f0
tree 59ff1b5f7c1ec41780907edd90a35c10a64e3996
parent 99abfeafb5f2eea1bb481330ff37343e1133c924
author Andreas Block [EMAIL PROTECTED] Thu, 25 Jan 2007  
17:12:48 +0100
committer Andreas Block [EMAIL PROTECTED] Thu, 25 Jan  
2007 17:12:48 +0100


 drivers/pci/setup-irq.c |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
index a251289..568f187 100644
--- a/drivers/pci/setup-irq.c
+++ b/drivers/pci/setup-irq.c
@@ -24,7 +24,7 @@ pdev_fixup_irq(struct pci_dev *dev,
   int (*map_irq)(struct pci_dev *, u8, u8))
 {
u8 pin, slot;
-   int irq;
+   int irq = 0;

/* If this device is not on the primary bus, we need to figure out
   which interrupt pin it will come in on.   We know which slot it
@@ -33,16 +33,18 @@ pdev_fixup_irq(struct pci_dev *dev,
   apply the swizzle function.  */

pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
-   /* Cope with 0 and illegal. */
-   if (pin == 0 || pin  4)
+   /* Cope with illegal. */
+   if (pin  4)
pin = 1;

-   /* Follow the chain of bridges, swizzling as we go.  */
-   slot = (*swizzle)(dev, pin);
+   if (pin != 0) {
+   /* Follow the chain of bridges, swizzling as we go.  */
+   slot = (*swizzle)(dev, pin);

-   irq = (*map_irq)(dev, slot, pin);
-   if (irq == -1)
-   irq = 0;
+   irq = (*map_irq)(dev, slot, pin);
+   if (irq == -1)
+   irq = 0;
+   }
dev-irq = irq;

pr_debug(PCI: fixup irq: (%s) got %d\n,

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] lumpy reclaim v2

[Andrew Morton]

On Thu, 14 Dec 2006 20:57:34 -0800
Andrew Morton [EMAIL PROTECTED] wrote:

 On Wed, 6 Dec 2006 16:59:35 +
 Andy Whitcroft [EMAIL PROTECTED] wrote:
 
  +   tmp = __pfn_to_page(pfn);
 
 ia64 doesn't implement __page_to_pfn.  Why did you not use page_to_pfn()?

Poke.  I'm still a no-compile on ia64.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bugfixes: PCI devices get assigned redundant IRQs

[Xavier Bestel]

On Fri, 2007-01-26 at 11:50 +0100, Andreas Block wrote:

   u8 pin, slot;
 - int irq;
 + int irq = 0;

Aren't there platforms for which irq = 0 is a valid irq ?

Xav


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages

[Andrew Morton]

On Thu, 25 Jan 2007 23:44:58 + (GMT)
Mel Gorman [EMAIL PROTECTED] wrote:

 The following 8 patches against 2.6.20-rc4-mm1 create a zone called
 ZONE_MOVABLE

Argh.  These surely get all tangled up with the
make-zones-optional-by-adding-zillions-of-ifdef patches:

deal-with-cases-of-zone_dma-meaning-the-first-zone.patch
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set-reduce-config_zone_dma-ifdefs.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
set-config_zone_dma-for-arches-with-generic_isa_dma.patch
zoneid-fix-up-calculations-for-zoneid_pgshift.patch

My objections to those patches:

- They add zillions of ifdefs

- They make the VM's behaviour diverge between different platforms and
  between differen configs on the same platforms, and hence degrade
  maintainability and increase complexity.

- We kicked around some quite different ways of implementing the same
  things, but nothing came of it.  iirc, one was to remove the hard-coded
  zones altogether and rework all the MM to operate in terms of

for (idx = 0; idx  NUMBER_OF_ZONES; idx++)
...

- I haven't seen any hard numbers to justify the change.

So I want to drop them all.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Track mlock()ed pages

[Andrew Morton]

On Thu, 25 Jan 2007 22:36:17 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:

 On Fri, 26 Jan 2007, Nick Piggin wrote:
 
  Christoph Lameter wrote:
   Add NR_MLOCK
   
   Track mlocked pages via a ZVC

Why?

  I think it is not quite right. You are tracking the number of ptes
  that point to mlocked pages, which can be = the actual number of pages.
 
 Mlocked pages are not inherited. I would expect sharing to be very rare.
  
  Also, page_add_anon_rmap still needs to be balanced with page_remove_rmap.
 
 Hmmm 
  
  I can't think of an easy way to do this without per-page state. ie.
  another page flag.
 
 Thats what I am trying to avoid.

You could perhaps go for a walk across all the other vmas which presently
map this page.  If any of them have VM_LOCKED, don't increment the counter.
Similar on removal: only decrement the counter when the final mlocked VMA
is dropping the pte.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + aio-completion-signal-notification.patch added to -mm tree

[Sébastien Dugué]

On Thu, 25 Jan 2007 19:21:41 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:

 Sebastien Dugue wrote:
 
  +static long aio_setup_sigevent(struct aio_notify *notify,
  +  struct sigevent __user *user_event)
  +{
  +   sigevent_t event;
  +   struct task_struct *target;
  +
  +   if (copy_from_user(event, user_event, sizeof(event)))
  +   return -EFAULT;
  +
  +   if (event.sigev_notify == SIGEV_NONE)
  +   return 0;
  +
  +   notify-notify = event.sigev_notify;
  +   notify-signo = event.sigev_signo;
  +   notify-value = event.sigev_value;
  +
  +   read_lock(tasklist_lock);
 
 We don't need tasklist_lock, we can use rcu_read_lock() instead.

  Right that will be beneficial, will change.

 
  +   target = good_sigevent(event);
  +
  +   if (unlikely(!target || (target-flags  PF_EXITING)))
  +   goto out_unlock;
 
 PF_EXITING check is racy and unneded. In fact, it is wrong. If the main
 thread is already died, we can only use SIGEV_THREAD_ID signals, because
 otherwise good_sigevent() returns -group_leader.

  Care to explain here please, I'm not following you.

 
  @@ -994,6 +1077,15 @@ int fastcall aio_complete(struct kiocb *
  kunmap_atomic(ring, KM_IRQ1);
 
  pr_debug(added to ring %p at [%lu]\n, iocb, tail);
  +
  +   if (iocb-ki_notify.notify != SIGEV_NONE) {
  +   ret = aio_send_signal(iocb-ki_notify);
  +
  +   /* If signal generation failed, release the sigqueue */
  +   if (ret)
  +   sigqueue_free(iocb-ki_notify.sigq);
 
 We should not use sigqueue_free() here. It takes current-sighand-siglock
 to remove sigqueue from struct sigpending. But current is just a random
 process here.
 
 Yes, if I understand this patch correctly, it is not possible that this
 sigqueue is pending, but still this is bad imho.

 Yes, in fact the sigqueue is used for a single signal delivery and then
free. In fact I could have used directly __sigqueue_free() instead here
except for the fact that it's private to signal.c and I'm reluctant
to export it to other subsystems.

 
   static void __sigqueue_free(struct sigqueue *q)
   {
  -   if (q-flags  SIGQUEUE_PREALLOC)
  +   if (q-flags  SIGQUEUE_PREALLOC  q-info.si_code != SI_ASYNCIO)
  return;
 
 Oh, this is not nice. Could we change send_sigqueue/send_group_sigqueue
 instead ?

  Yep, that's the other solution.

 
 - BUG_ON(!(q-flags  SIGQUEUE_PREALLOC));
 + BUG_ON(!(q-flags  SIGQUEUE_PREALLOC)  q-info.si_code != 
 SI_ASYNCIO);
 
 This way aio can use __sigqueue_alloc/__sigqueue_free directly and forget
 about SIGQUEUE_PREALLOC.

  Well, I don't think it's cleaner. The aio error path calls sigqueue_free()
directly whereas in case of success sigqueue_free() is called from the signal
delivery path.

 
 On the other hand, imho this patch takes a wrong direction.
 
 The purpose of SIGQUEUE_PREALLOC + send_sigqueue() is to re-use the same
 sigqueue while sending a stream of signals. But in aio case we allocate
 sigqueue to send only 1 signal, then it freed after the delivery like
 the regular sigqueue. So what is the point?
 
 I'd suggest to not use this interface. Just use group_send_sig_info() or
 specific_send_sig_info(). Yes, this way we will do GFP_ATOMIC allocation
 of sigqueue in interrupt context, but is this so bad in this case?

  Well, the thihere is that in the past we used group_send_sig_info()
and specific_send_sig_info() for notification but Zach Brown raised
the question about reliable signal delivery. IOW an aio submission
should not succeed if signal delivery is going to fail. Hence the
use of the preallocated sigqueue.

  Thanks,

  Sébastien.





-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fsync occasionally very slow

[Andrew Morton]

On Fri, 26 Jan 2007 05:37:38 -0500
Matthew Kirk [EMAIL PROTECTED] wrote:

 I am working on an application that fsync(2) files and directories as
 needed.I’m seeing intermittent stalls on fsync that can last many
 seconds.

Please generate an all-task backtrace during the stall via:

dmesg -n 8
wait for a stall
echo t  /prov/sysrq-trigger
dmesg -s 100  foo

and send foo.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Juju

[Stefan Richter]

Kristian Høgsberg wrote:
 Another thing that probably makes my explanation a little confusing is that 
 there are two types of transactions: FireWire transactions which consists of 
 a 
   request followed by a response and are pretty much the smallest interaction 
 you can have with a remote device.  Then there are SBP-2 transactions, which 
 are a higer level sequence layered on top of FireWire transactions.
[...]

Exactly. One SBP-2 transaction is one SCSI task's request and completion
and contains
  1. one 1394 write transaction, requested by initiator node,
  2. one 1394 read transaction, requested by the target node,
  3. zero to many 1394 read or write transactions, requested by the
 target node,
  4. one 1394 write transaction, requested by the target node
(if everything goes well and if we don't have dynamically appended ORB
lists). So it might be less confusing if we only speak of 1394
transactions and SCSI tasks.

BTW, SBP-3 allows to wrap step 2 into step 1. I read that some SBP-2
targets support this SBP-3 feature.

[...]
 The target wrote an SBP-2 status block into our memory. The status block
 contains the FireWire bus address of the ORB to which it belongs. Juju's
 fw-sbp2 does the same as mainline's sbp2: Looking through the pile of
 unfinished ORBs for one with the same FireWire bus address, which was
 previously derived from the DMA mapped address.
 
 But the status write actually does carry the address of the ORB it signals 
 the 
 completion of.  So in theory, we could just read out the ORB address from the 
 status write packet and map that back to kernel virtual memory

Map back to virtual memory is exactly what we do already, although in
a rather dumb fashion. It would be easier if there was a portable
bus_to_virt() which would do the job for us. This is much more of an
issue if we want to work without OHCI-1394 physical DMA: Then we have to
do this inverse DMA mapping also for arbitrary pieces of all scatter
gather elements of the SCSI data buffer.

[...]
 One thing I want to do (though very low priority) is to allocate the ORBs out 
 of a preallocated circular buffer.

Incidentally, one thing I want to do (though at low priority) is to use
a circular ORB buffer... Well, linux1394 has a number of more serious
issues pending at bugzilla.kernel.org, and meanwhile people are eager to
run things like FreeBob or Kino on Juju --- thus it remains to be seen
who of us gets to it first. :-)
-- 
Stefan Richter
-=-=-=== ---= ==-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ipw2200 problem with 2.6.20-rc6

[Ismail Dönmez]

Hi,

I recently saw this in dmesg after the wireless network suddenly stopped 
working and after some time it worked again:

ipw2200/0: page allocation failure. order:0, mode:0x20
 [c0140996] __alloc_pages+0x27b/0x28c
 [c015397a] cache_alloc_refill+0x292/0x46f
 [c0153b9c] __kmalloc+0x45/0x51
 [c02d47c5] __alloc_skb+0x47/0x102
 [e05c5153] ipw_rx_queue_replenish+0x52/0xf0 [ipw2200]
 [c032c69b] __sched_text_start+0x4c3/0x560
 [e05c520f] ipw_bg_rx_queue_replenish+0x1e/0x27 [ipw2200]
 [c01226b0] run_workqueue+0x8f/0x14b
 [e05c51f1] ipw_bg_rx_queue_replenish+0x0/0x27 [ipw2200]
 [c0122c6d] worker_thread+0x108/0x132
 [c0111efa] default_wake_function+0x0/0xc
 [c0122b65] worker_thread+0x0/0x132
 [c0125198] kthread+0xa0/0xc8
 [c01250f8] kthread+0x0/0xc8
 [c0103003] kernel_thread_helper+0x7/0x10
 ===
Mem-info:
DMA per-cpu:
CPU0: Hot: hi:0, btch:   1 usd:   0   Cold: hi:0, btch:   1 usd:   
0
Normal per-cpu:
CPU0: Hot: hi:  186, btch:  31 usd:  30   Cold: hi:   62, btch:  15 usd:  
56
Active:96632 inactive:5235 dirty:3532 writeback:4 unstable:0 free:730 
slab:7772 mapped:23842 pagetables:958
DMA free:1968kB min:88kB low:108kB high:132kB active:10068kB inactive:0kB 
present:16256kB pages_scanned:247 all_unreclaimable? no
lowmem_reserve[]: 0 483 483
Normal free:952kB min:2764kB low:3452kB high:4144kB active:376460kB 
inactive:20940kB present:494668kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 0*4kB 0*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 
0*2048kB 0*4096kB = 1968kB
Normal: 0*4kB 1*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 
0*2048kB 0*4096kB = 952kB
Swap cache: add 57, delete 57, find 0/0, race 0+0
Free swap  = 614164kB
Total swap = 614392kB
Free swap:   614164kB
128736 pages of RAM
0 pages of HIGHMEM
2010 reserved pages
127625 pages shared
0 pages swap cached
3532 pages dirty
4 pages writeback
23842 pages mapped
7772 pages slab
958 pages pagetables
eth2: Can not allocate SKB buffers.

Regards,
ismail
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/09] atomic.h : standardizing atomic primitives

[Peter Zijlstra]

On Thu, 2007-01-25 at 11:15 -0500, Mathieu Desnoyers wrote:
 atomic.h : standardizing atomic primitives
 
 It mainly adds support for missing 64 bits cmpxchg and 64 bits atomic add
 unless. Therefore, principally 64 bits architectures are targeted by these
 patches. It also adds the complete list of atomic operations on the 
 atomic_long
 type.
 
 These patches apply on 2.6.20-rc5-git4.

ARCH=um SUBARCH=i386

In file included from include2/asm/arch/atomic.h:257,
 from include2/asm/atomic.h:10,
 from /usr/src/linux-2.6-git/include/linux/file.h:9,
 from /usr/src/linux-2.6-git/mm/fadvise.c:12:
/usr/src/linux-2.6-git/include/asm-generic/atomic.h: In function 
‘atomic_long_add_unless’:
/usr/src/linux-2.6-git/include/asm-generic/atomic.h:260: warning: implicit 
declaration of function ‘cmpxchg’
/usr/src/linux-2.6-git/include/asm-generic/atomic.h: In function 
‘atomic_long_xchg’:
/usr/src/linux-2.6-git/include/asm-generic/atomic.h:281: warning: implicit 
declaration of function ‘xchg’


Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
diff --git a/include/asm-um/atomic.h b/include/asm-um/atomic.h
index b683f10..b2766b0 100644
--- a/include/asm-um/atomic.h
+++ b/include/asm-um/atomic.h
@@ -6,6 +6,7 @@ #define __UM_ATOMIC_H
  */
 #include linux/kernel.h
 
+#include asm/arch/system.h
 #include asm/arch/atomic.h
 
 #endif


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks

[Takashi Iwai]

At Fri, 26 Jan 2007 05:53:36 -0500,
[EMAIL PROTECTED] wrote:
 
 On 1/25/07, Greg KH [EMAIL PROTECTED] wrote:
 
  Is there anything else left to fix?
 
 Once that testing is done, no.  But don't trust the two patches I sent
 yet, I'll resumbit the patch resulting from more thorough testing in a
 few hours (much thanks to Takashi for giving me the parent device
 feedback I was trolling for).

After rechecking the current code regarding this sysfs change at last
night, I found out that it's more broken for some devices like
sound/arm/*.  They refer to card-dev to obtain the device for memory
allocation, etc, and passing card* object will screw them up.

The below is my current fix.  Hoepfully all evils got away now...  and
thanks for Monty for heading up this issue!


Takashi


[PATCH] ALSA: Fix sysfs breakage

The recent change for a new sysfs tree with card* object breaks the
/sys/class/sound tree if CONFIG_SYSFS_DEPRECATED is enabled.
The device in each entry doesn't point the correct device object:

  /sys/class/sound
  ...
  |-- pcmC0D0c
  |   |-- dev
  |   |-- device - ../../../class/sound/card0
  |   |-- pcm_class
  |   |-- power
  |   |   `-- wakeup
  |   |-- subsystem - ../../../class/sound
  |   `-- uevent

Also, this change breaks some drivers (like sound/arm/*) referring
card-dev directly to obtain the device object for memory handling.

This patch reverts the semantics of card-dev to the former version,
which points to a real device object.  The card* object is stored in a
new card-card_dev field, instead.  The device parent is chosen either
card-dev or card-card_dev according to CONFIG_SYSFS_DEPRECATED to
keep the tree compatibility.
Also, card* isn't created if CONFIG_SYSFS_DEPRECATED is enabled.  The
reason of card* object is a root of all beloing devices, and it makes
little sense if each sound device points to the real device object
directly.

Signed-off-by: Takashi Iwai [EMAIL PROTECTED]
---
 include/sound/core.h   |   18 +++---
 sound/core/init.c  |   18 +++---
 sound/core/sound.c |4 +---
 sound/core/sound_oss.c |4 +---
 4 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/include/sound/core.h b/include/sound/core.h
index a994bea..521f036 100644
--- a/include/sound/core.h
+++ b/include/sound/core.h
@@ -132,8 +132,10 @@ struct snd_card {
int shutdown;   /* this card is going down */
int free_on_last_close; /* free in context of file_release */
wait_queue_head_t shutdown_sleep;
-   struct device *parent;
-   struct device *dev;
+   struct device *dev; /* device assigned to this card */
+#ifndef CONFIG_SYSFS_DEPRECATED
+   struct device *card_dev;/* cardX object for sysfs */
+#endif
 
 #ifdef CONFIG_PM
unsigned int power_state;   /* power state */
@@ -191,6 +193,16 @@ struct snd_minor {
struct device *dev; /* device for sysfs */
 };
 
+/* return a device pointer linked to each sound device as a parent */
+static inline struct device *snd_card_get_device_link(struct snd_card *card)
+{
+#ifdef CONFIG_SYSFS_DEPRECATED
+   return card ? card-dev : NULL;
+#else
+   return card ? card-card_dev : NULL;
+#endif
+}
+
 /* sound.c */
 
 extern int snd_major;
@@ -257,7 +269,7 @@ int snd_card_file_add(struct snd_card *c
 int snd_card_file_remove(struct snd_card *card, struct file *file);
 
 #ifndef snd_card_set_dev
-#define snd_card_set_dev(card,devptr) ((card)-parent = (devptr))
+#define snd_card_set_dev(card,devptr) ((card)-dev = (devptr))
 #endif
 
 /* device.c */
diff --git a/sound/core/init.c b/sound/core/init.c
index 6152a75..a4cc6b1 100644
--- a/sound/core/init.c
+++ b/sound/core/init.c
@@ -361,8 +361,10 @@ static int snd_card_do_free(struct snd_c
snd_printk(KERN_WARNING unable to free card info\n);
/* Not fatal error */
}
-   if (card-dev)
-   device_unregister(card-dev);
+#ifndef CONFIG_SYSFS_DEPRECATED
+   if (card-card_dev)
+   device_unregister(card-card_dev);
+#endif
kfree(card);
return 0;
 }
@@ -497,12 +499,14 @@ int snd_card_register(struct snd_card *c
int err;
 
snd_assert(card != NULL, return -EINVAL);
-   if (!card-dev) {
-   card-dev = device_create(sound_class, card-parent, 0,
- card%i, card-number);
-   if (IS_ERR(card-dev))
-   card-dev = NULL;
+#ifndef CONFIG_SYSFS_DEPRECATED
+   if (!card-card_dev) {
+   card-card_dev = device_create(sound_class, card-dev, 0,
+  card%i, card-number);
+   if (IS_ERR(card-card_dev))
+   card-card_dev = NULL;
}
+#endif
if ((err = snd_device_register_all(card))  0)
return err;
mutex_lock(snd_card_mutex);
diff --git a/sound/core/sound.c b/sound/core/sound.c

Re: [RFC] Track mlock()ed pages

[Nick Piggin]

Christoph Lameter wrote:

On Fri, 26 Jan 2007, Nick Piggin wrote:



Christoph Lameter wrote:


Add NR_MLOCK

Track mlocked pages via a ZVC


I think it is not quite right. You are tracking the number of ptes
that point to mlocked pages, which can be = the actual number of pages.



Mlocked pages are not inherited. I would expect sharing to be very rare.


Things like library and application text could easily have a lot of
sharing.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + aio-completion-signal-notification.patch added to -mm tree

[Oleg Nesterov]

On 01/26, S?bastien Dugu? wrote:

 On Thu, 25 Jan 2007 19:21:41 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:
 
   + target = good_sigevent(event);
   +
   + if (unlikely(!target || (target-flags  PF_EXITING)))
   + goto out_unlock;
  
  PF_EXITING check is racy and unneded. In fact, it is wrong. If the main
  thread is already died, we can only use SIGEV_THREAD_ID signals, because
  otherwise good_sigevent() returns -group_leader.
 
   Care to explain here please, I'm not following you.

My apologies, I was unclear.

This check is racy, the condition could be changed right after the check.

It is unneeded, it is ok to do send_sigqueue(tsk) if if that task is already
dead. (we hold the reference to task_struct).

Now suppose that the main thread (-group_leader) already exited. This is
normal, the thread group is still alive, it should be ok to send a signal to
it via send_group_sigqueue(). But we can't: without SIGEV_THREAD_ID in
-sigev_notify good_event() returns -group_leader, and it has PF_EXITING.

Yes, kernel/posix-timers.c needs a cleanup too. But please note that it does
this check for another reason (according to the comment). This reason is not
valid now, the callsite for exit_itimers() was moved from __exit_signal() to
do_exit().

   + if (iocb-ki_notify.notify != SIGEV_NONE) {
   + ret = aio_send_signal(iocb-ki_notify);
   +
   + /* If signal generation failed, release the sigqueue */
   + if (ret)
   + sigqueue_free(iocb-ki_notify.sigq);
  
  We should not use sigqueue_free() here. It takes current-sighand-siglock
  to remove sigqueue from struct sigpending. But current is just a random
  process here.
  
  Yes, if I understand this patch correctly, it is not possible that this
  sigqueue is pending, but still this is bad imho.
 
  Yes, in fact the sigqueue is used for a single signal delivery and then
 free. In fact I could have used directly __sigqueue_free() instead here
 except for the fact that it's private to signal.c and I'm reluctant
 to export it to other subsystems.

I personally think it is better to export __sigqueue_free() even if 
sigqueue_free()
happens to work. It is to fragile imho to reference current-sighand. At least
we need a fat comment.

static void __sigqueue_free(struct sigqueue *q)
{
   - if (q-flags  SIGQUEUE_PREALLOC)
   + if (q-flags  SIGQUEUE_PREALLOC  q-info.si_code != SI_ASYNCIO)
 return;
  
  Oh, this is not nice. Could we change send_sigqueue/send_group_sigqueue
  instead ?
 
   Yep, that's the other solution.
 
  
  -   BUG_ON(!(q-flags  SIGQUEUE_PREALLOC));
  +   BUG_ON(!(q-flags  SIGQUEUE_PREALLOC)  q-info.si_code != 
  SI_ASYNCIO);
  
  This way aio can use __sigqueue_alloc/__sigqueue_free directly and forget
  about SIGQUEUE_PREALLOC.
 
   Well, I don't think it's cleaner. The aio error path calls sigqueue_free()
 directly whereas in case of success sigqueue_free() is called from the signal
 delivery path.

Hmm... now I don't understand you. Of course, the aio error path should use
__sigqueue_free() if we don't use SIGQUEUE_PREALLOC (and imho we should not).

And the signal delivery path uses __sigqueue_free() too.

?

  I'd suggest to not use this interface. Just use group_send_sig_info() or
  specific_send_sig_info(). Yes, this way we will do GFP_ATOMIC allocation
  of sigqueue in interrupt context, but is this so bad in this case?
 
   Well, the thihere is that in the past we used group_send_sig_info()
 and specific_send_sig_info() for notification but Zach Brown raised
 the question about reliable signal delivery. IOW an aio submission
 should not succeed if signal delivery is going to fail. Hence the
 use of the preallocated sigqueue.

Ok, I see, thanks.

Oleg.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Track mlock()ed pages

[Nick Piggin]

Andrew Morton wrote:

On Thu, 25 Jan 2007 22:36:17 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:




I can't think of an easy way to do this without per-page state. ie.
another page flag.


Thats what I am trying to avoid.



You could perhaps go for a walk across all the other vmas which presently
map this page.  If any of them have VM_LOCKED, don't increment the counter.
Similar on removal: only decrement the counter when the final mlocked VMA
is dropping the pte.


Can't do with un-racily because you can't get that information
atomically, AFAIKS. When / if we ever lock the page in fault handler,
this could become easier... but that seems nasty to do in fault path,
even if only for VM_LOCKED vmas.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/10] local_t : mips extension

[Ralf Baechle]

On Thu, Jan 25, 2007 at 11:16:12AM -0500, Mathieu Desnoyers wrote:
 From: Mathieu Desnoyers [EMAIL PROTECTED]
 To:   linux-kernel@vger.kernel.org
 Cc:   Linus Torvalds [EMAIL PROTECTED], Andrew Morton [EMAIL PROTECTED],
   Ingo Molnar [EMAIL PROTECTED],
   Greg Kroah-Hartman [EMAIL PROTECTED],
   Christoph Hellwig [EMAIL PROTECTED], [EMAIL PROTECTED],
   [EMAIL PROTECTED],
   Douglas Niehaus [EMAIL PROTECTED],
   Martin J. Bligh [EMAIL PROTECTED],
   Thomas Gleixner [EMAIL PROTECTED],
   Paul Mackerras [EMAIL PROTECTED],
   Mathieu Desnoyers [EMAIL PROTECTED]

How about copying the MIPS maintainer or linux-mips mailing list instead
of a zillion people who probably don't care?

 Subject: [PATCH 05/10] local_t : mips extension
 Date: Thu, 25 Jan 2007 11:16:12 -0500
 
 local_t : mips extension
 
 Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
 --- a/include/asm-mips/local.h
 +++ b/include/asm-mips/local.h
 @@ -1,60 +1,524 @@
 -#ifndef _ASM_LOCAL_H
 -#define _ASM_LOCAL_H
 +#ifndef _ARCH_POWERPC_LOCAL_H
 +#define _ARCH_POWERPC_LOCAL_H

The subject claims this is a MIPS patch ;-)

  #include linux/percpu.h
  #include asm/atomic.h
  
 -#ifdef CONFIG_32BIT
 +typedef struct
 +{
 + local_long_t a;
 +} local_t;
  
 -typedef atomic_t local_t;
 +#define LOCAL_INIT(i){ local_LONG_INIT(i) }
  
 -#define LOCAL_INIT(i)ATOMIC_INIT(i)
 -#define local_read(v)atomic_read(v)
 -#define local_set(v,i)   atomic_set(v,i)
 +#define local_read(l)local_long_read((l)-a)
 +#define local_set(l,i)   local_long_set((l)-a, (i))
  
 -#define local_inc(v) atomic_inc(v)
 -#define local_dec(v) atomic_dec(v)
 -#define local_add(i, v)  atomic_add(i, v)
 -#define local_sub(i, v)  atomic_sub(i, v)
 +#define local_add(i,l)   local_long_add((i),((l)-a))
 +#define local_sub(i,l)   local_long_sub((i),((l)-a))
 +#define local_inc(l) local_long_inc((l)-a)
 +#define local_dec(l) local_long_dec((l)-a)
  
 -#endif
  
 -#ifdef CONFIG_64BIT
 +#ifndef CONFIG_64BITS

There is no CONFIG_64BITS

 -typedef atomic64_t local_t;
 +/*
 + * Same as above, but return the result value
 + */
 +static __inline__ int local_add_return(int i, local_t * l)
 +{
 + unsigned long result;
 +
 + if (cpu_has_llsc  R1_LLSC_WAR) {

Missing #include  asm/war.h.

 + unsigned long temp;
 +
 + __asm__ __volatile__(
 +.setmips3   \n
 + 1: ll  %1, %2  # local_add_return  \n
 +addu%0, %1, %3  \n
 +sc  %0, %2  \n
 +beqzl   %0, 1b  \n
 +addu%0, %1, %3  \n
 +.setmips0   \n
 + : =r (result), =r (temp), =m ((l-a.counter))
 + : Ir (i), m ((l-a.counter))
 + : memory);
 + } else if (cpu_has_llsc) {
 + unsigned long temp;
 +
 + __asm__ __volatile__(
 +.setmips3   \n
 + 1: ll  %1, %2  # local_add_return  \n
 +addu%0, %1, %3  \n
 +sc  %0, %2  \n
 +beqz%0, 1b  \n
 +addu%0, %1, %3  \n
 +.setmips0   \n
 + : =r (result), =r (temp), =m ((l-a.counter))
 + : Ir (i), m ((l-a.counter))
 + : memory);
 + } else {
 + unsigned long flags;
 +
 + local_irq_save(flags);
 + result = (l-a.counter);
 + local_irq_restore(flags);
 + }

Asigning some pointer value to an integer variable with no cast?

 + result += i;
 + (l-a.counter) = result;

Invalid lvalue in assignment.

What I generally dislike about this patch is that several fairly large
functions have been duplicated with only little change.

  Ralf
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Intel PCI-E bridge ACPI resources and possibly related SATA unstability problems on ASUS A8Js

[Martin Drab]

On Thu, 25 Jan 2007, Oleg Verych wrote:

 On Thu, Jan 25, 2007 at 01:28:56PM +0100, Martin Drab wrote:
  On Thu, 25 Jan 2007, Oleg Verych wrote:
  
   gmane.linux.kernel:
recently I got my hands on an ASUS A8Js notebook (Core 2 Duo T7200,
Intel 945 PM PCI-E Chipset, for details see attached log). After 
booting 
the latest 2.6.20-rc5-git3 kernel (but the same behaviour occurs also 
with 
the 2.6.19.2, didn't try any other), some strange behaviour can be 
observed.
   
   There were disscussions about mmconfig and what nightmare it brought to
   PCI(E) configuration in scope of BIOS, chip bugs. Here's (one of) such:
   http://marc.theaimsgroup.com/?l=linux-kernelm=116007091004503w=2
   
At first the following messages appear in the log:
   
...
   [   40.303154] PCI: BIOS *Bug*: MCFG area at e000 is not 
 E820-reserved
[   40.303157] PCI: Not using MMCONFIG.
   
(not sure whether this is really a problem)
   
   I think it may be the major problem.
  
  Hmm, it may be. Was there suggested any solution (or at least proposal) 
  that I may try?
 
 Try fix BIOS bugs: http://permalink.gmane.org/gmane.linux.kernel/462632

ASUS refused to help fixing the BIOS with words that ASUS notebooks do not 
support Linux. So if we do not workaround this somehow, Linux would really 
be unusable on this HW. :(

Martin
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[Mauro Carvalho Chehab]

Em Qui, 2007-01-25 às 12:51 -0800, David Miller escreveu:
 From: Dirk Hohndel [EMAIL PROTECTED]
 Date: Thu, 25 Jan 2007 06:22:54 -0800
 

 It's too damn repetitive to go to the same location over and over.
 Why do you think LCA tries to go to a different city every year and
 even let foreigners run the show last year in New Zealand? :-)
 Nobody want to go to the same place twice if they have to travel
 at all.
 
 As an added bonus, we can hand off the conference organizing to
 different folks in the local location each year.  That will also add
 some new life and excitement to kernel summit, have different people
 chair, organize, and run the conference.  If you use the same people,
 just like using the same venue, the thing gets stale, and the kernel
 summit is extremely stale at the moment.
 
 That's what I'm against, going to the same location over and over.  It
 makes the event more like a chore than something to look forward to
 and enjoy.
If the conference would be hold in Brazil, I may help having local
support. 

The company I work hold last year an ETSI internal meeting about IMS in
Brasília. It were a very interesting experience. The meeting were closed
to ETSI members and some people invited. After the meeting, there were
two days of an open event.

It should be noticed that about 99.9% of the attendants came from
Europe, with travelling costs covered by their companies. The Brazilian
company organized the event and covered some local costs (like
lunch/dinner/cocktail/event hostage).

Probably, the major companies with worldwide presence will cover
travelling costs, whatever place KS would be hold, since the local
offices of those companies will have interests on holding the
conference.

Just my $2 cents.

Cheers,
Mauro.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/8] Add __GFP_MOVABLE for callers to flag allocations that may be migrated

[Nick Piggin]

Mel Gorman wrote:

It is often known at allocation time when a page may be migrated or
not. This patch adds a flag called __GFP_MOVABLE and a new mask called
GFP_HIGH_MOVABLE.


Shouldn't that be HIGHUSER_MOVABLE?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] AVR32 fix + defconfig update

[Haavard Skinnemoen]

Hi Linus,

Please pull from the 'for-linus' branch of

git://www.atmel.no/~hskinnemoen/linux/kernel/avr32.git for-linus

to receive the following updates. This fixes a build error when
compiling the ext3 filesystem as a module and adds the macb ethernet
driver to the defconfig for ATSTK1000.

 arch/avr32/configs/atstk1002_defconfig |   39 ++-
 arch/avr32/kernel/avr32_ksyms.c|1 +
 2 files changed, 28 insertions(+), 12 deletions(-)

Haavard Skinnemoen (2):
  [AVR32] Export clear_page symbol
  [AVR32] Update ATSTK1000 defconfig: Enable macb by default

diff --git a/arch/avr32/configs/atstk1002_defconfig 
b/arch/avr32/configs/atstk1002_defconfig
index ae92a14..77dace9 100644
--- a/arch/avr32/configs/atstk1002_defconfig
+++ b/arch/avr32/configs/atstk1002_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.19-rc2
-# Fri Oct 20 11:52:37 2006
+# Linux kernel version: 2.6.20-rc6
+# Fri Jan 26 13:12:59 2007
 #
 CONFIG_AVR32=y
 CONFIG_GENERIC_HARDIRQS=y
@@ -9,6 +9,8 @@ CONFIG_HARDIRQS_SW_RESEND=y
 CONFIG_GENERIC_IRQ_PROBE=y
 CONFIG_RWSEM_GENERIC_SPINLOCK=y
 CONFIG_GENERIC_TIME=y
+# CONFIG_ARCH_HAS_ILOG2_U32 is not set
+# CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_CALIBRATE_DELAY=y
 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
@@ -36,6 +38,7 @@ CONFIG_TASK_DELAY_ACCT=y
 # CONFIG_UTS_NS is not set
 CONFIG_AUDIT=y
 # CONFIG_IKCONFIG is not set
+CONFIG_SYSFS_DEPRECATED=y
 CONFIG_RELAY=y
 CONFIG_INITRAMFS_SOURCE=
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
@@ -75,7 +78,9 @@ CONFIG_MODULE_UNLOAD=y
 # Block layer
 #
 CONFIG_BLOCK=y
+# CONFIG_LBD is not set
 # CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
 
 #
 # IO Schedulers
@@ -125,6 +130,7 @@ CONFIG_SPLIT_PTLOCK_CPUS=4
 # CONFIG_OWNERSHIP_TRACE is not set
 # CONFIG_HZ_100 is not set
 CONFIG_HZ_250=y
+# CONFIG_HZ_300 is not set
 # CONFIG_HZ_1000 is not set
 CONFIG_HZ=250
 CONFIG_CMDLINE=
@@ -182,6 +188,7 @@ CONFIG_INET_TCP_DIAG=y
 # CONFIG_TCP_CONG_ADVANCED is not set
 CONFIG_TCP_CONG_CUBIC=y
 CONFIG_DEFAULT_TCP_CONG=cubic
+# CONFIG_TCP_MD5SIG is not set
 # CONFIG_IPV6 is not set
 # CONFIG_INET6_XFRM_TUNNEL is not set
 # CONFIG_INET6_TUNNEL is not set
@@ -260,6 +267,7 @@ CONFIG_MTD_CMDLINE_PARTS=y
 # User Modules And Translation Layers
 #
 CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
 CONFIG_MTD_BLOCK=y
 # CONFIG_FTL is not set
 # CONFIG_NFTL is not set
@@ -355,7 +363,6 @@ CONFIG_BLK_DEV_INITRD=y
 #
 # Misc devices
 #
-# CONFIG_SGI_IOC4 is not set
 # CONFIG_TIFM_CORE is not set
 
 #
@@ -405,11 +412,14 @@ CONFIG_TUN=m
 #
 # PHY device support
 #
+# CONFIG_PHYLIB is not set
 
 #
 # Ethernet (10 or 100Mbit)
 #
-# CONFIG_NET_ETHERNET is not set
+CONFIG_NET_ETHERNET=y
+CONFIG_MII=y
+CONFIG_MACB=y
 
 #
 # Ethernet (1000 Mbit)
@@ -505,10 +515,6 @@ CONFIG_UNIX98_PTYS=y
 # CONFIG_GEN_RTC is not set
 # CONFIG_DTLK is not set
 # CONFIG_R3964 is not set
-
-#
-# Ftape, the floppy tape device driver
-#
 # CONFIG_RAW_DRIVER is not set
 
 #
@@ -621,6 +627,10 @@ CONFIG_UNIX98_PTYS=y
 #
 
 #
+# Virtualization
+#
+
+#
 # File systems
 #
 CONFIG_EXT2_FS=m
@@ -683,7 +693,6 @@ CONFIG_CONFIGFS_FS=m
 # CONFIG_BEFS_FS is not set
 # CONFIG_BFS_FS is not set
 # CONFIG_EFS_FS is not set
-# CONFIG_JFFS_FS is not set
 CONFIG_JFFS2_FS=y
 CONFIG_JFFS2_FS_DEBUG=0
 CONFIG_JFFS2_FS_WRITEBUFFER=y
@@ -763,6 +772,11 @@ CONFIG_NLS_ISO8859_1=m
 CONFIG_NLS_UTF8=m
 
 #
+# Distributed Lock Manager
+#
+# CONFIG_DLM is not set
+
+#
 # Kernel hacking
 #
 CONFIG_TRACE_IRQFLAGS_SUPPORT=y
@@ -770,6 +784,8 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y
 CONFIG_ENABLE_MUST_CHECK=y
 CONFIG_MAGIC_SYSRQ=y
 # CONFIG_UNUSED_SYMBOLS is not set
+CONFIG_DEBUG_FS=y
+# CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_DETECT_SOFTLOCKUP=y
@@ -785,13 +801,10 @@ CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_DEBUG_KOBJECT is not set
 CONFIG_DEBUG_BUGVERBOSE=y
 # CONFIG_DEBUG_INFO is not set
-CONFIG_DEBUG_FS=y
 # CONFIG_DEBUG_VM is not set
 # CONFIG_DEBUG_LIST is not set
 CONFIG_FRAME_POINTER=y
-# CONFIG_UNWIND_INFO is not set
 CONFIG_FORCED_INLINING=y
-# CONFIG_HEADERS_CHECK is not set
 # CONFIG_RCU_TORTURE_TEST is not set
 # CONFIG_KPROBES is not set
 
@@ -809,6 +822,7 @@ CONFIG_FORCED_INLINING=y
 #
 # Library routines
 #
+CONFIG_BITREVERSE=y
 CONFIG_CRC_CCITT=m
 # CONFIG_CRC16 is not set
 CONFIG_CRC32=y
@@ -817,3 +831,4 @@ CONFIG_AUDIT_GENERIC=y
 CONFIG_ZLIB_INFLATE=y
 CONFIG_ZLIB_DEFLATE=y
 CONFIG_PLIST=y
+CONFIG_IOMAP_COPY=y
diff --git a/arch/avr32/kernel/avr32_ksyms.c b/arch/avr32/kernel/avr32_ksyms.c
index 7c4c761..80f55f8 100644
--- a/arch/avr32/kernel/avr32_ksyms.c
+++ b/arch/avr32/kernel/avr32_ksyms.c
@@ -29,6 +29,7 @@ EXPORT_SYMBOL(__avr32_asr64);
  */
 EXPORT_SYMBOL(memset);
 EXPORT_SYMBOL(memcpy);
+EXPORT_SYMBOL(clear_page);
 
 /*
  * Userspace access stuff.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a 

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[Bjørn Mork]

Mauro Carvalho Chehab [EMAIL PROTECTED] writes:

 The company I work hold last year an ETSI internal meeting about IMS in
 Brasília. It were a very interesting experience. The meeting were closed
 to ETSI members and some people invited. After the meeting, there were
 two days of an open event.

 It should be noticed that about 99.9% of the attendants came from
 Europe, with travelling costs covered by their companies. The Brazilian
 company organized the event and covered some local costs (like
 lunch/dinner/cocktail/event hostage).

Well, FWIW, some years ago we (I was working for the Norwegian
regulatory body at the time) tried to host an ETSI working group
meeting in Longyearbyen ( http://en.wikipedia.org/wiki/Longyearbyen ).
Despite this actually being in Europe, there were quite a few
complaints. Some of the regular participants had problems with the
additional travelling expenses, but the most common complaint was the
wast of time.  And that was nowhere near an intercontinental flight...

We ended up having the meeting in Oslo, as usual.


Bjørn
-- 
I mean, it's well known that the oceans are full of dirty fish.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: r8169 problems on x86_64 (transmit timeout crash)

[mirek kratochvil]

In case you have BIOS 04.., try to upgrade to 06.. version. Also, does it
help when you boot with acpi=off kernel commandline parameter? (do you
compile kernel with both acpi and apic support?).

Jiri Kosina



Upgraded to bios 0802,  but still the same problem. I think it's
definitely something
about the r8169 driver. acpi=off doesn't help. turning on/off apic
also doesn't matter.

What exactly means msg Netdev watchdog: Transmit timed out ? I hope
the broblem
is just about that tx (dying when transmitting...), because otherwise
I'd start suspecting
hardware. (note: full-speed receive doesn't crash anything)

one thing more - have confirmed that the bug is reproducible on *any*
laptop with 8168,
not only Asus. I guess the disk-usage-crash was some other bug.

I'm gonna ask some other people with 8168Realtek NICs to test this, hope some of
them can reproduce this and get better view of what's going on...

thanks
mirek kratochvil
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.18-stable release plans?

[Chris Rankin]

--- Ken Moffat [EMAIL PROTECTED] wrote:
  I can't, but Dave Jones had a similar problem earlier this month,
 archived at http://uwsg.iu.edu/hypermail/linux/kernel/0701.0/1822.html
 which I think is a followup from
 http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg105370.html
  - and seems to be a possible hardware failure (bulging capacitors)
 becoming apparent under load.

Interesting, although I don't believe I have a hardware fault. The box is 
perfectly stable under
2.6.18.x. Anyway, my particular problem happened very quickly last time so I am 
hoping that
recompiling xine from scratch will trigger something again. This time, however, 
I have built a
2.6.19.x kernel with a few memory debugging options turned on.

Cheers,
Chris



___ 
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy 
and free. http://uk.docs.yahoo.com/trueswitch2.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] ARM: Convert to use shared APM emulation.

[Ralf Baechle]

On Wed, Jan 24, 2007 at 05:50:51PM +, Pavel Machek wrote:

   arch/arm/Kconfig   |   29 ++
   arch/arm/common/sharpsl_pm.c   |2 -
   arch/arm/kernel/Makefile   |1 
   arch/arm/mach-pxa/corgi_pm.c   |2 -
   arch/arm/mach-pxa/sharpsl_pm.c |2 -
   arch/arm/mach-pxa/spitz_pm.c   |2 -
   include/asm-arm/apm.h  |   64 
  -
   7 files changed, 8 insertions(+), 94 deletions(-)
 
 Maybe you should delete apm.c, too?

Indeed ...  New patch in reply to this email.

Thanks,

  Ralf
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bugfixes: PCI devices get assigned redundant IRQs

[Andreas Block]

On Fri, 26 Jan 2007 12:00:55 +0100, Xavier Bestel [EMAIL PROTECTED]  
wrote:

On Fri, 2007-01-26 at 11:50 +0100, Andreas Block wrote:


u8 pin, slot;
-   int irq;
+   int irq = 0;


Aren't there platforms for which irq = 0 is a valid irq ?


As far as I understand the PCI spec, the answer to your question seems to  
be: no

(or I'm missing something).

Don't get me wrong. I'm not talking about system IRQs, but about the value  
of the Interrupt Pin Register in PCI configuration space.


The PCI Local Bus Specification in Revision 3.0 from 3rd February 2004  
says on page 223 about the content of Interrupt Pin register:


Value 0x00: _No_ interrupt
Values 0x01 to 0x04: Interrupt lines A to D
And values 5 to 0xFF are reserved.

So I'd say, the correction of greater values than four to a value of one  
seems discussable, too. Because it will break any future changes of the  
PCI spec.


Andreas

--
-

_/_/_/_/   Andreas Block
   _/_/_/_/   Dipl.-Ing.
  _/_/_/_/   [EMAIL PROTECTED]

  _/_/_/   _/_/_/_/_/_/_/  esd electronic system design gmbh
_/   _/  _/ _/Vahrenwalder Str. 207
   _/   _/_/_/_/   _/   _/   D-30165 Hannover
   _/ _/  _/   _/   Phone: +49-511-37298-0
_/_/_/_/_/_/_/   _/_/_/Fax:   +49-511-37298-68
  http://www.esd-electronics.com

-

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] ARM: Convert to use shared APM emulation.

[Ralf Baechle]

Signed-off-by: Ralf Baechle [EMAIL PROTECTED]

 arch/arm/Kconfig   |   29 -
 arch/arm/common/sharpsl_pm.c   |2 
 arch/arm/kernel/Makefile   |1 
 arch/arm/kernel/apm.c  |  672 -
 arch/arm/mach-pxa/corgi_pm.c   |2 
 arch/arm/mach-pxa/sharpsl_pm.c |2 
 arch/arm/mach-pxa/spitz_pm.c   |2 
 include/asm-arm/apm.h  |   64 ---
 8 files changed, 8 insertions(+), 766 deletions(-)

Index: linux-apm/arch/arm/Kconfig
===
--- linux-apm.orig/arch/arm/Kconfig
+++ linux-apm/arch/arm/Kconfig
@@ -9,6 +9,7 @@ config ARM
bool
default y
select RTC_LIB
+   select SYS_SUPPORTS_APM_EMULATION
help
  The ARM series is a line of low-power-consumption RISC chip designs
  licensed by ARM Ltd and targeted at embedded applications and
@@ -17,6 +18,9 @@ config ARM
  Europe.  There is an ARM Linux project with a web page at
  http://www.arm.linux.org.uk/.
 
+config SYS_SUPPORTS_APM_EMULATION
+   bool
+
 config GENERIC_TIME
bool
default n
@@ -856,31 +860,6 @@ menu Power management options
 
 source kernel/power/Kconfig
 
-config APM
-   tristate Advanced Power Management Emulation
-   ---help---
- APM is a BIOS specification for saving power using several different
- techniques. This is mostly useful for battery powered laptops with
- APM compliant BIOSes. If you say Y here, the system time will be
- reset after a RESUME operation, the /proc/apm device will provide
- battery status information, and user-space programs will receive
- notification of APM events (e.g. battery status change).
-
- In order to use APM, you will need supporting software. For location
- and more information, read file:Documentation/pm.txt and the
- Battery Powered Linux mini-HOWTO, available from
- http://www.tldp.org/docs.html#howto.
-
- This driver does not spin down disk drives (see the hdparm(8)
- manpage (man 8 hdparm) for that), and it doesn't turn off
- VESA-compliant green monitors.
-
- Generally, if you don't have a battery in your machine, there isn't
- much point in using this driver and you should say N. If you get
- random kernel OOPSes or reboots that don't seem to be related to
- anything, try disabling/enabling this option (or disabling/enabling
- APM in your BIOS).
-
 endmenu
 
 source net/Kconfig
Index: linux-apm/arch/arm/common/sharpsl_pm.c
===
--- linux-apm.orig/arch/arm/common/sharpsl_pm.c
+++ linux-apm/arch/arm/common/sharpsl_pm.c
@@ -27,7 +27,7 @@
 #include asm/hardware.h
 #include asm/mach-types.h
 #include asm/irq.h
-#include asm/apm.h
+#include asm/apm-emulation.h
 #include asm/arch/pm.h
 #include asm/arch/pxa-regs.h
 #include asm/arch/sharpsl.h
Index: linux-apm/arch/arm/kernel/Makefile
===
--- linux-apm.orig/arch/arm/kernel/Makefile
+++ linux-apm/arch/arm/kernel/Makefile
@@ -10,7 +10,6 @@ obj-y := compat.o entry-armv.o entry-co
   process.o ptrace.o semaphore.o setup.o signal.o sys_arm.o \
   time.o traps.o
 
-obj-$(CONFIG_APM)  += apm.o
 obj-$(CONFIG_ISA_DMA_API)  += dma.o
 obj-$(CONFIG_ARCH_ACORN)   += ecard.o 
 obj-$(CONFIG_FIQ)  += fiq.o
Index: linux-apm/arch/arm/mach-pxa/corgi_pm.c
===
--- linux-apm.orig/arch/arm/mach-pxa/corgi_pm.c
+++ linux-apm/arch/arm/mach-pxa/corgi_pm.c
@@ -16,7 +16,7 @@
 #include linux/delay.h
 #include linux/interrupt.h
 #include linux/platform_device.h
-#include asm/apm.h
+#include asm/apm-emulation.h
 #include asm/irq.h
 #include asm/mach-types.h
 #include asm/hardware.h
Index: linux-apm/arch/arm/mach-pxa/sharpsl_pm.c
===
--- linux-apm.orig/arch/arm/mach-pxa/sharpsl_pm.c
+++ linux-apm/arch/arm/mach-pxa/sharpsl_pm.c
@@ -23,7 +23,7 @@
 
 #include asm/hardware.h
 #include asm/mach-types.h
-#include asm/apm.h
+#include asm/apm-emulation.h
 #include asm/arch/pm.h
 #include asm/arch/pxa-regs.h
 #include asm/arch/sharpsl.h
Index: linux-apm/arch/arm/mach-pxa/spitz_pm.c
===
--- linux-apm.orig/arch/arm/mach-pxa/spitz_pm.c
+++ linux-apm/arch/arm/mach-pxa/spitz_pm.c
@@ -16,7 +16,7 @@
 #include linux/delay.h
 #include linux/interrupt.h
 #include linux/platform_device.h
-#include asm/apm.h
+#include asm/apm-emulation.h
 #include asm/irq.h
 #include asm/mach-types.h
 #include asm/hardware.h
Index: linux-apm/include/asm-arm/apm.h
===
--- linux-apm.orig/include/asm-arm/apm.h
+++ /dev/null

Re: + aio-completion-signal-notification.patch added to -mm tree

[Sébastien Dugué]

On Fri, 26 Jan 2007 14:52:33 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:

 On 01/26, S?bastien Dugu? wrote:
 
  On Thu, 25 Jan 2007 19:21:41 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:
  
+   target = good_sigevent(event);
+
+   if (unlikely(!target || (target-flags  PF_EXITING)))
+   goto out_unlock;
   
   PF_EXITING check is racy and unneded. In fact, it is wrong. If the main
   thread is already died, we can only use SIGEV_THREAD_ID signals, because
   otherwise good_sigevent() returns -group_leader.
  
Care to explain here please, I'm not following you.
 
 My apologies, I was unclear.
 
 This check is racy, the condition could be changed right after the check.
 
 It is unneeded, it is ok to do send_sigqueue(tsk) if if that task is already
 dead. (we hold the reference to task_struct).
 
 Now suppose that the main thread (-group_leader) already exited. This is
 normal, the thread group is still alive, it should be ok to send a signal to
 it via send_group_sigqueue(). But we can't: without SIGEV_THREAD_ID in
 -sigev_notify good_event() returns -group_leader, and it has PF_EXITING.

  Thanks, I understand the problem now. I will fix this.

 
 Yes, kernel/posix-timers.c needs a cleanup too. But please note that it does
 this check for another reason (according to the comment). This reason is not
 valid now, the callsite for exit_itimers() was moved from __exit_signal() to
 do_exit().
 
+   if (iocb-ki_notify.notify != SIGEV_NONE) {
+   ret = aio_send_signal(iocb-ki_notify);
+
+   /* If signal generation failed, release the sigqueue */
+   if (ret)
+   sigqueue_free(iocb-ki_notify.sigq);
   
   We should not use sigqueue_free() here. It takes current-sighand-siglock
   to remove sigqueue from struct sigpending. But current is just a 
   random
   process here.
   
   Yes, if I understand this patch correctly, it is not possible that this
   sigqueue is pending, but still this is bad imho.
  
   Yes, in fact the sigqueue is used for a single signal delivery and then
  free. In fact I could have used directly __sigqueue_free() instead here
  except for the fact that it's private to signal.c and I'm reluctant
  to export it to other subsystems.
 
 I personally think it is better to export __sigqueue_free() even if 
 sigqueue_free()
 happens to work. It is to fragile imho to reference current-sighand. At least
 we need a fat comment.

  OK.

 
 static void __sigqueue_free(struct sigqueue *q)
 {
-   if (q-flags  SIGQUEUE_PREALLOC)
+   if (q-flags  SIGQUEUE_PREALLOC  q-info.si_code != 
SI_ASYNCIO)
return;
   
   Oh, this is not nice. Could we change send_sigqueue/send_group_sigqueue
   instead ?
  
Yep, that's the other solution.
  
   
   - BUG_ON(!(q-flags  SIGQUEUE_PREALLOC));
   + BUG_ON(!(q-flags  SIGQUEUE_PREALLOC)  q-info.si_code != 
   SI_ASYNCIO);
   
   This way aio can use __sigqueue_alloc/__sigqueue_free directly and forget
   about SIGQUEUE_PREALLOC.
  
Well, I don't think it's cleaner. The aio error path calls sigqueue_free()
  directly whereas in case of success sigqueue_free() is called from the 
  signal
  delivery path.
 
 Hmm... now I don't understand you. Of course, the aio error path should use
 __sigqueue_free() if we don't use SIGQUEUE_PREALLOC (and imho we should not).
 
 And the signal delivery path uses __sigqueue_free() too.
 
 ?
 
   I'd suggest to not use this interface. Just use group_send_sig_info() or
   specific_send_sig_info(). Yes, this way we will do GFP_ATOMIC allocation
   of sigqueue in interrupt context, but is this so bad in this case?
  
Well, the thihere is that in the past we used group_send_sig_info()
  and specific_send_sig_info() for notification but Zach Brown raised
  the question about reliable signal delivery. IOW an aio submission
  should not succeed if signal delivery is going to fail. Hence the
  use of the preallocated sigqueue.
 
 Ok, I see, thanks.
 
 Oleg.
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: In-tree version of new FireWire drivers available

[Robert Crocombe]

On 1/25/07, Pieter Palmers [EMAIL PROTECTED] wrote:

I'd like to make one note here:
We should have a way to use smaller DMA buffers than one page size. If I
remember correctly, the page size on my system is 4096 bytes, being 1024
quadlets. If we assume a 4 channel audio stream, this corresponds to 256
audio samples. This means that the controller generates an interrupt
every 256 samples, making that we can achieve a latency of 512 samples
at best. This is unacceptable in a pro-audio environment.

The current stack exhibits this problem, and I solve it by recalculating
the max packet size, based upon the stream composition (i.e. expected
packet size) and the requested audio buffer size, such that the
interrupts are generated at a high enough frequency.

I'm not a kernel hacker, but when looking through the code I had the
impression that smaller DMA buffers were possible (aren't smaller
buffers used in packet-per-buffer mode?).


I am using isochronous receive in RAW1394_DMA_PACKET_PER_BUFFER mode
because I am closing a simulation loop around the data that is
received/transmitted.  Just for giggles I cranked up a test
isochronous stream from a bus analyzer at 1kB per packet at 8kHz at
the S400 rate (i.e., one packet on each cycle start: 8MBps ), set the
machine up to listen, and was able to maintain 8kHz interrupts at ~12%
CPU utilization on a 2.8GHz Opteron.

  1744719 interrupts int 218.112 seconds is 7999.193 ints/sec

I wasn't doing anything with the data for this test, but I have had
the aforementioned sim running steady at a somewhat lower rate.  This
test ran under 2.6.20-rc5-rt10, but the more productiony system is
on 2.6.16-rt29.

So hopefully you can get markedly lower latencies.  Myself, I'm
tickled pink by the performance that can be achieved.

--
Robert Crocombe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/