* [MIPS]clocks_calc_mult_shift() may gen a too big mult value
From: Chen Jie @ 2011-10-31 9:00 UTC (permalink / raw)
To: linux-mips, LKML
Cc: johnstul, tglx, yanhua, 项宇, zhangfx,
孙海勇
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
Hi all,
On MIPS, with maxsec=4, clocks_calc_mult_shift() may generate a very
big mult, which may easily cause timekeeper.mult overflow within
timekeeping jobs.
e.g. when clock freq was 250000500(i.e. mips_hpt_frequency=250000500,
and the CPU Freq will be 250000500*2=500001000), mult will be
0xffffde72
Attachment is a script that calculates mult values for CPU Freq
between 400050000 and 500050000, with 1KHz step. It outputs mult
values greater than 0xf0000000:
CPU Freq:500001000, mult:0xffffde72, shift:30
CPU Freq:500002000, mult:0xffffbce4, shift:30
CPU Freq:500003000, mult:0xffff9b56, shift:30
CPU Freq:500004000, mult:0xffff79c9, shift:30
...
The peak value appears around CPU_freq=500001000.
To avoid this, it may need:
1. Supply a bigger maxsec value?
2. In clocks_calc_mult_shift(), pick next mult/shift pair if mult is
too big? Then maxsec will not be strictly obeyed.
3. Change timekeeper.mult to u64?
4. ...
Any idea?
--
Regards,
- Chen Jie
[-- Attachment #2: mult-test.py --]
[-- Type: text/x-python, Size: 511 bytes --]
#!/bin/env python
def clocks_calc_mult_shift(from_, to_, maxsec):
sftacc = 32;
tmp = maxsec * from_ >> 32;
while tmp:
tmp >>= 1
sftacc -= 1
for sft in xrange(32, 0, -1):
tmp = to_ << sft;
tmp += (from_ / 2)
tmp /= from_
if ((tmp >> sftacc) == 0):
break
mult = tmp
shift = sft
return mult, shift
for i in xrange(400050000, 500050000, 1000):
mult, shift = clocks_calc_mult_shift(i/2, 1000000000, 4)
if mult > 0xf0000000:
print "CPU Freq:%d, mult:0x%x, shift:%d" % (i, mult, shift)
^ permalink raw reply
* Re: [PATCH] dbus: add work around to set right owner in postinst
From: Koen Kooi @ 2011-10-31 8:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319885588-5947-1-git-send-email-Martin.Jansa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Op 29 okt. 2011, om 12:53 heeft Martin Jansa het volgende geschreven:
> * even when I see right chown/chmod in log.do_install, files are still
> owned by bitbake:bitbake (user running bitbake) and we need to fix it on target
I suspect fsperms.txt is breaking things, but I haven't tested it yet.
regards,
Koen
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH] pm9263: add mach-type localy for the board
From: Igor Grinberg @ 2011-10-31 9:00 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319818261-27813-1-git-send-email-dimov@ronetix.at>
Hi Asen,
Same comments as for pm9261, hold here.
On 10/28/11 18:11, Asen Chavdarov Dimov wrote:
>
> Signed-off-by: Asen Chavdarov Dimov <dimov@ronetix.at>
> ---
> board/ronetix/pm9263/mach-type.h | 31 +++++++++++++++++++++++++++++++
> board/ronetix/pm9263/pm9263.c | 1 +
> 2 files changed, 32 insertions(+), 0 deletions(-)
> create mode 100644 board/ronetix/pm9263/mach-type.h
>
> diff --git a/board/ronetix/pm9263/mach-type.h b/board/ronetix/pm9263/mach-type.h
> new file mode 100644
> index 0000000..afa02df
> --- /dev/null
> +++ b/board/ronetix/pm9263/mach-type.h
> @@ -0,0 +1,31 @@
> +/*
> + * This was manually generated from arch/arm/include/asm/mach-types.h
> + * and add this machine ID removed with commit
> + * 47af6f61bcd9fdd5dcf389cff0a7406eba756c6.
> + * Do fix this.
> + */
> +
> +#ifndef __ASM_ARM_MACH_TYPE_PM9263_H
> +#define __ASM_ARM_MACH_TYPE_PM9263_H
> +
> +#ifndef __ASSEMBLY__
> +/* The type of machine we're running on */
> +extern unsigned int __machine_arch_type;
> +#endif
> +
> +/* see arch/arm/kernel/arch.c for a description of these */
> +#define MACH_TYPE_PM9263 1475
> +
> +#ifdef CONFIG_MACH_PM9263
> +# ifdef machine_arch_type
> +# undef machine_arch_type
> +# define machine_arch_type __machine_arch_type
> +# else
> +# define machine_arch_type MACH_TYPE_PM9263
> +# endif
> +# define machine_is_pm9263() (machine_arch_type == MACH_TYPE_PM9263)
> +#else
> +# define machine_is_pm9263() (0)
> +#endif
> +
> +#endif
> diff --git a/board/ronetix/pm9263/pm9263.c b/board/ronetix/pm9263/pm9263.c
> index cfc9847..86a84b0 100644
> --- a/board/ronetix/pm9263/pm9263.c
> +++ b/board/ronetix/pm9263/pm9263.c
> @@ -25,6 +25,7 @@
> */
>
> #include <common.h>
> +#include "mach-type.h"
> #include <asm/sizes.h>
> #include <asm/io.h>
> #include <asm/arch/at91sam9_smc.h>
--
Regards,
Igor.
^ permalink raw reply
* [U-Boot] [PATCH] pm9g45: add mach-type localy for the board
From: Igor Grinberg @ 2011-10-31 8:59 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319818270-28002-1-git-send-email-dimov@ronetix.at>
Hi Asen,
Same comments as for pm9261, hold here.
On 10/28/11 18:11, Asen Chavdarov Dimov wrote:
>
> Signed-off-by: Asen Chavdarov Dimov <dimov@ronetix.at>
> ---
> board/ronetix/pm9g45/mach-type.h | 31 +++++++++++++++++++++++++++++++
> board/ronetix/pm9g45/pm9g45.c | 1 +
> 2 files changed, 32 insertions(+), 0 deletions(-)
> create mode 100644 board/ronetix/pm9g45/mach-type.h
>
> diff --git a/board/ronetix/pm9g45/mach-type.h b/board/ronetix/pm9g45/mach-type.h
> new file mode 100644
> index 0000000..3f8902f
> --- /dev/null
> +++ b/board/ronetix/pm9g45/mach-type.h
> @@ -0,0 +1,31 @@
> +/*
> + * This was manually generated from arch/arm/include/asm/mach-types.h
> + * and add this machine ID removed with commit
> + * 47af6f61bcd9fdd5dcf389cff0a7406eba756c6.
> + * Do fix this.
> + */
> +
> +#ifndef __ASM_ARM_MACH_TYPE_PM9G45_H
> +#define __ASM_ARM_MACH_TYPE_PM9G45_H
> +
> +#ifndef __ASSEMBLY__
> +/* The type of machine we're running on */
> +extern unsigned int __machine_arch_type;
> +#endif
> +
> +/* see arch/arm/kernel/arch.c for a description of these */
> +#define MACH_TYPE_PM9G45 2672
> +
> +#ifdef CONFIG_MACH_PM9G45
> +# ifdef machine_arch_type
> +# undef machine_arch_type
> +# define machine_arch_type __machine_arch_type
> +# else
> +# define machine_arch_type MACH_TYPE_PM9G45
> +# endif
> +# define machine_is_pm9g45() (machine_arch_type == MACH_TYPE_PM9G45)
> +#else
> +# define machine_is_pm9g45() (0)
> +#endif
> +
> +#endif
> diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c
> index f3374a4..9aff01a 100644
> --- a/board/ronetix/pm9g45/pm9g45.c
> +++ b/board/ronetix/pm9g45/pm9g45.c
> @@ -28,6 +28,7 @@
> */
>
> #include <common.h>
> +#include "mach-type.h"
> #include <asm/sizes.h>
> #include <asm/io.h>
> #include <asm/arch/at91sam9_smc.h>
--
Regards,
Igor.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ingo Molnar @ 2011-10-31 8:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFx1NGWfNJAKDTvZfsHDDKiEtS4t4RydSgHurBeyGPyhXg@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> That said, even the "BEGIN PGP SIGNED MESSAGE" things are a massive
> pain in the butt. We need to automate this some sane way, both for
> the sender and for the recipient.
The most practical form would be if Git supported such oneliner pull
requests:
git pull git://foo.com bar.branch \
--pull-sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \
--gpg-by: "Ingo Molnar <mingo@kernel.org>" \
--gpg-sig: 8a6f134afd1d212fe21345
maintainers could just paste them into a shell and it would abort if
it's not trusted. The maintainer verifies the visible, 'Ingo Molnar'
bit. The 8a6f134afd1d212fe21345 is a signed-by-Ingo-Molnar version of
this content:
git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4
And Git would verify that what ends up being pulled is indeed
0acf00014bcfd and also verifies that it was signed by me.
[ If we are extra diligent/paranoid then beyond the sha1 we might
even GPG sign the shortlog, or even the full raw log of all commits
leading to the sha1: this introduces some Git shortlog and patch
formatting version dependency though.
Git could also double check foo.com's DNS coherency, or check it
against a known-trusted whitelist of domain names specified in the
maintainer's .gitconfig, as an extra layer. ]
Doing it in this form would remove all the mail formatting madness -
one could paste such a pull request into a shell straight away, from
HTML email, from text email, from MIME email, etc.
In fact i would trust such a Git based solution far more than any
opaque, invisible tool that claims to have checked a signature with
cooperation of my mail client (ha!).
The only somewhat non-obvious bit is that Git should be *very*
careful about its key ID and signature parsing strategy, to protect
against social engineering attacks.
For example neither this:
--gpg-by: "Ingo Molnar <mingo@kernal.org>"
nor this:
--pgp-by: "Ingo Molnar <mingo@kernel.org>"
malicious pull request should slip through in any fashion:
- Git should only use keys that are in your ring of trust - not pull
keys from the public keyring automatically and just check
coherency of the pull request or such. [I'm sure people will be
tempted to have such a feature - but that temptation should be
resisted.]
- Git should abort the moment it sees an unknown option
Thanks,
Ingo
^ permalink raw reply
* Re: Question about mdadm commit d6508f0cfb60edf07b36f1532eae4d9cddf7178b "be more careful about add attempts"
From: Alexander Lyakas @ 2011-10-31 8:57 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20111031101649.657a1ab3@notabene.brown>
Thank you for the clarification, Neil!
I was looking at raid_disk, because I am trying to see whether it is
possible to control into which raid slot a disk is being added (not
re-added).
Let's say we had raid6 with 4 drives (a,b,c,d), and drives c and d
failed.Now let's say, that it is decided to replace drive d with a new
drive e (--add for drive e). Then it's possible that drive e will take
the raid slot of drive c. So later, if we want to bring back drive c
into the array, it will have to go into a different slot, resulting in
a full reconstruction, not bitmap-based reconstruction. While if we
would have re-added drive c first, it would have done a bitmap-based
reconstruction, so only the e drive would have required a full
reconstruction.
So do you think it makes sense to somehow (perhaps through
disc.raid_disk) instruct the kernel into which slot to add a new
drive?
Thanks,
Alex.
On Mon, Oct 31, 2011 at 1:16 AM, NeilBrown <neilb@suse.de> wrote:
> On Thu, 27 Oct 2011 11:10:54 +0200 Alexander Lyakas <alex.bolshoy@gmail.com>
> wrote:
>
>> Hello Neil,
>> it makes perfect sense not to turn a device into a spare inadvertently.
>>
>> However, with mdadm 3.1.4 under gdb, I tried the following:
>> - I had a raid6 with 4 drives (sda/b/c/d), their "desc_nr" in the
>> kernel were respectively (according to GET_DISK_INFO): 0,1,2,3.
>> - I failed the two last drives (c & d) via mdadm and removed them from the array
>> - I wiped the superblock on drive d.
>> - I added the drive d back to the array
>> So now the array had the following setup:
>> sda: disc_nr=0, raid_disk=0
>> sdb: disc_nr=1, raid_disk=1
>> sdd: disc_nr=4, raid_disk=2
>> So sdd was added to the array into slot 2, and received disc_nr=4
>>
>> - Now I asked to re-add drive sdc back to array. In gdb I followed the
>> re-add flow, to the place where it fills the mdu_disk_info_t structure
>> from the superblock read from sdc. It put there the following content:
>> disc.major = ...
>> disc.minor = ...
>> disc.number = 2
>> disc.raid_disk = 2 (because previously this drive was in slot 2)
>> disc.state = ...
>>
>> Now in gdb I changed disc.number to 4 (to match the desc_nr of sdd).
>> And then issued ADD_NEW_DISK. It succeeded, and the sdc drive received
>> disc_nr=2 (while it was asking for 4). Of course, it could not have
>> received the same raid_disk, because this raid_disk was already
>> occupied by sdd. So it was added as a spare.
>>
>> But you are saying:
>> > If a device already exists with the same disk.number, a re-add cannot
>> > succeed, so mdadm doesn't even try.
>> while in my case it succeeded (while it actually did "add" and not "re-add").
>
> We seem to be using word differently.
> If I ask mdadm to do a "re-add" and it does an "add", then I consider that to
> be "failure", however you seem to consider it to be a "success".
>
> That seems to be the source of confusion.
>
>
>>
>> That's why I was thinking it makes more sense to check disc.raid_disk
>> and not disc.number in this check. Since disc.number is not the
>> drive's role within the array (right?), it is simply a position of the
>> drive in the list of all drives.
>> So if you check raid_disk, and see that this raid slot is already
>> occupied, then, naturally, the drive will be converted to spare, which
>> we want to avoid.
>
> It may well be appropriate to check raid_disk as well, yes. It isn't so easy
> though which is maybe why I didn't.
>
> With 0.90 metadata, the disc.number is the same as disc.raid_disk for active
> devices. That might be another reason for the code being the way that it is.
>
> Thanks,
> NeilBrown
>
>
>
>>
>> And the enough_fd() check protects us from adding a spare to a failed
>> array (like you mentioned to me previously).
>>
>> What am I missing?
>>
>> Thanks,
>> Alex.
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Oct 26, 2011 at 11:51 PM, NeilBrown <neilb@suse.de> wrote:
>> > On Wed, 26 Oct 2011 19:02:37 +0200 Alexander Lyakas <alex.bolshoy@gmail.com>
>> > wrote:
>> >
>> >> Greetings everybody,
>> >> I have a question about the following code in Manage.c:Manage_subdevs()
>> >>
>> >> disc.number = mdi.disk.number;
>> >> if (ioctl(fd, GET_DISK_INFO, &disc) != 0
>> >> || disc.major != 0 || disc.minor != 0
>> >> || !enough_fd(fd))
>> >> goto skip_re_add;
>> >>
>> >> I do not underatand why the checks: disc.major != 0 || disc.minor != 0
>> >> are required. This basically means that the kernel already has an
>> >> rdev->desc_nr equal to disc.number. But why fail the re-add procedure?
>> >>
>> >> Let's say that enough_fd() returns true, and we go ahead an issue
>> >> ioctl(ADD_NEW_DISK). In this case, according to the kernel code in
>> >> add_new_disk(), it will not even look at info->number. It will
>> >> initialize rdev->desc_nr to -1, and will allocate a free desc_nr for
>> >> the rdev later.
>> >>
>> >> Doing this with mdadm 3.1.4, where this check is not present, actually
>> >> succeeds. I understand that this code was added for cases when
>> >> enough_fd() returns false, which sounds perfectly fine to protect
>> >> from.
>> >>
>> >> I was thinking that this code should actually check something like:
>> >> if (ioctl(fd, GET_DISK_INFO, &disc) != 0
>> >> || disk.raid_disk != mdi.disk.raid_disk
>> >> || !enough_fd(fd))
>> >> goto skip_re_add;
>> >>
>> >> That is to check that the slot that was being occupied by the drive we
>> >> are trying to add, is already occupied by a different drive (need also
>> >> to cover cases of raid_disk <0, raid_disk >= raid_disks etc...) and
>> >> not the desc_nr, which does not have any persistent meaning.
>> >>
>> >> Perhaps there are some compatibility issues with old kernels? Or
>> >> special considerations for ... containers? non-persistent arrays?
>> >
>> > The point of this code is to make --re-add fail unless mdadm is certain that
>> > the kernel will accept the re-add, rather than turn the device into a spare.
>> >
>> > If a device already exists with the same disk.number, a re-add cannot
>> > succeed, so mdadm doesn't even try.
>> >
>> > When you say in 3.1.4 it "actually succeeds" - what succeeds? Does it re-add
>> > the device to the array, or does it turn the device into a spare?
>> > I particularly do not want --re-add to turn a device into a spare because
>> > people sometimes use it in cases where it cannot work, their device gets
>> > turned into a spare, and they lose information that could have been used to
>> > reconstruct the array.
>> >
>> > That that make sense?
>> >
>> > NeilBrown
>> >
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [U-Boot] [PATCH 1/2] nand_spl_simple: Add omap3 DMA usage to SPL
From: Simon Schwarz @ 2011-10-31 8:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA6FEF9.6070208@freescale.com>
Dear Scott,
On 10/25/2011 08:24 PM, Scott Wood wrote:
> On 10/16/2011 05:10 AM, Simon Schwarz wrote:
>> This adds DMA copy for the nand spl implementation. If CONFIG_SPL_DMA_SUPPORT
>> is defined the DMA is used.
>>
>> Based on DMA driver patch:
>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/109744/focus=109747
>
> As Wolfgang pointed out, this doesn't belong here. Create your own
> alternate SPL driver if your hardware doesn't work with the simple one
> (similar to the not-yet-migrated nand_spl/nand_boot_fsl_elbc.c,
> nand_spl/nand_boot_fsl_ifc.c, etc).
>
Hm. The naming of the functions was a fault. Will rename the calls in
nand_spl_simple to remove omap parts. So
omap3_dma_wait_for_transfer
will become
dma_wait_for_transfer
etc.
So a board which intents to use DMA in SPL can implement these
functions. Would this be ok?
A whole new driver is IMHO not the right thing as there is too much
duplicated code then.
>> @@ -46,11 +59,11 @@ static int nand_command(int block, int page, uint32_t offs,
>> this->cmd_ctrl(&mtd, offs, NAND_CTRL_ALE | NAND_CTRL_CHANGE);
>> this->cmd_ctrl(&mtd, page_addr& 0xff, NAND_CTRL_ALE); /* A[16:9] */
>> this->cmd_ctrl(&mtd, (page_addr>> 8)& 0xff,
>> - NAND_CTRL_ALE); /* A[24:17] */
>> + NAND_CTRL_ALE); /* A[24:17] */
>> #ifdef CONFIG_SYS_NAND_4_ADDR_CYCLE
>> /* One more address cycle for devices> 32MiB */
>> this->cmd_ctrl(&mtd, (page_addr>> 16)& 0x0f,
>> - NAND_CTRL_ALE); /* A[28:25] */
>> + NAND_CTRL_ALE); /* A[28:25] */
>> #endif
>
> Please refrain from making random unrelated whitespace changes in a
> patch that also makes functional changes, particularly when they are
> extensive enough to make it hard to spot the functional changes.
>
> In this particular case, I think the whitespace was fine the way it was;
> the continuation lines were nicely aligned.
If I remember right I changed these because of checkpatch errors.
Regards
Simon
^ permalink raw reply
* Re: [PATCH] Fix a typo in line 117 of git-gui/lib/sshkeys.tcl.
From: Pat Thoyts @ 2011-10-31 8:56 UTC (permalink / raw)
To: kusmabite; +Cc: Dejan Ribič, Git ML
In-Reply-To: <CABPQNSaLsS9P8hWMEBYVe4FEo5x11+J+pMw29NN+EF2siCO35w@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
>Thanks for re-posting inline and with a sign-off. But there's still a
>few minor nits:
>
>2011/10/30 Dejan Ribič <dejan.ribic@gmail.com>:
>> "succeded" changed to "succeeded".
>
>We write commit messages in imperative mood, so this should be
>something like 'change "succeded" to "succeeded"' instead. This is
>documented in Documentation/SubmittingPatches.
>
>> modified: git-gui/lib/sshkey.tcl
>
>We don't normally include a list of changed files in the commit
>message; the diffstat already provides that information.
>
The change is fine so I've applied this to the git-gui repository with a
fixed commit message. Thank you.
git-gui is hosted separately and merged into git-core at intervals so
the development version of git-gui is in fact hosted at
git://repo.or.cz/git-gui.git although patches against the git-core
version seldom pose a problem to apply and are gratefully received.
(git am -p2 usually fixes them).
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [patch v2] [ALSA] hwdep: silence integer overflow warning
From: Takashi Iwai @ 2011-10-31 8:55 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Paul Gortmaker, alsa-devel, kernel-janitors, walter harms
In-Reply-To: <20111028064601.GB14707@longonot.mountain>
At Fri, 28 Oct 2011 09:46:01 +0300,
Dan Carpenter wrote:
>
> Smatch complains that if device is INT_MAX then device + 1 can
> overflow. It just means we would have an annoying loop while we
> check all the devices from -2147483648 to SNDRV_MINOR_HWDEPS.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied now. Thanks!
Takashi
> ---
> v2: reshuffled it a bit per Walter Harms's suggestion.
>
> diff --git a/sound/core/hwdep.c b/sound/core/hwdep.c
> index c7ceb28..75ea16f 100644
> --- a/sound/core/hwdep.c
> +++ b/sound/core/hwdep.c
> @@ -273,7 +273,14 @@ static int snd_hwdep_control_ioctl(struct snd_card *card,
> if (get_user(device, (int __user *)arg))
> return -EFAULT;
> mutex_lock(®ister_mutex);
> - device = device < 0 ? 0 : device + 1;
> +
> + if (device < 0)
> + device = 0;
> + else if (device < SNDRV_MINOR_HWDEPS)
> + device++;
> + else
> + device = SNDRV_MINOR_HWDEPS;
> +
> while (device < SNDRV_MINOR_HWDEPS) {
> if (snd_hwdep_search(card, device))
> break;
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: [alsa-devel] [patch v2] [ALSA] hwdep: silence integer overflow warning
From: Takashi Iwai @ 2011-10-31 8:55 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Paul Gortmaker, alsa-devel, kernel-janitors, walter harms
In-Reply-To: <20111028064601.GB14707@longonot.mountain>
At Fri, 28 Oct 2011 09:46:01 +0300,
Dan Carpenter wrote:
>
> Smatch complains that if device is INT_MAX then device + 1 can
> overflow. It just means we would have an annoying loop while we
> check all the devices from -2147483648 to SNDRV_MINOR_HWDEPS.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied now. Thanks!
Takashi
> ---
> v2: reshuffled it a bit per Walter Harms's suggestion.
>
> diff --git a/sound/core/hwdep.c b/sound/core/hwdep.c
> index c7ceb28..75ea16f 100644
> --- a/sound/core/hwdep.c
> +++ b/sound/core/hwdep.c
> @@ -273,7 +273,14 @@ static int snd_hwdep_control_ioctl(struct snd_card *card,
> if (get_user(device, (int __user *)arg))
> return -EFAULT;
> mutex_lock(®ister_mutex);
> - device = device < 0 ? 0 : device + 1;
> +
> + if (device < 0)
> + device = 0;
> + else if (device < SNDRV_MINOR_HWDEPS)
> + device++;
> + else
> + device = SNDRV_MINOR_HWDEPS;
> +
> while (device < SNDRV_MINOR_HWDEPS) {
> if (snd_hwdep_search(card, device))
> break;
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: [patch 5/5]thp: split huge page if head page is isolated
From: Shaohua Li @ 2011-10-31 9:03 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, aarcange@redhat.com, Hugh Dickins, Rik van Riel,
mel, KAMEZAWA Hiroyuki, linux-mm, lkml
In-Reply-To: <20111031082317.GA21440@barrios-laptop.redhat.com>
On Mon, 2011-10-31 at 16:23 +0800, Minchan Kim wrote:
> On Mon, Oct 31, 2011 at 09:21:28AM +0800, Shaohua Li wrote:
> > On Sat, 2011-10-29 at 08:06 +0800, Minchan Kim wrote:
> > > On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > > > With current logic, if page reclaim finds a huge page, it will just reclaim
> > > > the head page and leave tail pages reclaimed later. Let's take an example,
> > > > lru list has page A and B, page A is huge page:
> > > > 1. page A is isolated
> > > > 2. page B is isolated
> > > > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > > > page A+1, page A+2, ... are added to lru list.
> > > > 4. shrink_page_list() adds page B to swap page cache.
> > > > 5. page A and B is written out and reclaimed.
> > > > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > > > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> > > >
> > > > We expected the whole huge page A is reclaimed in the meantime, so
> > > > the order is A, A+1, ... A+HPAGE_PMD_NR-1, B, ....
> > > >
> > > > With this patch, we do huge page split just after the head page is isolated
> > > > for inactive lru list, so the tail pages will be reclaimed immediately.
> > > >
> > > > In a test, a range of anonymous memory is written and will trigger swap.
> > > > Without the patch:
> > > > #cat /proc/vmstat|grep thp
> > > > thp_fault_alloc 451
> > > > thp_fault_fallback 0
> > > > thp_collapse_alloc 0
> > > > thp_collapse_alloc_failed 0
> > > > thp_split 238
> > > >
> > > > With the patch:
> > > > #cat /proc/vmstat|grep thp
> > > > thp_fault_alloc 450
> > > > thp_fault_fallback 1
> > > > thp_collapse_alloc 0
> > > > thp_collapse_alloc_failed 0
> > > > thp_split 103
> > > >
> > > > So the thp_split number is reduced a lot, though there is one extra
> > > > thp_fault_fallback.
> > > >
> > > > Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> > > > ---
> > > > include/linux/memcontrol.h | 3 +-
> > > > mm/memcontrol.c | 12 +++++++++--
> > > > mm/vmscan.c | 49 ++++++++++++++++++++++++++++++++++-----------
> > > > 3 files changed, 50 insertions(+), 14 deletions(-)
> > > >
> > > > Index: linux/mm/vmscan.c
> > > > ===================================================================
> > > > --- linux.orig/mm/vmscan.c 2011-10-25 08:36:08.000000000 +0800
> > > > +++ linux/mm/vmscan.c 2011-10-25 09:51:44.000000000 +0800
> > > > @@ -1076,7 +1076,8 @@ int __isolate_lru_page(struct page *page
> > > > */
> > > > static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> > > > struct list_head *src, struct list_head *dst,
> > > > - unsigned long *scanned, int order, int mode, int file)
> > > > + unsigned long *scanned, int order, int mode, int file,
> > > > + struct page **split_page)
> > > > {
> > > > unsigned long nr_taken = 0;
> > > > unsigned long nr_lumpy_taken = 0;
> > > > @@ -1100,7 +1101,12 @@ static unsigned long isolate_lru_pages(u
> > > > case 0:
> > > > list_move(&page->lru, dst);
> > > > mem_cgroup_del_lru(page);
> > > > - nr_taken += hpage_nr_pages(page);
> > > > + if (PageTransHuge(page) && split_page) {
> > > > + nr_taken++;
> > > > + *split_page = page;
> > > > + goto out;
> > > > + } else
> > > > + nr_taken += hpage_nr_pages(page);
> > > > break;
> > > >
> > > > case -EBUSY:
> > > > @@ -1158,11 +1164,16 @@ static unsigned long isolate_lru_pages(u
> > > > if (__isolate_lru_page(cursor_page, mode, file) == 0) {
> > > > list_move(&cursor_page->lru, dst);
> > > > mem_cgroup_del_lru(cursor_page);
> > > > - nr_taken += hpage_nr_pages(page);
> > > > nr_lumpy_taken++;
> > > > if (PageDirty(cursor_page))
> > > > nr_lumpy_dirty++;
> > > > scan++;
> > > > + if (PageTransHuge(page) && split_page) {
> > > > + nr_taken++;
> > > > + *split_page = page;
> > > > + goto out;
> > > > + } else
> > > > + nr_taken += hpage_nr_pages(page);
> > > > } else {
> > > > /*
> > > > * Check if the page is freed already.
> > > > @@ -1188,6 +1199,7 @@ static unsigned long isolate_lru_pages(u
> > > > nr_lumpy_failed++;
> > > > }
> > > >
> > > > +out:
> > > > *scanned = scan;
> > > >
> > > > trace_mm_vmscan_lru_isolate(order,
> > > > @@ -1202,7 +1214,8 @@ static unsigned long isolate_pages_globa
> > > > struct list_head *dst,
> > > > unsigned long *scanned, int order,
> > > > int mode, struct zone *z,
> > > > - int active, int file)
> > > > + int active, int file,
> > > > + struct page **split_page)
> > > > {
> > > > int lru = LRU_BASE;
> > > > if (active)
> > > > @@ -1210,7 +1223,7 @@ static unsigned long isolate_pages_globa
> > > > if (file)
> > > > lru += LRU_FILE;
> > > > return isolate_lru_pages(nr, &z->lru[lru].list, dst, scanned, order,
> > > > - mode, file);
> > > > + mode, file, split_page);
> > > > }
> > > >
> > > > /*
> > > > @@ -1444,10 +1457,12 @@ shrink_inactive_list(unsigned long nr_to
> > > > {
> > > > LIST_HEAD(page_list);
> > > > unsigned long nr_scanned;
> > > > + unsigned long total_scanned = 0;
> > > > unsigned long nr_reclaimed = 0;
> > > > unsigned long nr_taken;
> > > > unsigned long nr_anon;
> > > > unsigned long nr_file;
> > > > + struct page *split_page;
> > > >
> > > > while (unlikely(too_many_isolated(zone, file, sc))) {
> > > > congestion_wait(BLK_RW_ASYNC, HZ/10);
> > > > @@ -1458,16 +1473,19 @@ shrink_inactive_list(unsigned long nr_to
> > > > }
> > > >
> > > > set_reclaim_mode(priority, sc, false);
> > > > +again:
> > > > lru_add_drain();
> > > > + split_page = NULL;
> > > > spin_lock_irq(&zone->lru_lock);
> > > >
> > > > if (scanning_global_lru(sc)) {
> > > > - nr_taken = isolate_pages_global(nr_to_scan,
> > > > + nr_taken = isolate_pages_global(nr_to_scan - total_scanned,
> > > > &page_list, &nr_scanned, sc->order,
> > > > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > > > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > > > - zone, 0, file);
> > > > + zone, 0, file, &split_page);
> > > > zone->pages_scanned += nr_scanned;
> > > > + total_scanned += nr_scanned;
> > > > if (current_is_kswapd())
> > > > __count_zone_vm_events(PGSCAN_KSWAPD, zone,
> > > > nr_scanned);
> > > > @@ -1475,12 +1493,13 @@ shrink_inactive_list(unsigned long nr_to
> > > > __count_zone_vm_events(PGSCAN_DIRECT, zone,
> > > > nr_scanned);
> > > > } else {
> > > > - nr_taken = mem_cgroup_isolate_pages(nr_to_scan,
> > > > + nr_taken = mem_cgroup_isolate_pages(nr_to_scan - total_scanned,
> > > > &page_list, &nr_scanned, sc->order,
> > > > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > > > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > > > zone, sc->mem_cgroup,
> > > > - 0, file);
> > > > + 0, file, &split_page);
> > > > + total_scanned += nr_scanned;
> > > > /*
> > > > * mem_cgroup_isolate_pages() keeps track of
> > > > * scanned pages on its own.
> > > > @@ -1491,11 +1510,19 @@ shrink_inactive_list(unsigned long nr_to
> > > > spin_unlock_irq(&zone->lru_lock);
> > > > return 0;
> > > > }
> > > > + if (split_page && total_scanned < nr_to_scan) {
> > > > + spin_unlock_irq(&zone->lru_lock);
> > > > + split_huge_page(split_page);
> > > > + goto again;
> > > > + }
> > > >
> > > > update_isolated_counts(zone, sc, &nr_anon, &nr_file, &page_list);
> > > >
> > > > spin_unlock_irq(&zone->lru_lock);
> > > >
> > > > + if (split_page)
> > > > + split_huge_page(split_page);
> > > > +
> > > > nr_reclaimed = shrink_page_list(&page_list, zone, sc);
> > > >
> > > > /* Check if we should syncronously wait for writeback */
> > > > @@ -1589,13 +1616,13 @@ static void shrink_active_list(unsigned
> > > > nr_taken = isolate_pages_global(nr_pages, &l_hold,
> > > > &pgscanned, sc->order,
> > > > ISOLATE_ACTIVE, zone,
> > > > - 1, file);
> > > > + 1, file, NULL);
> > > > zone->pages_scanned += pgscanned;
> > > > } else {
> > > > nr_taken = mem_cgroup_isolate_pages(nr_pages, &l_hold,
> > > > &pgscanned, sc->order,
> > > > ISOLATE_ACTIVE, zone,
> > > > - sc->mem_cgroup, 1, file);
> > > > + sc->mem_cgroup, 1, file, NULL);
> > > > /*
> > > > * mem_cgroup_isolate_pages() keeps track of
> > > > * scanned pages on its own.
> > > > Index: linux/mm/memcontrol.c
> > > > ===================================================================
> > > > --- linux.orig/mm/memcontrol.c 2011-10-25 08:36:08.000000000 +0800
> > > > +++ linux/mm/memcontrol.c 2011-10-25 09:33:51.000000000 +0800
> > > > @@ -1187,7 +1187,8 @@ unsigned long mem_cgroup_isolate_pages(u
> > > > unsigned long *scanned, int order,
> > > > int mode, struct zone *z,
> > > > struct mem_cgroup *mem_cont,
> > > > - int active, int file)
> > > > + int active, int file,
> > > > + struct page **split_page)
> > > > {
> > > > unsigned long nr_taken = 0;
> > > > struct page *page;
> > > > @@ -1224,7 +1225,13 @@ unsigned long mem_cgroup_isolate_pages(u
> > > > case 0:
> > > > list_move(&page->lru, dst);
> > > > mem_cgroup_del_lru(page);
> > > > - nr_taken += hpage_nr_pages(page);
> > > > + if (PageTransHuge(page) && split_page) {
> > > > + nr_taken++;
> > > > + *split_page = page;
> > > > + goto out;
> > > > + } else
> > > > + nr_taken += hpage_nr_pages(page);
> > > > +
> > > > break;
> > > > case -EBUSY:
> > > > /* we don't affect global LRU but rotate in our LRU */
> > > > @@ -1235,6 +1242,7 @@ unsigned long mem_cgroup_isolate_pages(u
> > > > }
> > > > }
> > > >
> > > > +out:
> > > > *scanned = scan;
> > > >
> > > > trace_mm_vmscan_memcg_isolate(0, nr_to_scan, scan, nr_taken,
> > > > Index: linux/include/linux/memcontrol.h
> > > > ===================================================================
> > > > --- linux.orig/include/linux/memcontrol.h 2011-10-25 08:36:08.000000000 +0800
> > > > +++ linux/include/linux/memcontrol.h 2011-10-25 09:33:51.000000000 +0800
> > > > @@ -37,7 +37,8 @@ extern unsigned long mem_cgroup_isolate_
> > > > unsigned long *scanned, int order,
> > > > int mode, struct zone *z,
> > > > struct mem_cgroup *mem_cont,
> > > > - int active, int file);
> > > > + int active, int file,
> > > > + struct page **split_page);
> > > >
> > > > #ifdef CONFIG_CGROUP_MEM_RES_CTLR
> > > > /*
> > > >
> > > >
> > >
> > > I saw the code. my concern is your patch could make unnecessary split of THP.
> > >
> > > When we isolates page, we can't know whether it's working set or not.
> > > So split should happen after we judge it's working set page.
> > yes, but since memory is big currently, it's unlikely the isolated page
> > get accessed in the window. And I only did the split in
>
> We don't check page_reference when isolate happens.
> Window which between isolation time and reclaim?
> No. Window is from inactive's head to tail and it's the basic concept of
> our LRU.
>
> > shrink_inactive_list, not in active list.
>
> But inactive list's size could be still big and
> page reference heuristic is very important for reclaim algorithm.
I mean pages aren't referenced. but ok, I can't take such assumption.
> > And THP has mechanism to collapse small pages to huge page later.
>
> You mean "merge" instead of "collapse"?
>
> >
> > > If you really want to merge this patch, I suggest that
> > > we can handle it in shrink_page_list step, not isolation step.
> > >
> > > My totally untested code which is just to show the concept is as follows,
> > I did consider this option before. It has its problem too. The isolation
> > can isolate several huge page one time. And then later shrink_page_list
> > can swap several huge page one time, which is unfortunate. I'm pretty
> > sure this method can't reduce the thp_split count in my test. It could
>
> I understand your point but approach isn't good to me.
> Maybe we can check whether we are going on or not before other THP page split happens
> in shrink_page_list. If we split THP page successfully, maybe we can skip another THP split.
> Another idea is we can avoid split of THP unless high order reclaim happens or low order
> high priority pressure happens.
I agreed the split better be done at shrink_page_list, but we must avoid
isolate too many pages. I'll check if I can have a better solution for
next post.
Thanks,
Shaohua
^ permalink raw reply
* Re: [patch 5/5]thp: split huge page if head page is isolated
From: Shaohua Li @ 2011-10-31 9:03 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, aarcange@redhat.com, Hugh Dickins, Rik van Riel,
mel, KAMEZAWA Hiroyuki, linux-mm, lkml
In-Reply-To: <20111031082317.GA21440@barrios-laptop.redhat.com>
On Mon, 2011-10-31 at 16:23 +0800, Minchan Kim wrote:
> On Mon, Oct 31, 2011 at 09:21:28AM +0800, Shaohua Li wrote:
> > On Sat, 2011-10-29 at 08:06 +0800, Minchan Kim wrote:
> > > On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > > > With current logic, if page reclaim finds a huge page, it will just reclaim
> > > > the head page and leave tail pages reclaimed later. Let's take an example,
> > > > lru list has page A and B, page A is huge page:
> > > > 1. page A is isolated
> > > > 2. page B is isolated
> > > > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > > > page A+1, page A+2, ... are added to lru list.
> > > > 4. shrink_page_list() adds page B to swap page cache.
> > > > 5. page A and B is written out and reclaimed.
> > > > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > > > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> > > >
> > > > We expected the whole huge page A is reclaimed in the meantime, so
> > > > the order is A, A+1, ... A+HPAGE_PMD_NR-1, B, ....
> > > >
> > > > With this patch, we do huge page split just after the head page is isolated
> > > > for inactive lru list, so the tail pages will be reclaimed immediately.
> > > >
> > > > In a test, a range of anonymous memory is written and will trigger swap.
> > > > Without the patch:
> > > > #cat /proc/vmstat|grep thp
> > > > thp_fault_alloc 451
> > > > thp_fault_fallback 0
> > > > thp_collapse_alloc 0
> > > > thp_collapse_alloc_failed 0
> > > > thp_split 238
> > > >
> > > > With the patch:
> > > > #cat /proc/vmstat|grep thp
> > > > thp_fault_alloc 450
> > > > thp_fault_fallback 1
> > > > thp_collapse_alloc 0
> > > > thp_collapse_alloc_failed 0
> > > > thp_split 103
> > > >
> > > > So the thp_split number is reduced a lot, though there is one extra
> > > > thp_fault_fallback.
> > > >
> > > > Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> > > > ---
> > > > include/linux/memcontrol.h | 3 +-
> > > > mm/memcontrol.c | 12 +++++++++--
> > > > mm/vmscan.c | 49 ++++++++++++++++++++++++++++++++++-----------
> > > > 3 files changed, 50 insertions(+), 14 deletions(-)
> > > >
> > > > Index: linux/mm/vmscan.c
> > > > ===================================================================
> > > > --- linux.orig/mm/vmscan.c 2011-10-25 08:36:08.000000000 +0800
> > > > +++ linux/mm/vmscan.c 2011-10-25 09:51:44.000000000 +0800
> > > > @@ -1076,7 +1076,8 @@ int __isolate_lru_page(struct page *page
> > > > */
> > > > static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> > > > struct list_head *src, struct list_head *dst,
> > > > - unsigned long *scanned, int order, int mode, int file)
> > > > + unsigned long *scanned, int order, int mode, int file,
> > > > + struct page **split_page)
> > > > {
> > > > unsigned long nr_taken = 0;
> > > > unsigned long nr_lumpy_taken = 0;
> > > > @@ -1100,7 +1101,12 @@ static unsigned long isolate_lru_pages(u
> > > > case 0:
> > > > list_move(&page->lru, dst);
> > > > mem_cgroup_del_lru(page);
> > > > - nr_taken += hpage_nr_pages(page);
> > > > + if (PageTransHuge(page) && split_page) {
> > > > + nr_taken++;
> > > > + *split_page = page;
> > > > + goto out;
> > > > + } else
> > > > + nr_taken += hpage_nr_pages(page);
> > > > break;
> > > >
> > > > case -EBUSY:
> > > > @@ -1158,11 +1164,16 @@ static unsigned long isolate_lru_pages(u
> > > > if (__isolate_lru_page(cursor_page, mode, file) == 0) {
> > > > list_move(&cursor_page->lru, dst);
> > > > mem_cgroup_del_lru(cursor_page);
> > > > - nr_taken += hpage_nr_pages(page);
> > > > nr_lumpy_taken++;
> > > > if (PageDirty(cursor_page))
> > > > nr_lumpy_dirty++;
> > > > scan++;
> > > > + if (PageTransHuge(page) && split_page) {
> > > > + nr_taken++;
> > > > + *split_page = page;
> > > > + goto out;
> > > > + } else
> > > > + nr_taken += hpage_nr_pages(page);
> > > > } else {
> > > > /*
> > > > * Check if the page is freed already.
> > > > @@ -1188,6 +1199,7 @@ static unsigned long isolate_lru_pages(u
> > > > nr_lumpy_failed++;
> > > > }
> > > >
> > > > +out:
> > > > *scanned = scan;
> > > >
> > > > trace_mm_vmscan_lru_isolate(order,
> > > > @@ -1202,7 +1214,8 @@ static unsigned long isolate_pages_globa
> > > > struct list_head *dst,
> > > > unsigned long *scanned, int order,
> > > > int mode, struct zone *z,
> > > > - int active, int file)
> > > > + int active, int file,
> > > > + struct page **split_page)
> > > > {
> > > > int lru = LRU_BASE;
> > > > if (active)
> > > > @@ -1210,7 +1223,7 @@ static unsigned long isolate_pages_globa
> > > > if (file)
> > > > lru += LRU_FILE;
> > > > return isolate_lru_pages(nr, &z->lru[lru].list, dst, scanned, order,
> > > > - mode, file);
> > > > + mode, file, split_page);
> > > > }
> > > >
> > > > /*
> > > > @@ -1444,10 +1457,12 @@ shrink_inactive_list(unsigned long nr_to
> > > > {
> > > > LIST_HEAD(page_list);
> > > > unsigned long nr_scanned;
> > > > + unsigned long total_scanned = 0;
> > > > unsigned long nr_reclaimed = 0;
> > > > unsigned long nr_taken;
> > > > unsigned long nr_anon;
> > > > unsigned long nr_file;
> > > > + struct page *split_page;
> > > >
> > > > while (unlikely(too_many_isolated(zone, file, sc))) {
> > > > congestion_wait(BLK_RW_ASYNC, HZ/10);
> > > > @@ -1458,16 +1473,19 @@ shrink_inactive_list(unsigned long nr_to
> > > > }
> > > >
> > > > set_reclaim_mode(priority, sc, false);
> > > > +again:
> > > > lru_add_drain();
> > > > + split_page = NULL;
> > > > spin_lock_irq(&zone->lru_lock);
> > > >
> > > > if (scanning_global_lru(sc)) {
> > > > - nr_taken = isolate_pages_global(nr_to_scan,
> > > > + nr_taken = isolate_pages_global(nr_to_scan - total_scanned,
> > > > &page_list, &nr_scanned, sc->order,
> > > > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > > > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > > > - zone, 0, file);
> > > > + zone, 0, file, &split_page);
> > > > zone->pages_scanned += nr_scanned;
> > > > + total_scanned += nr_scanned;
> > > > if (current_is_kswapd())
> > > > __count_zone_vm_events(PGSCAN_KSWAPD, zone,
> > > > nr_scanned);
> > > > @@ -1475,12 +1493,13 @@ shrink_inactive_list(unsigned long nr_to
> > > > __count_zone_vm_events(PGSCAN_DIRECT, zone,
> > > > nr_scanned);
> > > > } else {
> > > > - nr_taken = mem_cgroup_isolate_pages(nr_to_scan,
> > > > + nr_taken = mem_cgroup_isolate_pages(nr_to_scan - total_scanned,
> > > > &page_list, &nr_scanned, sc->order,
> > > > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > > > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > > > zone, sc->mem_cgroup,
> > > > - 0, file);
> > > > + 0, file, &split_page);
> > > > + total_scanned += nr_scanned;
> > > > /*
> > > > * mem_cgroup_isolate_pages() keeps track of
> > > > * scanned pages on its own.
> > > > @@ -1491,11 +1510,19 @@ shrink_inactive_list(unsigned long nr_to
> > > > spin_unlock_irq(&zone->lru_lock);
> > > > return 0;
> > > > }
> > > > + if (split_page && total_scanned < nr_to_scan) {
> > > > + spin_unlock_irq(&zone->lru_lock);
> > > > + split_huge_page(split_page);
> > > > + goto again;
> > > > + }
> > > >
> > > > update_isolated_counts(zone, sc, &nr_anon, &nr_file, &page_list);
> > > >
> > > > spin_unlock_irq(&zone->lru_lock);
> > > >
> > > > + if (split_page)
> > > > + split_huge_page(split_page);
> > > > +
> > > > nr_reclaimed = shrink_page_list(&page_list, zone, sc);
> > > >
> > > > /* Check if we should syncronously wait for writeback */
> > > > @@ -1589,13 +1616,13 @@ static void shrink_active_list(unsigned
> > > > nr_taken = isolate_pages_global(nr_pages, &l_hold,
> > > > &pgscanned, sc->order,
> > > > ISOLATE_ACTIVE, zone,
> > > > - 1, file);
> > > > + 1, file, NULL);
> > > > zone->pages_scanned += pgscanned;
> > > > } else {
> > > > nr_taken = mem_cgroup_isolate_pages(nr_pages, &l_hold,
> > > > &pgscanned, sc->order,
> > > > ISOLATE_ACTIVE, zone,
> > > > - sc->mem_cgroup, 1, file);
> > > > + sc->mem_cgroup, 1, file, NULL);
> > > > /*
> > > > * mem_cgroup_isolate_pages() keeps track of
> > > > * scanned pages on its own.
> > > > Index: linux/mm/memcontrol.c
> > > > ===================================================================
> > > > --- linux.orig/mm/memcontrol.c 2011-10-25 08:36:08.000000000 +0800
> > > > +++ linux/mm/memcontrol.c 2011-10-25 09:33:51.000000000 +0800
> > > > @@ -1187,7 +1187,8 @@ unsigned long mem_cgroup_isolate_pages(u
> > > > unsigned long *scanned, int order,
> > > > int mode, struct zone *z,
> > > > struct mem_cgroup *mem_cont,
> > > > - int active, int file)
> > > > + int active, int file,
> > > > + struct page **split_page)
> > > > {
> > > > unsigned long nr_taken = 0;
> > > > struct page *page;
> > > > @@ -1224,7 +1225,13 @@ unsigned long mem_cgroup_isolate_pages(u
> > > > case 0:
> > > > list_move(&page->lru, dst);
> > > > mem_cgroup_del_lru(page);
> > > > - nr_taken += hpage_nr_pages(page);
> > > > + if (PageTransHuge(page) && split_page) {
> > > > + nr_taken++;
> > > > + *split_page = page;
> > > > + goto out;
> > > > + } else
> > > > + nr_taken += hpage_nr_pages(page);
> > > > +
> > > > break;
> > > > case -EBUSY:
> > > > /* we don't affect global LRU but rotate in our LRU */
> > > > @@ -1235,6 +1242,7 @@ unsigned long mem_cgroup_isolate_pages(u
> > > > }
> > > > }
> > > >
> > > > +out:
> > > > *scanned = scan;
> > > >
> > > > trace_mm_vmscan_memcg_isolate(0, nr_to_scan, scan, nr_taken,
> > > > Index: linux/include/linux/memcontrol.h
> > > > ===================================================================
> > > > --- linux.orig/include/linux/memcontrol.h 2011-10-25 08:36:08.000000000 +0800
> > > > +++ linux/include/linux/memcontrol.h 2011-10-25 09:33:51.000000000 +0800
> > > > @@ -37,7 +37,8 @@ extern unsigned long mem_cgroup_isolate_
> > > > unsigned long *scanned, int order,
> > > > int mode, struct zone *z,
> > > > struct mem_cgroup *mem_cont,
> > > > - int active, int file);
> > > > + int active, int file,
> > > > + struct page **split_page);
> > > >
> > > > #ifdef CONFIG_CGROUP_MEM_RES_CTLR
> > > > /*
> > > >
> > > >
> > >
> > > I saw the code. my concern is your patch could make unnecessary split of THP.
> > >
> > > When we isolates page, we can't know whether it's working set or not.
> > > So split should happen after we judge it's working set page.
> > yes, but since memory is big currently, it's unlikely the isolated page
> > get accessed in the window. And I only did the split in
>
> We don't check page_reference when isolate happens.
> Window which between isolation time and reclaim?
> No. Window is from inactive's head to tail and it's the basic concept of
> our LRU.
>
> > shrink_inactive_list, not in active list.
>
> But inactive list's size could be still big and
> page reference heuristic is very important for reclaim algorithm.
I mean pages aren't referenced. but ok, I can't take such assumption.
> > And THP has mechanism to collapse small pages to huge page later.
>
> You mean "merge" instead of "collapse"?
>
> >
> > > If you really want to merge this patch, I suggest that
> > > we can handle it in shrink_page_list step, not isolation step.
> > >
> > > My totally untested code which is just to show the concept is as follows,
> > I did consider this option before. It has its problem too. The isolation
> > can isolate several huge page one time. And then later shrink_page_list
> > can swap several huge page one time, which is unfortunate. I'm pretty
> > sure this method can't reduce the thp_split count in my test. It could
>
> I understand your point but approach isn't good to me.
> Maybe we can check whether we are going on or not before other THP page split happens
> in shrink_page_list. If we split THP page successfully, maybe we can skip another THP split.
> Another idea is we can avoid split of THP unless high order reclaim happens or low order
> high priority pressure happens.
I agreed the split better be done at shrink_page_list, but we must avoid
isolate too many pages. I'll check if I can have a better solution for
next post.
Thanks,
Shaohua
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [Buildroot] [PATCH] syslinux: add support for host-install
From: Will Moore @ 2011-10-31 8:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1319668075-20291-1-git-send-email-arnout@mind.be>
Hi Arnout,
> -----Original Message-----
> From: Arnout Vandecappelle (Essensium/Mind) [mailto:arnout at mind.be]
> Sent: 26 October 2011 23:28
> Subject: [PATCH] syslinux: add support for host-install
>
> From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> Hoi Will,
>
> This patch (applied to the current HEAD) builds syslinux for the host.
Thanks!
I can see some discussion on the mailing list of a few patches you have sent for
syslinux moving to v4.04 and adding the host build, but what is the status of
these?
>
> What is still missing from this is a way to have a Windows self-installer.
> I've got a patch cooking for that too, but it's a hack: it copies the
> precompiled syslinux.exe binary from the extracted tar file.
I can't see there is another way. I have no interest in this personally but
would like to have a target build so my buildroot target can itself syslinux a
device to make it bootable. I would suggest that these are both unusual versus
having a host build and so should be menu options.
>
> Regards,
> Arnout
> ---
> boot/syslinux/syslinux.mk | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/boot/syslinux/syslinux.mk b/boot/syslinux/syslinux.mk
> index fa5af07..66a7076 100644
> --- a/boot/syslinux/syslinux.mk
> +++ b/boot/syslinux/syslinux.mk
> @@ -26,4 +26,20 @@ define SYSLINUX_INSTALL_IMAGES_CMDS
> done
> endef
>
> +
> +HOST_SYSLINUX_POST_EXTRACT_HOOKS += SYSLINUX_RM_MK_LBA_IMG
> +
> +define HOST_SYSLINUX_BUILD_CMDS
> + $(HOST_MAKE_ENV) $(MAKE) -C $(@D)
> +endef
> +
> +define HOST_SYSLINUX_INSTALL_CMDS
> + $(HOST_MAKE_ENV) $(MAKE) -C $(@D) INSTALLROOT=$(HOST_DIR) install
> +endef
> +
> +define HOST_SYSLINUX_CLEAN_CMDS
> + $(HOST_MAKE_ENV) $(MAKE) -C $(@D) clean
> +endef
> +
> $(eval $(call GENTARGETS))
> +$(eval $(call GENTARGETS,host))
> --
> 1.7.7
^ permalink raw reply
* [PATCH v2] KVM: booke: Do Not start decrementer when SPRN_DEC set 0
From: Bharat Bhushan @ 2011-10-31 8:54 UTC (permalink / raw)
To: kvm-ppc
As per specification the decrementer interrupt not happen when DEC is written with 0. Also when DEC is zero, no decrementer running. So we should not start hrtimer for decrementer when DEC = 0.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
arch/powerpc/kvm/emulate.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 141dce3..0452357 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -77,7 +77,8 @@ static int kvmppc_dec_enabled(struct kvm_vcpu *vcpu)
#else
static int kvmppc_dec_enabled(struct kvm_vcpu *vcpu)
{
- return vcpu->arch.tcr & TCR_DIE;
+ /* On BOOKE, DEC = 0 is as good as decrementer not enabled */
+ return (vcpu->arch.tcr & TCR_DIE) && vcpu->arch.dec;
}
#endif
--
1.7.0.4
^ permalink raw reply related
* [U-Boot] [PATCH 2/2] at91: defined mach-types for otc570 board in board config file
From: Daniel Gorsulowski @ 2011-10-31 8:52 UTC (permalink / raw)
To: u-boot
quotation from Albert ARIBAUD:
"Recently the ARM mach-types.h file has been brought in sync with its
Linux original, leasing to a number of boards not being listed any more,
as the new list only contains boards which have actual Linux support or
were declared less than one year ago.
The symptom is a build failure with a message of the form "error:
'MACH_TYPE_XXXXXX' undeclared (first use in this function)".
U-Boot maintainers of such boards (in Cc: of this mail) should provide a
patch to re-introduce the MACH_TYPE_XXXXXX definition in their boards'
config header file in include/configs/."
Signed-off-by: Daniel Gorsulowski <Daniel.Gorsulowski@esd.eu>
---
include/configs/otc570.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/configs/otc570.h b/include/configs/otc570.h
index e2c2eda..c068aa0 100644
--- a/include/configs/otc570.h
+++ b/include/configs/otc570.h
@@ -45,6 +45,13 @@
*/
#define CONFIG_SYS_TEXT_BASE 0x20002000
+/*
+ * since a number of boards are not being listed in linux
+ * arch/arm/tools/mach-types any more, the mach-types have to be
+ * defined here
+ */
+#define MACH_TYPE_OTC570 2166
+
/* ARM asynchronous clock */
#define CONFIG_SYS_AT91_SLOW_CLOCK 32768 /* 32.768 kHz crystal */
#define CONFIG_SYS_AT91_MAIN_CLOCK 16000000/* 16.0 MHz crystal */
--
1.5.3
^ permalink raw reply related
* [U-Boot] [PATCH 1/2] at91: defined mach-types for meesc board in board config file
From: Daniel Gorsulowski @ 2011-10-31 8:52 UTC (permalink / raw)
To: u-boot
quotation from Albert ARIBAUD:
"Recently the ARM mach-types.h file has been brought in sync with its
Linux original, leasing to a number of boards not being listed any more,
as the new list only contains boards which have actual Linux support or
were declared less than one year ago.
The symptom is a build failure with a message of the form "error:
'MACH_TYPE_XXXXXX' undeclared (first use in this function)".
U-Boot maintainers of such boards (in Cc: of this mail) should provide a
patch to re-introduce the MACH_TYPE_XXXXXX definition in their boards'
config header file in include/configs/."
Signed-off-by: Daniel Gorsulowski <Daniel.Gorsulowski@esd.eu>
---
include/configs/meesc.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/configs/meesc.h b/include/configs/meesc.h
index a2b55d5..ea40290 100644
--- a/include/configs/meesc.h
+++ b/include/configs/meesc.h
@@ -45,6 +45,14 @@
*/
#define CONFIG_SYS_TEXT_BASE 0x20002000
+/*
+ * since a number of boards are not being listed in linux
+ * arch/arm/tools/mach-types any more, the mach-types have to be
+ * defined here
+ */
+#define MACH_TYPE_MEESC 2165
+#define MACH_TYPE_ETHERCAN2 2407
+
/* ARM asynchronous clock */
#define CONFIG_SYS_AT91_SLOW_CLOCK 32768 /* 32.768 kHz crystal */
#define CONFIG_SYS_AT91_MAIN_CLOCK 16000000/* 16.0 MHz crystal */
--
1.5.3
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2011-10-31 8:40 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
The majority of the bits here are driver bug fixes, but more notably:
1) icmp6_dst_alloc needs to set the destination address in the route
before trying to binding the route to an inetpeer entry, since the
inetpeer is found by destination. Fix from Gao Feng.
2) Traffic class not set properly for TIME_WAIT sockets, from Eric
Dumazet.
3) Fix vlan over bonding ARP regression, also from Eric Dumazet.
4) ip6_ufo_append_data() does not propagate errors properly, resulting
in signal interrupts and hangups looking like memory allocation
errors. Fix from Zheng Yan.
5) Refcounting and hash lookup fixes in batman-adv from Simon Wunderlich.
7) Fix races in bond_close() and workqueue deadlocks. From Jay
Vosburgh.
8) IPV6 addrconf prefix handling needs to explicitly lookup routes
in the RT6_TABLE_PREFIX routing table, otherwise it might find
unrelated routes. Fix from Andreas Hofmeister.
Please pull, thanks a lot!
The following changes since commit 839d8810747bbf39e0a5a7f223b67bffa7945f8d:
Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (2011-10-30 15:54:59 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Andreas Hofmeister (1):
ipv6: fix route lookup in addrconf_prefix_rcv()
Angus Clark (1):
stmmac: fix NULL pointer dereference in capabilities fixup (v2)
Antonio Quartulli (1):
batman-adv: unify hash_entry field position in tt_local/global_entry
David S. Miller (1):
Merge branch 'batman-adv/maint' of git://git.open-mesh.org/linux-merge
Dmitry Kravkov (2):
bnx2x: use FW 7.0.29.0
bnx2x: update driver version to 1.70.30-0
Eric Dumazet (2):
ipv6: tcp: fix TCLASS value in ACK messages sent from TIME_WAIT
vlan: allow nested vlan_do_receive()
Gao feng (1):
ipv6: fix route error binding peer in func icmp6_dst_alloc
Geert Uytterhoeven (1):
i825xx: Fix incorrect dependency for BVME6000_NET
Giuseppe CAVALLARO (2):
stmmac: fix a bug while checking the HW cap reg (v2)
stmmac: update normal descriptor structure (v2)
Jay Vosburgh (1):
bonding: eliminate bond_close race conditions
Simon Wunderlich (2):
batman-adv: remove references for global tt entries
batman-adv: add sanity check when removing global tts
Somnath Kotur (2):
be2net: Refactored be_cmds.c file.
be2net: Changing MAC Address of a VF was broken.
Sony Chacko (1):
qlcnic: updated reset sequence
Sritej Velaga (2):
qlcnic: skip IDC ack check in fw reset path.
qlcnic: Updated License file
Sucheta Chakraborty (2):
qlcnic: reset loopback mode if promiscous mode setting fails.
qlcnic: fix beacon and LED test.
Yaniv Rosner (5):
bnx2x: Fix LED blink rate for 578xx
bnx2x: Add link retry to 578xx-KR
bnx2x: Fix RX/TX problem caused by the MAC layer
bnx2x: Fix 54618se LED behavior
bnx2x: Enable changing speed when port type is PORT_DA
Zheng Yan (1):
ipv6: fix error propagation in ip6_ufo_append_data()
Documentation/networking/LICENSE.qlcnic | 51 +---
drivers/net/bonding/bond_3ad.c | 8 +-
drivers/net/bonding/bond_alb.c | 16 +-
drivers/net/bonding/bond_main.c | 96 +++---
drivers/net/bonding/bonding.h | 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 4 +-
.../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 217 ++++++++---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.h | 3 +
drivers/net/ethernet/emulex/benet/be_cmds.c | 400 ++++++--------------
drivers/net/ethernet/emulex/benet/be_main.c | 28 +-
drivers/net/ethernet/i825xx/Kconfig | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 4 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 45 ++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h | 2 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 50 +++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 48 ++-
drivers/net/ethernet/stmicro/stmmac/common.h | 8 +-
drivers/net/ethernet/stmicro/stmmac/descs.h | 31 +-
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 38 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 8 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +-
include/linux/if_vlan.h | 6 +-
include/net/inet_timewait_sock.h | 1 +
include/net/ipv6.h | 3 +-
net/8021q/vlan_core.c | 7 +-
net/batman-adv/translation-table.c | 17 +-
net/batman-adv/types.h | 4 +-
net/core/dev.c | 4 +-
net/dccp/ipv6.c | 4 +-
net/ipv4/tcp_minisocks.c | 1 +
net/ipv6/addrconf.c | 43 ++-
net/ipv6/inet6_connection_sock.c | 2 +-
net/ipv6/ip6_output.c | 9 +-
net/ipv6/route.c | 3 +-
net/ipv6/tcp_ipv6.c | 17 +-
net/sctp/ipv6.c | 2 +-
39 files changed, 634 insertions(+), 567 deletions(-)
^ permalink raw reply
* Winning Code (AQ11WWRZZA1)!!!
From: British Cordinator @ 2011-10-31 8:40 UTC (permalink / raw)
This is to inform you that you have been
selected for a cash prize of 1,000,000
(British Pounds) held on the 28th of october,
2011 in London (United Kingdom).
1.Full Name
2.Full Address
3.Marital Status
4.Occupation
5.Age
6.Sex
7.Country Of Residence
8.Telephone Number
9.Next of Kin
Agent Name: Mr.David Scott
Tel: +44 702-403-4509
Email: (bnl.claimsdept121@live.co.uk)
^ permalink raw reply
* [U-Boot] Goodday !!!!
From: Mr Ali Musa @ 2011-10-31 8:49 UTC (permalink / raw)
To: u-boot
Goodday !!!!?My Name is Mr Ali Musa, I am the Bill and exchange manager of ADB Bank In Ouagadougou Burkina Faso West Africa.I have a business proposal in the tune of $6.2m (six million two hundred thousand United States Dollar only) after the successful transfer we shall share in ratio of 40% for you and 60% for me.?Should you be interested, so we can commence all arrangements and I will give you more information on how we would handle this project? Please treat thisbusiness with utmost confidentiality and send me the Following information's bellow;?(1) Full names:(2) Private phone number:(3) Currentresidential address:(4) Occupation:(5) Age and Sex:?Best Regards,Mr Ali Musa.
^ permalink raw reply
* (unknown),
From: merez @ 2011-10-31 8:49 UTC (permalink / raw)
To: linux-mmc
subscribe linux-mmc
^ permalink raw reply
* [U-Boot] [PATCH 1/5] arm/km: adapt bootcounter evaluation
From: Prafulla Wadaskar @ 2011-10-31 8:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE58B6.9040805@keymile.com>
> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck at keymile.com]
> Sent: Monday, October 31, 2011 1:44 PM
> To: Prafulla Wadaskar
> Cc: u-boot at lists.denx.de; Valentin Longchamp;
> albert.u.boot at aribaud.net; Wolfgang Denk
> Subject: Re: [PATCH 1/5] arm/km: adapt bootcounter evaluation
>
> On 10/31/2011 08:29 AM, Prafulla Wadaskar wrote:
...snip...
>
> Anyway Wolfgang or Albert, who should pick up the patches for
> our Keymile
> Kirkwood boards?
>
> This two series have only board specific patches:
> http://lists.denx.de/pipermail/u-boot/2011-
> September/101328.html
> http://lists.denx.de/pipermail/u-boot/2011-
> September/102534.html
Applied both these patches to u-boot-marvell.git master branch
Regards..
Prafulla . .
^ permalink raw reply
* Serious question: How long does it take to get 64bit into ARM?
From: Catalin Marinas @ 2011-10-31 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111030001654.GX4267@michelle1>
Hi,
On 30 October 2011 01:16, Michelle Konzack
<linux4michelle@tamay-dogan.net> wrote:
> Applied Micro Circuits (AMCC) has now presented its new 64bit ARM ?C:
>
> ? ?<http://www.pcmag.com/article2/0,2817,2395449,00.asp>
>
> and I like to know, how long it take, to ?get ?64bit ?support ?into ?the
> Kernel.
We are working on this already and will follow the Linux community
review process to get the ARMv8 support in the mainline kernel. I
can't mention a timeline at this point as it depends on detailed
documentation being available and at least some early hardware (FPGA)
to test on but hopefully we'll complete the process before you can get
platforms with ARMv8 (even if mainline would not fully support ARMv8,
I'll make patches available on some Git tree).
--
Catalin
^ permalink raw reply
* [U-Boot] [PATCH V2] ARM: re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
From: Igor Grinberg @ 2011-10-31 8:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE5BFA.3040805@scharsoft.de>
Hi Jens,
On 10/31/11 10:27, Jens Scharsig wrote:
> Am 2011-10-31 08:46, schrieb Igor Grinberg:
>> Hi Jens,
>>> @@ -41,6 +41,8 @@
>>> #define CONFIG_MISC_INIT_R
>>> #define CONFIG_BOARD_EARLY_INIT_F
>>>
>>> +#define MACH_TYPE_EB_CPUX9K2 1977
>>> +
>>
>> While you are at it, probably, it will be a good time
>> to switch to the new standard and use the CONFIG_MACH_TYPE
>> option. Please, read the README file.
>>
>>> /*--------------------------------------------------------------------------*/
>>> #define CONFIG_SYS_TEXT_BASE 0x00000000
>>> #define CONFIG_SYS_LOAD_ADDR 0x21000000 /* default load address */
>>
>
> Dear Albert ARIBAUD,
>
> What's your opinion?
>
> #define MACH_TYPE_EB_CPUX9K2 1977
>
> or
>
> #define CONFIG_MACH_TYPE 1977
It should be both:
#define MACH_TYPE_EB_CPUX9K2 1977
and then:
#define CONFIG_MACH_TYPE MACH_TYPE_EB_CPUX9K2
--
Regards,
Igor.
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Quentin Lefebvre @ 2011-10-31 8:47 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <CAP8O3oNnSWO2q5-97XkcpxE-FK7nyyTF1YSSWCf+F+crpr2pEw@mail.gmail.com>
On 31/10/2011 01:30, Aleksander Swirski wrote :
> I'm pretty sure this warning is only displayed when someone decides to
> create new crypto on some partition or fill encrypted device with random
> data in the next step after setting the password. but just setting the
> password on an existing device makes data unusable without warning. when
> the partitioning is finished there is a list of partitions that will be
> wiped out, and also, during my installation crypto-deviced and /home inside
> LVM was not listed there, but already lost few clicks earlier.
>
> i understand that it wasn't taken into consideration that someone can
> attach existing encrypted device, but only that a new one will be created.
> this is inconsistent with how it goes with unencrypted partitions, where
> you can reattach them without formatting and keep your data. so i guess
> with encrypted partition this should also work that way. or maybe i miss
> the point? i will try to make the whole scenario clear, and then send my
> proposition, to debian-boot@lists.debian.org
Hi,
Indeed, it seems that improvements can be done for the Debian installer
to better handle crypto disks and partitions. With the little experience
I have about using encrypted partitions with LUKS/cryptsetup under/over
LVM, I would not have tried to attach an existing encrypted device
through the installer menu, as I know pretty well that few scenarios are
handled at this point.
Hopelessly, what you had to do in your case was to switch to a console
to make changes by hand or, if you could, wait for the reboot of your
fresh install to edit the system files and mount old volumes this way.
I agree on the point you mention, i.e. encryption could be better
integrated in the installer so that assisted mounting of old encrypted
partitions becomes possible.
In my particular case, it would be *very* valuable that other encryption
schemes get integrated in the linux kernel / initrd used by the Debian
installer, because the latter cannot either create or mount my encrypted
partitions (which need the 'xts' module). At least not with additional
work... Installing my system is really complicated by this limitation,
as I have to :
1) ( *before* launching the installer) find the appropriate kernel
modules and put them on a USB key (I sometimes installed a useless
system just for that)
2) (during the installation process) manually partition the disks in a
console, with the necessary step of loading the modules I use
3) (at the end of the installation process, *before* reboot ) 'chroot
/target' to
a) edit the /etc/cryptab file and add my encrypted devices
b) edit the /etc/initramfs-tools/modules and add the appropriate modules
c) *run* 'mkinitramfs -k all -u -v'
d) check grub and fstab config (no longer necessary ?)
e) exit
Only after these operations, I can safely switch back to the installer
and reboot the system, with the hope my root filesystem will be
correctly opened.
I would be happy to help Debian developers regarding this kind of
install, but I have always delayed the moment I contact them. If you are
planning to do so, I would be interested to be included in the
discussion and give my feedback too.
Best,
Quentin
^ permalink raw reply
* [U-Boot] Business Proposal
From: MARRI0TT-H0TEL-GROUP @ 2011-10-31 8:46 UTC (permalink / raw)
To: u-boot
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.denx.de/pipermail/u-boot/attachments/20111031/272bb824/attachment.asc
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.