Re: -CURRENT and -STABLE fails on IBM R30 in agp_ali.c

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Tue, 11 Nov 2003 16:41:10 -0500 (EST)
On 11-Nov-2003 Eric Anholt wrote:
> On Mon, 2003-11-10 at 13:50, Bjoern Fischer wrote:
>> Hello,
>> 
>> there is a problem in ali_agp.c (both, -CURRENT and -STABLE): If I
>> boot the generic kernel, it panics in agp_ali.c, when it tries to
>> allocate memory for the gatt. Some simlpe tests showed, that the
>> initial aperture size is reported as zero by the device:
>> 
>>   static int
>>   agp_ali_attach(device_t dev)
>>   {
>>        struct agp_ali_softc *sc = device_get_softc(dev);
>>        struct agp_gatt *gatt;
>>        int error;
>>   
>>        error = agp_generic_attach(dev);
>>        if (error)
>>                return error;
>>   
>>        sc->initial_aperture = AGP_GET_APERTURE(dev);
>> 
>> This is zero---------------------^^^^^^
>>   
>>        for (;;) {
>>                gatt = agp_alloc_gatt(dev);
>>                if (gatt)
>>                        break;
>>   
>>                /*
>>                 * Probably contigmalloc failure. Try reducing the
>>                 * aperture so that the gatt size reduces.
>>                 */
>>                if (AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2)) {
>>                        agp_generic_detach(dev);
>>                        return ENOMEM;
>>                }
>>        }
>>        sc->gatt = gatt;
>>   
>>        /* Install the gatt. */
>> 
>> Since I don't have a machine ready running -CURRENT, I can't really
>> debug this. How can I disable agp0 on boot time?
> 
> Would this be appropriate to commit to AGP, to disable the ali agp in
> case it reports 0 size (perhaps something in the BIOS has disabled it?)
> and to have agp_alloc_gatt() just fail instead of panicing in
> contigmalloc if the aperture size is 0?

Looks good to me.

-- 

John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
Received on Tue Nov 11 2003 - 12:41:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:28 UTC