Re: 2.6.37-git17 virtual IO boot failure

On 19.01.2011 [17:06:18 +1100], Benjamin Herrenschmidt wrote:

On Tue, 2011-01-18 at 16:48 -0800, Nishanth Aravamudan wrote:

quoted

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 [off-list ref]
IBM Linux Technology Center