????: Help:why bus resource shortage?

Gerald Heinig gheinig at syskonnect.de
Fri Jun 30 09:13:32 UTC 2006


Hi Guys,

On Fri, 2006-06-30 at 01:16 -0700, John-Mark Gurney wrote:
> hongz at promisechina.com wrote this message on Fri, Jun 30, 2006 at 14:26 +0800:
> > I found the problem! It was caused by an existed ata driver in FreeBSD. I
> > have mentioned before that the existed ata driver can take over the
> > management of our HBA card, leading to our driver can not probe our card! By
> > getting rid of the ID in ata-chipset.c,we can probe the HBA card, but we
> > still can not get the pci resources! Instead, I can get rid of the effects
> > of the existed ata driver by only getting rid of the ID in probe function of
> > ata-pci.c!  
> 
> This has now been fixed by making the built in driver return a negative
> value for the probe.. so your probe routine can return 0, and it will
> win the probe for the device...

Minor nitpick: it may perhaps be better to return a smaller negative
value (eg. -5) rather than 0. IIRC -10 is the default score used by
standard system drivers and 0 is the highest score available. If someone
wants to use an alternative driver to Hong's and the standard system's
it won't attach.

> 
> > In summon, the problems (probe failure and bus resource short) lie in the
> 
> hmm. that seems wierd, are you trying to allocate the resource in the
> _probe function?  You shouldn't need to unless you need to do special
> munging of the resources to properly identify the device..  and unless
> you return 0 from your _probe function, you will have to release the
> resrouce at the end of the _probe function...
> 
> > ata driver in FreeBSD, which can recognize our HBA card because it records
> > the ID of this HBA. By getting rid of the switch case of this ID in probe
> > function of ata-pci.c, you can take over the HBA completely.
> > 
> > Here, I would like to report my solution (not tested yet) on a previous
> > question about how to transfer physical address into kernel virtual address
> > in FreeBSD:
> 
> That is what the bus_space api is for...  The method you propose is a
> hack and not very useful for ensuring that your driver run on other
> platforms...
> 
> > -----????????-----
> > ??????: John-Mark Gurney [mailto:gurney_j at resnet.uoregon.edu] 
> > ????????: 2006??6??30?? 6:36
> > ??????: hongz at promisechina.com
> > ????: freebsd-hackers at freebsd.org
> > ????: Re: Help:why bus resource shortage?
> > 
> > hongz at promisechina.com wrote this message on Thu, Jun 15, 2006 at 14:55
> > +0800:
> > > I failed to get the pci bus resource after the driver is loaded (sc->r_mem
> > > is NULL after bus_alloc_resource_any is called). Is it because bus
> > resources
> > > have been consumed by other drivers? Or other something happened? Please
> > > help me on this!
> > 
> > Please provide a verbose boot (boot -v) output of the pci card...
> > 
> > > rid = 0x10;
> > 
> > You really should be using PCIR_BAR macro instead of hard coding it...
> > 
> > > sc->r_mem = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &rid,
> > > RF_ACTIVE);
> > > 
> > > if (!sc->r_mem) return ENOMEM;
> > > 
> > >  
> > > 
> > > The pci resources on our cards:
> > > 
> > > shasta0: <Promise FastTrak 4310/579/779 Driver> port 0x2400-0x247f,
> > > 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe9000000-0xe901ffff irq 17 at
> > > device 5.0 on pci2
> > 
> > The resources could be in a different order than listed...  Are you
> > sure the memory resource is in the first bar possition?
> 


More information about the freebsd-hackers mailing list