Patch: sym(4) "VTOBUS FAILED" panics on amd64, amd64/89550

Jan Mikkelsen janm at transactionware.com
Sat Sep 23 15:40:34 PDT 2006


Stefan Esser wrote:
> I've been the co-author of the ncr SCSI driver, on which sym is based
> (though not that particular code fragment). Since I know the structure
> and principals of the driver (and since I have and know the docs up to
> the 53c875, possibly also the 53c895), I'd probably be in a position
> to work on this with the least effort to get started. Only problem is
> that I do not have an amd64 system for testing ...
> 
> I changed the private allocator in the sym driver to use contigmalloc,
> some time ago, but now I understand that there are stricter alignment
> requirements. For a start, a work-around could be committed, 
> IMHO (even
> if it is ugly). The better approach is of course an extension 
> of busdma
> to support aligned physical chunks as required by the driver.
> 
> But I could also try to find a clean fix for the affected driver code.

What are the "stricter alignment requirements" you have seen?  The only ones
I have seen are those on virtual addresses caused by the buddy allocator.
Replacing that would remove the virtual address alignment requirements,
unless I've missed something else.

Are there special physical alignment requirements that the driver is not
currently meeting?

> Is the Symbios SCSI controller still used that much that the effort
> required for a "clean" fix is well spent?

This is a broader question.  For my immediate purposes, my patch and wasting
a few pages gets a functional tape drive, which is a reasonable tradeoff to
me.  I don't know how anyone else feels.  This does seem to have been broken
on amd64 for a while and I haven't seen a large number of messages
complaining.

However:  I needed an inexpensive SCSI controller for a machine, looked at
the supported hardware list, and bought a sym(4) controller.  It didn't
work.  I think either the driver or the supported hardware list should be
fixed;  my preference is the driver.

Regards,

Jan.



More information about the freebsd-stable mailing list