linux.git/drivers/mtd, branch v3.7-rc8

revert "Revert "mm: remove __GFP_NO_KSWAPD""

2012-11-30T16:51:17+00:00

It apepars that this patch was innocent, and we hope that "mm: avoid
waking kswapd for THP allocations when compaction is deferred or
contended" will fix the final kswapd-spinning cause.

Cc: Zdenek Kabelac 
Cc: Seth Jennings 
Cc: Valdis Kletnieks 
Cc: Jiri Slaby 
Cc: Rik van Riel 
Cc: Robert Jennings 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Revert "mm: remove __GFP_NO_KSWAPD"

2012-11-27T01:41:24+00:00

With "mm: vmscan: scale number of pages reclaimed by reclaim/compaction
based on failures" reverted, Zdenek Kabelac reported the following

  Hmm,  so it's just took longer to hit the problem and observe
  kswapd0 spinning on my CPU again - it's not as endless like before -
  but still it easily eats minutes - it helps to	turn off  Firefox
  or TB  (memory hungry apps) so kswapd0 stops soon - and restart
  those apps again.  (And I still have like >1GB of cached memory)

  kswapd0         R  running task        0    30      2 0x00000000
  Call Trace:
    preempt_schedule+0x42/0x60
    _raw_spin_unlock+0x55/0x60
    put_super+0x31/0x40
    drop_super+0x22/0x30
    prune_super+0x149/0x1b0
    shrink_slab+0xba/0x510

The sysrq+m indicates the system has no swap so it'll never reclaim
anonymous pages as part of reclaim/compaction.  That is one part of the
problem but not the root cause as file-backed pages could also be
reclaimed.

The likely underlying problem is that kswapd is woken up or kept awake
for each THP allocation request in the page allocator slow path.

If compaction fails for the requesting process then compaction will be
deferred for a time and direct reclaim is avoided.  However, if there
are a storm of THP requests that are simply rejected, it will still be
the the case that kswapd is awake for a prolonged period of time as
pgdat->kswapd_max_order is updated each time.  This is noticed by the
main kswapd() loop and it will not call kswapd_try_to_sleep().  Instead
it will loopp, shrinking a small number of pages and calling
shrink_slab() on each iteration.

The temptation is to supply a patch that checks if kswapd was woken for
THP and if so ignore pgdat->kswapd_max_order but it'll be a hack and not
backed up by proper testing.  As 3.7 is very close to release and this
is not a bug we should release with, a safer path is to revert "mm:
remove __GFP_NO_KSWAPD" for now and revisit it with the view to ironing
out the balance_pgdat() logic in general.

Signed-off-by: Mel Gorman 
Cc: Zdenek Kabelac 
Cc: Seth Jennings 
Cc: Valdis Kletnieks 
Cc: Jiri Slaby 
Cc: Rik van Riel 
Cc: Robert Jennings 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'for-3.7' of git://git.infradead.org/users/dedekind/l2-mtd

2012-11-21T10:38:13+00:00

Conflicts:
	drivers/mtd/nand/nand_base.c

mtd: nand: fix Samsung SLC detection regression

2012-11-15T13:37:43+00:00

This patch fixes errors seen in identifying old Samsung SLC, due to the
following commits:

    commit e2d3a35ee427aaba99b6c68a56609ce276c51270
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

    commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a
    mtd: nand: add generic READ ID length calculation functions

Some Samsung NAND with "5-byte" ID really appear to have 6-byte IDs, with
wraparound like:

  Samsung K9K8G08U0D
  ec d3 51 95 58 ec ec d3

  Samsung K9F1G08U0C
  ec f1 00 95 40 ec ec f1

  Samsung K9F2G08U0B
  ec da 10 95 44 00 ec da

This bad wraparound makes it hard to reliably detect the difference
between Samsung SLC with 5-byte ID and Samsung SLC with 6-byte ID.

The fix is to, for now, only use the new Samsung table for MLC. We
cannot support the new SLC (K9FAG08U0M) until Samsung gives better ID
decode information.

Note that this applies in addition to the previous regression fix:

    commit bc86cf7af2ebda88056538e8edff852ee627f76a
    mtd: nand: fix Samsung SLC NAND identification regression

Together, these patches completely restore the previous detection
behavior so that we cannot see any more regressions in Samsung SLC NAND
(finger crossed). With luck, I can get a hold of a Samsung
representative and stop having to cross my fingers eventually.

Reported-by: Sylwester Nawrocki 
Tested-by: Sylwester Nawrocki 
Signed-off-by: Brian Norris 
Signed-off-by: Artem Bityutskiy

mtd: nand: fix Samsung SLC NAND identification regression

2012-11-15T13:37:16+00:00

A combination of the following two commits caused a regression in 3.7-rc1
when identifying some Samsung NAND, so that some previously working NAND
were no longer detected properly:

    commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a
    mtd: nand: add generic READ ID length calculation functions

    commit e2d3a35ee427aaba99b6c68a56609ce276c51270
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

Particularly, a regression was seen on Samsung K9F2G08U0B, with the
following full 8-byte READ ID string:

    ec da 10 95 44 00 ec da

The basic problem is that Samsung manufactures both SLC and MLC NAND
that use a non-standard decoding table for deriving information from
their IDs. I have heuristically determined that all the chips that use
the new table have ID strings which wrap around after the 6th byte.
Unfortunately, I overlooked the fact that some older Samsung SLC (which
use a different decoding table) have "5 byte ID strings" which also wrap
around after the 6th byte.

This patch re-introduces a distinction between these old and new Samsung
NAND by checking that the 6th byte is non-zero, allowing both old and
new Samsung NAND to be detected properly.

Signed-off-by: Brian Norris 
Tested-by: Brian Norris 
Reported-by: Marek Vasut 
Tested-by: Marek Vasut 
Signed-off-by: Artem Bityutskiy

mtd: onenand: Make flexonenand_set_boundary static

2012-11-09T15:02:50+00:00

Fixes the following sparse warning:
drivers/mtd/onenand/onenand_base.c:3697:5: warning:
symbol 'flexonenand_set_boundary' was not declared. Should it be static?

Signed-off-by: Sachin Kamat 
Acked-by: Kyungmin Park 
Signed-off-by: Artem Bityutskiy

mtd: slram: invalid checking of absolute end address

2012-11-09T15:02:50+00:00

Fixed parsing end absolute address.

Signed-off-by: Jiri Engelthaler 
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy

mtd: ofpart: Fix incorrect NULL check in parse_ofoldpart_partitions()

2012-10-10T08:12:39+00:00

The pointer returned by kzalloc should be tested for NULL
to avoid potential NULL pointer dereference later. Incorrect
pointer was being tested for NULL. Bug introduced by commit fbcf62a3
(mtd: physmap_of: move parse_obsolete_partitions to become separate
parser).
This patch fixes this bug.

Cc: Dmitry Eremin-Solenikov 
Cc: Artem Bityutskiy 
Cc: stable@kernel.org
Signed-off-by: Sachin Kamat 
Signed-off-by: David Woodhouse

mtd: nand: fix Samsung SLC NAND identification regression

2012-10-10T06:30:37+00:00

A combination of the following two commits caused a regression in 3.7-rc1
when identifying some Samsung NAND, so that some previously working NAND
were no longer detected properly:

    commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a
    mtd: nand: add generic READ ID length calculation functions

    commit e2d3a35ee427aaba99b6c68a56609ce276c51270
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

Particularly, a regression was seen on Samsung K9F2G08U0B, with the
following full 8-byte READ ID string:

    ec da 10 95 44 00 ec da

The basic problem is that Samsung manufactures both SLC and MLC NAND
that use a non-standard decoding table for deriving information from
their IDs. I have heuristically determined that all the chips that use
the new table have ID strings which wrap around after the 6th byte.
Unfortunately, I overlooked the fact that some older Samsung SLC (which
use a different decoding table) have "5 byte ID strings" which also wrap
around after the 6th byte.

This patch re-introduces a distinction between these old and new Samsung
NAND by checking that the 6th byte is non-zero, allowing both old and
new Samsung NAND to be detected properly.

Signed-off-by: Brian Norris 
Tested-by: Brian Norris 
Reported-by: Marek Vasut 
Tested-by: Marek Vasut 
Signed-off-by: David Woodhouse

mtd: Disable mtdchar mmap on MMU systems

2012-10-09T14:08:42+00:00

This code was broken because it assumed that all MTD devices were map-based.
Disable it for now, until it can be fixed properly for the next merge window.

Signed-off-by: David Woodhouse