Re: 2.5.70-bk radeonfb oops on boot.

[Andrew Morton <akpm@digeo.com>]

Simon Fowler <simon@himi.org> wrote:
>
> > > > 
> > > > It might be worth reverting this chunk, see if that fixes it:
> > > > 
> > > > --- b/drivers/char/mem.c        Thu Jun  5 23:36:40 2003
> > > > +++ b/drivers/char/mem.c        Sun Jun  8 05:02:24 2003
> > > > @@ -716 +716 @@
> > > > -__initcall(chr_dev_init);
> > > > +subsys_initcall(chr_dev_init);
> > > > 
> > > And we have a winner . . . Reverting this hunk fixes the oops.
> > > 
> > 
> > So it's another initcall problem in the PCI layer.
> > 
> > pci_enable_device_bars() is needing things which are not yet set up.  A lot
> > of the PCI initialisation is at subsys_initcall() as well, and you got
> > unlucky with link order.
> > 
> > I expect the below patch will fix this as well.  Could you please put the
> > above change back to normal and see if this one fixes it?
> > 
> I applied this to a clean 2.5.70-bk14 tree, and it failed to boot -
> I've copied the output after switching to the framebuffer:
> 
> --------------------------------------------------
> onsole: switching to colour frame buffer device 160x48
> pty: 256 Unix98 ptys configured.
> block request queues:
>   4/128 requests per read queue
>   4/128 requests per write queue
>   Enter congestion at 15
>   Exit congestion at 17
> PCI: Cannot allocate resource region 0 of device 00:14.0
> PCI: Cannot allocate resource region 2 of device 00:14.0
> --------------------------------------------------
> 
> 00:14.0 is the Radeon.

Thanks for testing.

All the initcall ordering of chardevs versus pci, pci versus pci and who
knows what else is all bollixed up.

Unfortunately I do not have the bandwidth to work on this.