> Hello, > > I tested 2.6.34-rc7 now and it has the problem too. > Then I checked 2.6.24.7 which has the problem, > but 2.6.23.1 looks fine. Hello, I searched a bit more in the git tree, when the "Permission denied" problems does occur first(for me). I'm no expert in git. I used git bisect visualize to find a commit which should build and then tested if it works/works not. The first commit which introduced the "Permission denied" problem, was: 1-run: >commit 77a55a1fe8f26f7d022986a599b68002e21d968a >NFS: Eliminate nfs_renew_times() >svn: Can't change perms of file >'Kernel-pxe3-1.h2cuuZBQlF/arch/h8300/platform/h8 >s/.svn/log.1': Permission denied When I go back one commit, the "Permission denied" disappears, but now I get an "Input/output error". 5-run: >commit 92f6c178250170222f6d80c8ae725400765aa7a4 >"Don't call nfs_renew_times() in nfs_dentry_iput()" >svn: Can't read file >'Kernel-pxe3-5.HQikkhUNHk/drivers/usb/storage/.svn/log': Input/output error Thus it looks that the problem is now "I/O Error" instead of permission denied. And that I have to search when the I/O Error disappears? Maybe someone has an idea what went wrong here? All I can say that I have reproduced a similar svn problem with 2.6.33 as server/client and with 2.6.34-rc7 as client. And that on my system does not go away with sync, tcp, udp, noac, nosharecache. But I cannot say that the problem in the 2.6.33 (server/client) combination is the same. Because with this the svn error is "No such file or directory". The problem never existed on my 2.6.16 kernel from SLES10, but now every kernel >= 2.6.24 seems to be affected. regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html