On Fri, 29 Aug 2014, Mike Belopuhov wrote: > On 29 August 2014 11:26, Stefan Fritsch <s...@sfritsch.de> wrote: > > On Fri, 29 Aug 2014, Miod Vallat wrote: > >> > sc->sc_xfer_max is computed according to the host's capabilities. What I > >> > want to simulate with this diff is a host adapter that can only cope with > >> > transfers < 64k == MAXPHYS. > >> > >> Back to your original problem, you might want to print the sc_link > >> struct as well the scsi_adapter struct it points to, when you detect a > >> transfer larger than MAXPHYS. It has likely been overriden or reset to > >> NULL by mistake at some point. > > > > OK, I will try that. Will take a bit until I have time, though.
That's not the problem. I have added an additional KASSERT(xs->sc_link->adapter->scsi_minphys == vioblk_minphys) before the other KASSERT and it did not trigger. > > But I have also read the code and I could not find a place in the path > > from bread() to the scsi adapter cmd function where the minphys function > > is called. > > > > correct me if i'm wrong, but what happens is that bread being a block > read reads up to MAXBSIZE which is conveniently set to 64k and you can't > create a filesystem with a larger block size. > > physio (raw device io) however doesn't go through bread and need to know > how split the provided buffer in separate transactions hence minphys. Yes, that seems to be what happens. But if every adapter needs to support transfers of MAXBSIZE == MAXPHYS anyway, there would be no need for the adapter to be able to override the default minphys function with its own. And adapters that only support smaller transfers would need to have logic in their driver to be able to split the transfer into smaller chunks. I think it makes more sense to have that logic in one place to be used by all drivers.
