Messages in this thread | | | Date | Tue, 10 Jun 2003 21:16:07 -0700 | From | Andrew Morton <> | Subject | Re: 2.5.70-bk radeonfb oops on boot. |
| |
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/
| |