Hi John, > Hi Ajish, > > >> > >>>> From an earlier mail [0] I got the impression that you tested on > >>>> an arm platform – did you? > >>> Yes, with respect to my previous mail update, at that time got the > >>> chance to load the driver on ARM server/enclosure connected in one > >>> of our tester's arm server after attaching the controller card. > >>> There this error handling issue was observed. > >>> > >>> The card/driver was never tested or validated on ARM server before, > >>> was curious to see the behavior for the first time. Whereas driver > >>> loads smoothly on x86 server. > >>> > >>> Currently busy with some other issues, debugging on ARM server is > >>> not planned for now. > >>> > >> OK, since you do see this same/similar issue with another card on arm > >> then I think that it is safe to assume that it is a driver issue. > >> > >> If you can share the dmesg on the arm machine then at least that > >> would be helpful. > > Right now the arm configuration is not available. Will be difficult to > > get dmesg. > > By adding (enabling) a tonne of debug logs in the the driver and enabling > heavy kernel debug config options mount+umount works reliably. > So it looks like a timing issue / memory barrier issue - yuck. Since the issue is > so reliably produced it seems unlikely to be a barrier issue. > > There are lots of files in the shost sysfs folder - can any of these be used to > help debug? For my driver level debugging I normally use "logging_level" sysfs to enable and disable logs of different level during run time. For example to enable IO logging cat logging_level 00000201h echo 0x209 > logging_level cat logging_level 00000209h > > Thanks, > John Thanks, Ajish
