ZFS checksum errors on umass(4) insertion

John Baldwin jhb at freebsd.org
Thu Apr 16 22:04:49 UTC 2009

On Thursday 16 April 2009 5:53:35 pm Scott Long wrote:
> John Baldwin wrote:
> > On Thursday 16 April 2009 5:32:52 pm Scott Long wrote:
> >> John Baldwin wrote:
> >>> Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch?  
> >>> lines up with your analysis in that it fixes a problem in the bounce 
> > buffer
> >>> code that was introduced with the new USB stack (and only triggers when 
> > the
> >>> USB code has to use a bounce buffer).
> >>>
> >> As a data point, most normal I/O is not going to trigger this bug, even
> >> if it gets bounced.  I/O using O_DIRECT can, and GEOM discovery I/O can
> >> as well.  Since memory is allocated from the top of the system, I think
> >> that the damage gets done early during boot, and then propagates out
> >> over time as the system becomes busier.
> > 
> > Hmm, are you sure regular I/O won't trigger it as well?  All it takes is 
> > any USB transfer that starts off within a page to get a page into a 
> > offset and later have a request >= PAGE_SIZE bounce.  Since the VM is 
> > to always ask for I/O to pages (e.g. GET/PUTPAGES) normal disk I/O would 
> > break if it uses the bad bounce page I think.
> > 
> Sorry, I knew what I meant but didn't say it that well.  Once it gets 
> triggered, it poisons that bounce page from thereon out, and any I/O 
> will be affected.  But the only I/O that will typically trigger it is 
> GEOM scanning and O_DIRECT.

Ah, ok.  Actually, couldn't any USB request trigger it (so long as the source 
buffer isn't page aligned?)  E.g. if you malloc()'d a 16-byte buffer and used 
it to receive some descriptor for the keyboard driver and malloc() used a 
backing page > 4GB, wouldn't that bounce and end up breaking a bounce page?

John Baldwin

More information about the freebsd-current mailing list