**** BEGIN LOGGING AT Mon Jun 30 02:59:56 2008
Jun 30 04:46:14 <CIA-47> 03bzhou * r8622 10optware/trunk/ (make/libc-dev.mk platforms/packages-syno-x07.mk): libc-dev: moved _nonshared.a from /usr/lib to /opt/lib; promoted on syno-x07 (native toolchain part 3 of 3)
Jun 30 05:27:43 <CIA-47> 03bzhou * r8623 10optware/trunk/make/optware-devel.mk: optware-devel: updated DEPENDS list
Jun 30 05:58:41 <CIA-47> 03bzhou * r8624 10optware/trunk/make/sdparm.mk: sdparm: 1.02 -> 1.03
Jun 30 05:59:03 <CIA-47> 03bzhou * r8625 10optware/trunk/make/httping.mk: httping: 1.2.6 -> 1.2.8
Jun 30 21:44:51 <CIA-48> 03bzhou * r8629 10optware/trunk/make/libc-dev.mk: libc-dev: do not use ?= in LIBC-DEV_VERSION
Jun 30 22:01:54 <CIA-48> 03bzhou * r8630 10optware/trunk/make/py-paste.mk: py-paste: 1.7 -> 1.7.1
Jun 30 22:02:18 <CIA-48> 03bzhou * r8631 10optware/trunk/make/py-pastedeploy.mk: py-pastedeploy: 1.3.1 -> 1.3.2
Jun 30 22:02:44 <CIA-48> 03bzhou * r8632 10optware/trunk/make/py-pastescript.mk: py-pastescript: 1.6.2 -> 1.6.3
Jun 30 23:57:55 <sdm485> RobNC: I have managed to create the fatslug problem reliably. I am using rsnapshot to transfer 10G to the slug. It randomly stops processing but still responds to pings.
Jun 30 23:59:07 <sdm485> Further, If I mount the destination partition as ext2 instead of ext3, it succeeds every time so far. So it fails every time if mounted as ext3 and succeeds every time when mounted as ext2
Jul 01 00:00:10 <sdm485> It also runs about 3 times faster when mounted ext2.
Jul 01 00:01:24 <sdm485> I can also have it hang deleting that 10G of data when mounted ext3 and succeed when mounted ext2.
Jul 01 00:07:08 <rwhitby> sdm485: interesting about the ext2/ext3 difference.
Jul 01 00:08:00 <rwhitby> still responding to pings is expected, since the networking doesn't depend on the usb subsystem (which dies and takes all/most userspace programs with it but doesn't actually kill the kernel)
Jul 01 00:09:45 <sdm485> rwhitby: yes. I don't think it is kjournald unless something about the usb subsystem exposes a race situation. I am presently checking out the effects of atime/noatime.
Jul 01 00:13:31 <rwhitby> do you have the dmabounce debug patch in your kernel from openwrt?
Jul 01 00:14:44 <sdm485> I have the default slugosbe-4.10-alpha version. 
Jul 01 00:15:49 <rwhitby> If you add https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/trunk/target/linux/ixp4xx/patches-2.6.26/400-dmabounce.patch to the kernel, and enable it, you'll get more info about the DMA allocations that we think are causing the problem.
Jul 01 00:16:23 <rwhitby> (it's not added by default since it's debug-overkill for the 95% of cases where it doesn't kill anything)
Jul 01 00:16:35 <sdm485> OK. Can you give a quick runthrough as to how to do that?
Jul 01 00:17:55 <rwhitby> use the nslu2-linux svn kernel repo to build a custom kernel
Jul 01 00:23:40 <sdm485> OK. Just a question. Is it possible to just apply the patch to my existing work directory and then make it rebuild? 
Jul 01 00:27:27 <rwhitby> yes, you could do that manually by re-running the compile step in bitbake for ixp4xx-kernel
Jul 01 00:35:57 <sdm485> OK, I see it. I will enable the flag and rebuild and let you know. Thanks.
Jul 01 00:41:56 <sdm485> For the record, I am using a 128M fatslug. It has a serial port on it and I can watch for messages there.
Jul 01 01:07:57 <sdm485> yikes! that debug message popped up three times on boot. Just after usb3 was found and before kjournald launched.
Jul 01 01:12:40 <sdm485> Requested size was 0x00002000 (8k)
Jul 01 01:24:56 <sdm485> and 0x00010000 (64k), 0x00003000 (12k), 0x00004000 (16k), 0x00007000,0x0000C000,0x0000D000,0x0000E000
Jul 01 01:26:23 <sdm485> There are too many messages to continue testing. The trace back is the same in each call.
Jul 01 01:42:28 <CIA-48> 03osas * r8633 10optware/trunk/make/asterisk14.mk: asterisk14: 1.4.21 -> 1.4.21.1
**** ENDING LOGGING AT Tue Jul 01 02:59:56 2008