[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#338089: New aic7xxx driver fails spectacularly on 2940UW



James Bottomley wrote:
On Sun, 2005-11-13 at 13:03 -0500, Graham Knap wrote:

Doug Ledford <dledford@redhat.com> wrote:

You already said it didn't help with the problem,

I meant that I don't think I successfully disabled DV, because the boot
messages were *identical*, except for the line where the kernel shows
the "Kernel command line".

I had added this argument at the end of the line:  aic7xxx=dv:{0}

I've re-read "aic7xxx.txt" and I'm not sure what I'm doing wrong. If
you can tell me how to disable DV, I'd be happy to give it a try.


aic7xxx.txt is out of date.  The aic7xxx (and 79xx) drivers use the
generic domain validation code now rather than the old aic specific ones
(which is what the dv:{0} option is referring to).  If you try the code
in the prior email, I think that will disable the piece of DV that's
causing the problem.

If the test code succeeds, the problem is pretty nasty:  Apparently the
device claims DT support but in fact rejects DT in the negotiation.  We
use DT support to begin the check for an echo buffer, which starts with
READ_BUFFERS for the descriptor.  Apparently this device returns a valid
descriptor with a reasonable echo buffer size and then promptly throws a
wobbly when we try to use it.

James


The device is on a non-LVD bus. Certain devices were created back when the spec still stated that using PPR negotiation messages on a non-LVD bus was a no-no. As the echo buffer was an addition to support DV, and originally DV wasn't intended to be used on non-LVD busses, it might stand to reason that this device simply is going tits up because we are attempting to use the echo buffer while in SE mode. Checking that PPR/DT is valid (not just between controller and device, but also given bus mode) and only using echo buffer DV when all LVD conditions are met would likely solve the problem (assuming that the problem is what you are referring to).

--
Doug Ledford <dledford@redhat.com>
http://people.redhat.com/dledford




Reply to: