[BUG] flash failure with CONFIG_RTAS_FLASH=m

[BUG] flash failure with CONFIG_RTAS_FLASH=m

[Nathan Lynch]

Hi-

Was trying to flash firmware on a JS20 with the rtas flash code built
modular and I got the "kernel bug" printk in rtas_flash_firmware:

        /* NOTE: the "first" block list is a global var with no data
         * blocks in the kernel data segment.  We do this because
         * we want to ensure this block_list addr is under 4GB.
         */
        rtas_firmware_flash_list.num_blocks = 0;
        flist = (struct flash_block_list *)&rtas_firmware_flash_list;
        rtas_block_list = virt_to_abs(flist);
        if (rtas_block_list >= 4UL*1024*1024*1024) {
                printk(KERN_ALERT "FLASH: kernel bug...flash list
        header addr above 4GB\n");
                return;
        }

The problem doesn't happen if CONFIG_RTAS_FLASH=y.

What's the best way to fix this?  Should rtas_firmware_flash_list be
defined in some non-modular code and exported?

Re: [BUG] flash failure with CONFIG_RTAS_FLASH=m

[Olof Johansson]

On Thu, 4 Jan 2007 17:49:51 -0600 Nathan Lynch <ntl@pobox.com> wrote:

> The problem doesn't happen if CONFIG_RTAS_FLASH=y.
> 
> What's the best way to fix this?  Should rtas_firmware_flash_list be
> defined in some non-modular code and exported?

Makes sense to me.

You could allocate it dynamically really early (i.e. lmb_alloc) since
that's the only allocator that we can give limits to where in the
address range it can allocate. It seems to be overkill in this case
though, it's just a page worth of data.


-Olof

Re: [BUG] flash failure with CONFIG_RTAS_FLASH=m

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Thu, 2007-01-04 at 18:04 -0600, Olof Johansson wrote:
> On Thu, 4 Jan 2007 17:49:51 -0600 Nathan Lynch <ntl@pobox.com> wrote:
> 
> > The problem doesn't happen if CONFIG_RTAS_FLASH=y.
> > 
> > What's the best way to fix this?  Should rtas_firmware_flash_list be
> > defined in some non-modular code and exported?
> 
> Makes sense to me.
> 
> You could allocate it dynamically really early (i.e. lmb_alloc) since
> that's the only allocator that we can give limits to where in the
> address range it can allocate. It seems to be overkill in this case
> though, it's just a page worth of data.

There's the ZONE stuff, but it doesn't help us because our ZONE_DMA ==
all of ram - we'd need to add another ZONE below that, which is generic
code :/

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]