Bug#524003: FTBFS on armel
tags 524003 + patch thanks. * Sebastian Andrzej Siewior | 2010-01-26 23:09:59 [+0100]: fine. I don't patch tag since the two dcache flushes don't look right and upstream did not apply it yet. We will see. It is in queued in -mm [0] for .33, will be backportable if nobody has a problem with it [1]. So we have patch now :) I'm curious what can be done about the dependency of tokyocabinet. It should depend on the kernel which has the patch because a user of the library might get wrong results if it is using a kernel without the patch on the affected architecture. However, there is no need to use a debian kernel so users without a debian kernel would get it pulled in. Plus even if the kernel is installed it is not necessary that this is the kernel which booted the system. [0] http://marc.info/?l=linux-mm-commitsm=126454582727638w=2 [1] http://lkml.org/lkml/2010/1/27/344 Sebastian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
Hi, and thanks for tracing this bug down! Quick summary for debian-kernel list - a patch in generic kernel code is needed to fix tokyocabinet FTBFS on armel. On Thu, Jan 28, 2010 at 09:49:57AM +0100, Sebastian Andrzej Siewior wrote: It is in queued in -mm [0] for .33, will be backportable if nobody has a problem with it [1]. So we have patch now :) Would this be material for backporting to the 2.6.32-x debian kernels? Since most buildd's run debian/stable kernels, until the next release tokyocabinet would need to be built manually on armel anyway. While inconvinient, it should still allow tokyocabinet back in testing. I'm curious what can be done about the dependency of tokyocabinet. It should depend on the kernel which has the patch because a user of the library might get wrong results if it is using a kernel without the patch on the affected architecture. However, there is no need to use a debian kernel so users without a debian kernel would get it pulled in. Plus even if the kernel is installed it is not necessary that this is the kernel which booted the system. Best would be to have a runtime check in tokyocabinet that errs out if the kernel bug is seen. [0] http://marc.info/?l=linux-mm-commitsm=126454582727638w=2 [1] http://lkml.org/lkml/2010/1/27/344 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
* Riku Voipio riku.voi...@iki.fi [2010-01-28 09:18]: Would this be material for backporting to the 2.6.32-x debian kernels? It sounds to me as if Andrew Morton is planning to submit it to the stable branch, so we probably just need to wait. If it doesn't show up in -stable soon, we can add the patch to the Debian package directly. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
On Thu, 2010-01-28 at 09:18 +, Riku Voipio wrote: Hi, and thanks for tracing this bug down! Quick summary for debian-kernel list - a patch in generic kernel code is needed to fix tokyocabinet FTBFS on armel. On Thu, Jan 28, 2010 at 09:49:57AM +0100, Sebastian Andrzej Siewior wrote: It is in queued in -mm [0] for .33, will be backportable if nobody has a problem with it [1]. So we have patch now :) Would this be material for backporting to the 2.6.32-x debian kernels? Since most buildd's run debian/stable kernels, until the next release tokyocabinet would need to be built manually on armel anyway. While inconvinient, it should still allow tokyocabinet back in testing. If it's urgent we can cherry-pick this fix. Otherwise we'll get this via the 2.6.32-stable series after Linus accepts it. I'm curious what can be done about the dependency of tokyocabinet. It should depend on the kernel which has the patch because a user of the library might get wrong results if it is using a kernel without the patch on the affected architecture. However, there is no need to use a debian kernel so users without a debian kernel would get it pulled in. Plus even if the kernel is installed it is not necessary that this is the kernel which booted the system. Best would be to have a runtime check in tokyocabinet that errs out if the kernel bug is seen. I'm not sure that's possible. But certainly a dependency is the wrong way to do this. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#524003: FTBFS on armel
Processing commands for cont...@bugs.debian.org: reassign 524003 linux-2.6 2.6.32-5 Bug #524003 [tokyocabinet] FTBFS on armel Bug reassigned from package 'tokyocabinet' to 'linux-2.6'. Bug No longer marked as found in versions 1.4.14-2. Bug #524003 [linux-2.6] FTBFS on armel There is no source info for the package 'linux-2.6' at version '2.6.32-5' with architecture '' Unable to make a source version for version '2.6.32-5' Bug Marked as found in versions 2.6.32-5. tags 524003 - help Bug #524003 [linux-2.6] FTBFS on armel Removed tag(s) help. thanks. Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
reassign 524003 linux-2.6 2.6.32-5 tags 524003 - help thanks. * Pierre Habouzit | 2009-04-15 01:40:32 [+0200]: Hi Mikio, I'm the Debian maintainer of tokyocabinet, I wanted to report to you that tokyocabinet seems to have issues on armel (and also hppa). You can see the full build logs here: https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=armelver=1.4.14-2stamp=1239676884file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=hppaver=1.4.14-2stamp=1239662413file=logas=raw I've been looking at the ARM part and I can reproduce this here on my machine. The error message or that part where the test case stopped depends very much on the seed. With seed=0 or 1 (don't remember really) I got an infinite loop. So it looked to me for a while that the test code is buggy. Also comparing the seed with amd64 the armel seed is much higher. However nothing of this true :) I looks now that this a kernel bug. The patch at [0] which I attached seems to fix the issue and I was able to build the package on my arm box after applying the patch. I would be happy if someone could re-test this on ARM and on HPPA. I reassing to package to the kernel team since I thing the user space is fine. I don't patch tag since the two dcache flushes don't look right and upstream did not apply it yet. We will see. Date: Thu, 21 Jan 2010 13:07:57 +0800 Message-ID: 979dd0561001202107v4ddc1eb7xa59a7c16c452f...@mail.gmail.com Subject: [PATCH] Flush dcache before writing into page to avoid alias From: anfei zhou anfei.z...@gmail.com To: linux...@kvack.org, linux-ker...@vger.kernel.org Cc: Andrew Morton a...@linux-foundation.org, KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com, li...@arm.linux.org.uk, Jamie Lokier ja...@shareable.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-ow...@vger.kernel.org Precedence: bulk List-ID: linux-kernel.vger.kernel.org The cache alias problem will happen if the changes of user shared mapping is not flushed before copying, then user and kernel mapping may be mapped into two different cache line, it is impossible to guarantee the coherence after iov_iter_copy_from_user_atomic. So the right steps should be: flush_dcache_page(page); kmap_atomic(page); write to page; kunmap_atomic(page); flush_dcache_page(page); More precisely, we might create two new APIs flush_dcache_user_page and flush_dcache_kern_page to replace the two flush_dcache_page accordingly. Here is a snippet tested on omap2430 with VIPT cache, and I think it is not ARM-specific: int val = 0x; fd = open(abc, O_RDWR); addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); *(addr+0) = 0x; tmp = *(addr+0); *(addr+1) = 0x; write(fd, val, sizeof(int)); close(fd); The results are not always 0x 0x at the beginning as expected. Signed-off-by: Anfei anfei.z...@gmail.com --- fs/fuse/file.c |3 +++ mm/filemap.c |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/fs/fuse/file.c b/fs/fuse/file.c index c18913a..a9f5e13 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -828,6 +828,9 @@ static ssize_t fuse_fill_write_pages(struct fuse_req *req, if (!page) break; + if (mapping_writably_mapped(mapping)) + flush_dcache_page(page); + pagefault_disable(); tmp = iov_iter_copy_from_user_atomic(page, ii, offset, bytes); pagefault_enable(); diff --git a/mm/filemap.c b/mm/filemap.c index 96ac6b0..07056fb 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2196,6 +2196,9 @@ again: if (unlikely(status)) break; + if (mapping_writably_mapped(mapping)) + flush_dcache_page(page); + pagefault_disable(); copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes); pagefault_enable(); -- 1.6.3.1 [0] http://lkml.org/lkml/2010/1/21/3 Sebastian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
Package: tokyocabinet Severity: serious Version: 1.4.14-2 User: debian-...@lists.debian.org Usertag: eabi Package testsuite failed with the following error: LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Random Concatenating Test seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0 omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1 .make[2]: *** [check-fdb] Segmentation fault make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make[1]: *** [check] Error 2 make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
On Tue, Apr 14, 2009 at 07:50:18AM +, Riku Voipio wrote: Package: tokyocabinet Severity: serious Version: 1.4.14-2 User: debian-...@lists.debian.org Usertag: eabi Package testsuite failed with the following error: LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Random Concatenating Test seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0 omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1 .make[2]: *** [check-fdb] Segmentation fault make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make[1]: *** [check] Error 2 make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 Yes, I saw that, OTOH it built fine on the experimental buildds, so I'm kind of lost here. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpzSoEQd7xfz.pgp Description: PGP signature
Bug#524003: FTBFS on armel
On Tue, Apr 14, 2009 at 11:13:43PM +0200, Pierre Habouzit wrote: Package testsuite failed with the following error: LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Random Concatenating Test seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0 omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1 .make[2]: *** [check-fdb] Segmentation fault make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make[1]: *** [check] Error 2 make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 Yes, I saw that, OTOH it built fine on the experimental buildds, so I'm kind of lost here. Same error on experimental build: http://experimental.debian.net/fetch.php?pkg=tokyocabinetver=1.4.14-1arch=armelstamp=1239671928file=logas=raw -- rm -rf only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
On Tue, Apr 14, 2009 at 09:20:41PM +, Riku Voipio wrote: On Tue, Apr 14, 2009 at 11:13:43PM +0200, Pierre Habouzit wrote: Package testsuite failed with the following error: LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Random Concatenating Test seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0 omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1 .make[2]: *** [check-fdb] Segmentation fault make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make[1]: *** [check] Error 2 make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 Yes, I saw that, OTOH it built fine on the experimental buildds, so I'm kind of lost here. Same error on experimental build: http://experimental.debian.net/fetch.php?pkg=tokyocabinetver=1.4.14-1arch=armelstamp=1239671928file=logas=raw Damn okay, I was pretty sure it built fine, sorry, I'll try to look into it. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpilKiW6sQ16.pgp Description: PGP signature
Bug#524003: FTBFS on armel
forwarded 524003 mi...@users.sourceforge.net
thanks
On Tue, Apr 14, 2009 at 07:50:18AM +, Riku Voipio wrote:
Package: tokyocabinet
Severity: serious
Version: 1.4.14-2
User: debian-...@lists.debian.org
Usertag: eabi
Package testsuite failed with the following error:
LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded: ignored.
Random Concatenating Test
seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0
omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1
.make[2]: *** [check-fdb] Segmentation fault
make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14'
make: *** [build-arch-stamp] Error 2
dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave
error exit status 2
Hi Mikio, I'm the Debian maintainer of tokyocabinet, I wanted to report
to you that tokyocabinet seems to have issues on armel (and also hppa).
You can see the full build logs here:
https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=armelver=1.4.14-2stamp=1239676884file=logas=raw
https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=hppaver=1.4.14-2stamp=1239662413file=logas=raw
I'm really unsure what is going on, so if you have any idea of how I can
debug this, I'd be glad.
For the armel one, I do have a backtrace though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4001fd80 (LWP 7696)]
0x4007258c in tcfdbputimpl (fdb=value optimized out,
id=4612214096449045504, vbuf=0xbee56661, vsiz=-1, dmode=0) at tcfdb.c:2060
2060 char *nvbuf = procptr-proc(rp, osiz, nvsiz,
procptr-op);
(gdb) bt full
#0 0x4007258c in tcfdbputimpl (fdb=value optimized out,
id=4612214096449045504, vbuf=0xbee56661, vsiz=-1, dmode=0) at tcfdb.c:2060
procptr = (FDBPDPROCOP *) 0x8e5677c
nvsiz = value optimized out
nvbuf = value optimized out
wp = value optimized out
rec = (unsigned char *) 0x40314322
nsiz = value optimized out
rp = (unsigned char *) 0x40314324 \001
osiz = 4
snum = 0
lnum = 1074397736
wp = value optimized out
__PRETTY_FUNCTION__ = tcfdbputimpl
__func__ = tcfdbputimpl
#1 0x40073674 in tcfdbputproc (fdb=0x1a008, id=100, vbuf=0x0, vsiz=0,
proc=0xa55c pdprocfunc, op=0x1) at tcfdb.c:1291
procop = {proc = 0xa55c pdprocfunc, op = 0x0}
procptr = (FDBPDPROCOP *) 0xbee5677c
stack =
|gå¾145\000\000\000\000l\217\000\000\000\000\000\000Dgå¾\230\231\000@,\222\...@hà\001@\000\000\000\000þ3ª\a\001\000\000\000\000\000\000\000
\002\...@\234©\002@hà\...@\000p\002@\000`\...@\000ð\035@\030xå¾\214\f\001\000¨gå¾Øfå¾\b \001\000\000\000\000\000\030xå¾Ðfå¾
ç\...@`ë\016@\000\000\000\000,\222\...@\001\200û\030xå¾\030xå¾\030xå¾\030xå¾\033xå¾\030xå¾,
'\0' repeats 20 times,
:\...@\000\000\000\000\000\000\000\000\000\000\a@\000\000\000\000\000\000\000\000\b \001\000\000\000\000...
rv = value optimized out
__PRETTY_FUNCTION__ = tcfdbputproc
__func__ = tcfdbputproc
#2 0xa3a8 in procrcat (path=value optimized out, rnum=5000,
width=value optimized out, limsiz=0, mt=value optimized out, omode=0,
pnum=500, dai=false, dad=false, rl=71, ru=200) at tcftest.c:668
id = value optimized out
kbuf =
209\000\001\000\000\000\...@\177@\004}å¾\000\000\000\000\000\000\000\000\...@\177@l\00...@\000\000\000\000\000\000\000\000\000@\...@Ø\004\t@
ksiz = 3
i = 105
err = false
stime = 1239752343.776659
fdb = (TCFDB *) 0x1a008
#3 0xf9c4 in main (argc=1, argv=0xbee57b14) at tcftest.c:356
rv = value optimized out
(gdb) p *procptr
Cannot access memory at address 0x8e5677c
(gdb)
Please tell me if you need more informations.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
pgpMaptNugBMb.pgp
Description: PGP signature
Processed: Re: Bug#524003: FTBFS on armel
Processing commands for cont...@bugs.debian.org: forwarded 524003 mi...@users.sourceforge.net Bug#524003: FTBFS on armel Noted your statement that Bug has been forwarded to mi...@users.sourceforge.net. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
