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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:27 EST