On Thu, Jun 12, 2014 at 4:34 AM, wrote:
>
> Do you think it happens only specific version?
>
I am running the same (20140609) aufs on Linux 3.12.21 on two real
machines with similar aufs stacks (tmpfs:squashfs:squashfs) but
mach-1) Is an Intel Core 2 Duo, has CONFIG_MCORE2=y, two squashfs
image
Guan Xin:
> mach-1) Is an Intel Core 2 Duo, has CONFIG_MCORE2=y, two squashfs
> images on an ext4;
>
> mach-2) Is an Intel Core Duo, has CONFIG_MPENTIUMM=y but otherwise the
> same config as 1, two squashfs images on tmpfs.
>
> This problem only happens to the mach-1.
Then we have two options as
On Thu, Jun 12, 2014 at 11:53 AM, wrote:
>
> Then we have two options as next step.
>
> 1. dive into IDR assembler code on MCORE2
>- disassemble IDR object file
>- write a small test program for IDR, run and disassemble it
>
> 2. forget all about chip dendent issues
>- re-build as oth
Guan wrote:
I am running the same (20140609) aufs on Linux 3.12.21 on two real
machines with similar aufs stacks (tmpfs:squashfs:squashfs) but
mach-1) Is an Intel Core 2 Duo, has CONFIG_MCORE2=y, two squashfs
images on an ext4;
mach-2) Is an Intel Core Duo, has CONFIG_
Guan Xin:
> Built with CONFIG_M686=y, same problem.
> Run memtest86+, no error.
Ok, thanks.
Guan, Nikolay, would you test this patch manually for mm/shmem.c?
It may produce a new warining once.
ino = idr_alloc(&sbinfo->idr, inode, 2, INT_MAX, GFP_NOFS);
if (ino
J. R. Okajima:
Ok, thanks.
Guan, Nikolay, would you test this patch manually for mm/shmem.c?
It may produce a new warining once.
        ino = idr_alloc(&sbinfo->idr, inode, 2, INT_MAX,
GFP_NOFS);
        if (ino > 0) {
  Â
Nikolay Pertsev:
> I tested it. I got the following in my dmesg output:
Thanks.
Confirmed no progress...
J. R. Okajima
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most
On Thu, Jun 12, 2014 at 7:20 PM, Nikolay Pertsev wrote:
>
> So, on mach-1 what folders do you mount as aufs branches?
I mounted 3 branches on both machines -- br1:br2:br3
where br1 is tmpfs, br2 and br3 are squashfs.
br3 is the system image, and br2 contains /lib/{firmware,modules}.
> And do yo
On Thu, Jun 12, 2014 at 7:36 PM, wrote:
>
> Guan, Nikolay, would you test this patch manually for mm/shmem.c?
> It may produce a new warining once.
>
>
> ino = idr_alloc(&sbinfo->idr, inode, 2, INT_MAX, GFP_NOFS);
> if (ino > 0) {
> inode->i
Guan Xin:
> Didn't see the new warning after reboot to the patched kernel ...
> Still the same error messages as before.
Thanks guys.
When you have time, please test this too.
You don't have to hurry since I am going to sleep. It is midnight in my
timezone now.
simple_xattrs_free(&info
On Thu, Jun 12, 2014 at 8:22 PM, wrote:
> simple_xattrs_free(&info->xattrs);
> WARN_ON(inode->i_blocks);
> if (inode->i_ino) {
> + int i = inode->i_ino;
> mutex_lock(&sbinfo->idr_lock);
> - idr_remove(&sbinfo->idr, inode->i_ino);
J. R. Okajima:
On Thu, Jun 12, 2014 at 8:22 PM, Â <[1]sf...@users.sourceforge.net> wrote:
> Â Â Â Â simple_xattrs_free(&info->xattrs);
> Â Â Â Â WARN_ON(inode->i_blocks);
> Â Â Â Â if (inode->i_ino) {
> + Â Â Â Â Â Â Â int i = inode->i_ino;
> Â Â Â Â Â
Nikolay Pertsev:
> Also notice that id values in at least first 9 error messages are products
> of multiplication of number 32768.
>
> In my case I have only 3 error messages and ids are 32768, 65537 and 98304
> which is the same pattern.
Please apply this too and let's see how many times will th
> Please apply this too and let's see how many times will the message
> printed for the same inode-number.
Ah!
please replace 0x8000 by 0x08000.
J. R. Okajima
--
HPCC Systems Open Source Big Data Platform from LexisNex
J. R. Okajima:
> Please apply this too and let's see how many times will the message
> printed for the same inode-number.
Ah!
please replace 0x8000 by 0x08000.
J. R. Okajima
Ok, so here it is.
[1]http://pastebin.com/nHacTb7f
Also, Guan's system generates much mo
Nikolay Pertsev:
> Ok, so here it is.
>
> http://pastebin.com/nHacTb7f
Let me make sure.
Didn't you forget applying the patch against mm/shmem.c:shmem_get_inode()?
Didn't it print anything at all?
If it is true, this is a very interesting discovery.
Next time I send you a debug patch, I will con
On Wed, Jun 11, 2014 at 8:16 PM, <[1]sf...@users.sourceforge.net> wrote:
Jeremy Lin:
> I'm looking to use the 'fallocate' command under an aufs mount (within a
> Docker container), but this doesn't seem to work currently. Is there any
> technical reason that the fallocate() sysc
Jeremy Lin:
> I applied your patch to the 3.13.0-29-generic kernel on Ubuntu 14.04. I ran
> some tests with /usr/bin/fallocate in a Docker 1.0 container, using 1-5 GB
> files. Everything seems to work fine. In particular, when the Docker
> storage is on an ext4 partition, fallocate works as expect
18 matches
Mail list logo
