The reason it is failing is that the assigned IRQ is 0 or 255. If I
can't assume that that setup is done, I might as well start implementing
PCI resource allocation, because that is what is missing here.
The problem is not that the PCI device is not initialised, but that the
device is assigned a bogus irq (0/255) by the BIOS. It is allocated and
setup correctly as far as I can see from other PCI drivers. But then it
never fires, which is correct, because there is no such thing as irq 0
or 255. And that's were the driver freezes, waiting for an interrupt
that never comes and never times out or at least times out very slowly.
What John Polstra is suggesting is to check for these bogus values and
reject the device such that the boot will complete.
Or am I misunderstanding you completely, Mike?
> > The bottom line is this; in your driver, ask for the resources that you
> > need. If you don't get them, you fail. The PCI bus infrastructure is
> > being worked on to improve your chances of getting these resources; it's
> > not something that a driver writer should be worrying about per se.
> And I should probably have added; the assumptions you can make about the
> state of your device are very few. There is a *very* good chance that
> your device will *just* have been powered up, and had the BARs set to
> something sane. That's it. You should not make any assumptions about
> setup done by the BIOS, firmware, etc.
> ... every activity meets with opposition, everyone who acts has his
> rivals and unfortunately opponents also. But not because people want
> to be opponents, rather because the tasks and relationships force
> people to take different points of view. [Dr. Fritz Todt]
> V I C T O R Y N O T V E N G E A N C E
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
The USB for FreeBSD project.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message