On 19.01.2011 [17:06:18 +1100], Benjamin Herrenschmidt wrote: > On Tue, 2011-01-18 at 16:48 -0800, Nishanth Aravamudan wrote: > > > > Ben, if you're ok with waiting to see if Milton or Sonny have any > > ideas, > > I'd like to hold off on asking for a revert. In the case they do, I'll > > be able to test and send out any proposed fix rapidly. > > I don't believe this specific error is causing the lockup, I think we > only hit a spurrious message on devices that don't have DMA > capabilities in the first place. (But I may be wrong, I'll wait for > you guys to dig more or I'll have a look myself tomorrow if I manage > to get out of meetings).
Yes, this seems accurate. Like I mentioned elsewhere, this box came up ok even with these messages and seemed ok (up until the disk locked up). > So there's another problem with SCSI tho it -could- also be a DMA issue, > hard to tell at this point. Right, I'm not sure how to determine that. I did see the lockup, though, with both my patches reverted (the patches for vio, I mean, after 2.6.37) > BTW. I'm not too happy with those defaults set to 64-bit. Probably not > an issue until your other patches go in, but some devices like veth > cannot do 64-bit DMA. I think we should default to 32-bit in the VIO > base code and explicitely enable 64-bit DMA from drivers that support it > (in theory vscsi but I haven't verified the implementation). Ok, so change the bit-mask to 32-bit? Or would it be appropriate to attempt 64-bit, if it fails fallback to 32-bit? Seems to be a common pattern throughout the DMA bit-setting callers. Thanks, Nish -- Nishanth Aravamudan <n...@us.ibm.com> IBM Linux Technology Center _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
