On Wed, 2010-12-22 at 16:53 -0500, Carlos O'Donell wrote: > On Wed, Dec 22, 2010 at 4:34 PM, Guy Martin <gmsoft@xxxxxxxxxxxx> wrote: > > It seems that NFS got broken recently. > > I've bisected this to babddc72a9468884ce1a23db3c3d54b0afa299f0. > > > > Both NFS version 2 and 3 are affected. I haven't tested NFS 4. > > > > I've been able to reproduce with both 32bit and 64bit kernels using > > gcc-4.5.1 with the fix for PR46915 included. > > > > To reproduce, simply mount an NFS share and try to list the files with > > ls. > > > > When listing the directory, the code seem to be looping in the commit I > > mentioned. The network traffic goes high and you always see the same > > packets flowing. > > > > In current HEAD, the behavior is slightly different. The process uses > > 100% and either you get a kernel panic or if you are lucky, you get > > something like "memory exhausted". > > > > > > I'm not sure how to troubleshoot this further. > > > > Any idea ? > > You need to understand the failure mode. > > I would do two things: > > (a) Revert the patch on HEAD and see if it works. This is usually > convincing proof that something is broken and the patch interacts > badly with our arch. > > (c) Put printfs in the code to see where it's looping and under what > conditions. > > Once you have a better grasp of the failure mode you can contact the > author of the patch and tell them about the breakage, CC linux-parisc, > and ask for help. > > That would be me plan of attack. Arm ran into this as well http://marc.info/?t=129372938100002 It looks to be an inequivalent aliasing problem caused by writes via the kernel direct mapping, and reads via vmalloc space. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
