Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Use PRIxPADDR to print a DMA address. This fix a problem that if_wm.c
can't compile with WM_DEBUG on non-64bit platforms.
sizeof(paddr_t) != sizeof(bus_addr_t) at least on sparc,
so using PRIx64 with an explicit (uint64_t) cast is
On Tue, Oct 09, 2012 at 01:36:07PM +, Manuel Bouyer wrote:
[...]
Log Message:
Support transfers of up to MACHINE_MAXPHYS in all pciide variants, and ahci.
wd(4) limits its maxphys depending on the drives's capability (64k sectors
for LBA48, 256 sectors for LBA and 128 sectors for older
Hi, tsutsui.
(2012/10/09 21:20), Izumi Tsutsui wrote:
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Use PRIxPADDR to print a DMA address. This fix a problem that if_wm.c
can't compile with WM_DEBUG on non-64bit platforms.
sizeof(paddr_t) != sizeof(bus_addr_t) at least on
On Tue, Oct 09, 2012 at 03:50:18PM +0200, Manuel Bouyer wrote:
On Tue, Oct 09, 2012 at 01:36:07PM +, Manuel Bouyer wrote:
[...]
Log Message:
Support transfers of up to MACHINE_MAXPHYS in all pciide variants, and ahci.
wd(4) limits its maxphys depending on the drives's capability (64k
On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
Hm.
This will be an attempt to transfer an entire file -- 139264 will be the
entire file size of something, probably an executable it's paging in.
I saw this before -- I can't remember what caused it -- the bad
On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
Hm.
This will be an attempt to transfer an entire file -- 139264 will be the
entire file size of something, probably an executable it's paging in.
On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
Hm.
This will be an attempt to transfer an entire file -- 139264 will be the
On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
Hm.
This will be an attempt to transfer an entire file -- 139264 will be the
On Tue, Oct 09, 2012 at 05:35:44PM +0200, Manuel Bouyer wrote:
On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
Hm.
This
On Tue, Oct 09, 2012 at 09:20:46AM -0700, Chuck Silvers wrote:
[...]
I wondered that myself. I think multiple of pagesize is probably okay,
but -- IIRC -- I couldn't convince myself we'd always do the right thing
with the residual. Try it?
the underlying mechanism used by the UVM read
On Tue, Oct 09, 2012 at 10:15:06PM +0200, Manuel Bouyer wrote:
Now, iostat -x shows that sequential read of a large file (either with cat
or dd bs=1m) is done in 32k transfers at the disk level. So I guess something
is not working properly here ...
I saw that too, though I managed to get 64K
On Tue, Oct 09, 2012 at 11:13:52PM +0200, Manuel Bouyer wrote:
There is still a reference to MAXPHYS in ufs_bmaparray(), which, if I got
it right, will limit the *runp in VOP_BMAP(), which will limit iobytes
in genfs_do_io().
but that doens't explain why I see 32k xfers. And, to make things
On Tue, Oct 09, 2012 at 11:50:27PM +0200, Manuel Bouyer wrote:
On Tue, Oct 09, 2012 at 11:13:52PM +0200, Manuel Bouyer wrote:
There is still a reference to MAXPHYS in ufs_bmaparray(), which, if I got
it right, will limit the *runp in VOP_BMAP(), which will limit iobytes
in genfs_do_io().
13 matches
Mail list logo
