linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Kernel cannot allocate resource region
@ 2001-11-02  3:13 tahoward
  2001-11-02  8:34 ` Michael Schmitz
  0 siblings, 1 reply; 6+ messages in thread
From: tahoward @ 2001-11-02  3:13 UTC (permalink / raw)
  To: linuxppc-dev


Hi.  I've been trying to get 2.4 series kernels to work, but they always
have hung very early in booting, and never printed anything on the screen.
It just occurred to me to try booting with the console on a serial port,
and I got the following message using 2.4.14-pre3 from source.mvista.com:

PCI: Probing PCI hardware
PCI:00:0e.0: Resource 0: 84000000-87ffffff (f=1208)
PCI:00:0e.0: Resource 2: 80804000-80807fff (f=200)
PCI:00:10.0: Resource 0: f3000000-f307ffff (f=200)
PCI:00:0d.0: Resource 0: 80801000-80801fff (f=1208)
PCI:00:0e.0: Resource 1: 00000400-000004ff (f=101)
PCI:00:11.0: Resource 0: 00000400-0000047f (f=101)
PCI: Cannot allocate resource region 0 of device 00:11.0
PCI:  parent is c041b030: 00000000-007fffff (f=100)
PCI:00:11.0: Resource 1: 80800000-8080007f (f=200)
Macinto

Nothing more ever appears.  Here is the output from lspci -v under 2.2.19:

00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev
03)
        Flags: bus master, medium devsel, latency 32

00:0d.0 Multimedia video controller: Brooktree Corporation Bt848 TV with
DMA push (rev 12)
        Flags: bus master, medium devsel, latency 32, IRQ 23
        Memory at 80801000 (32-bit, prefetchable) [disabled]

00:0e.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE
(prog-if 00 [VGA])
        Subsystem: Unknown device b530:0408
        Flags: bus master, stepping, medium devsel, latency 32, IRQ 25
        Memory at 84000000 (32-bit, prefetchable)
        I/O ports at 0400
        Memory at 80804000 (32-bit, non-prefetchable)
        Expansion ROM at 80820000 [disabled]
        Capabilities: [5c] Power Management version 1

00:10.0 Class ff00: Apple Computer Inc. O'Hare I/O (rev 01)
        Flags: bus master, medium devsel, latency 32
        Memory at f3000000 (32-bit, non-prefetchable)

00:11.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 30)
        Subsystem: Standard Microsystems Corp [SMC]: Unknown device 2401
        Flags: bus master, medium devsel, latency 32, IRQ 22
        I/O ports at 0400
        Memory at 80800000 (32-bit, non-prefetchable) [disabled]
        Expansion ROM at 80840000 [disabled]

I'm guessing that there is a conflict between my ethernet and video cards,
but I don't know what to do to resolve it.  Any suggestions?  I don't know
if it matters, but I'm using BootX 1.2.2

Tony


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Kernel cannot allocate resource region
  2001-11-02  3:13 Kernel cannot allocate resource region tahoward
@ 2001-11-02  8:34 ` Michael Schmitz
  2001-11-03  4:11   ` tahoward
  0 siblings, 1 reply; 6+ messages in thread
From: Michael Schmitz @ 2001-11-02  8:34 UTC (permalink / raw)
  To: tahoward; +Cc: linuxppc-dev


> PCI: Cannot allocate resource region 0 of device 00:11.0
> 00:0e.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE
> (prog-if 00 [VGA])
>         Subsystem: Unknown device b530:0408
>         Flags: bus master, stepping, medium devsel, latency 32, IRQ 25
>         Memory at 84000000 (32-bit, prefetchable)
>         I/O ports at 0400
>         Memory at 80804000 (32-bit, non-prefetchable)
>         Expansion ROM at 80820000 [disabled]
>         Capabilities: [5c] Power Management version 1
>
> 00:11.0 Ethernet controller: Digital Equipment Corporation DECchip
> 21142/43 (rev 30)
>         Subsystem: Standard Microsystems Corp [SMC]: Unknown device 2401
>         Flags: bus master, medium devsel, latency 32, IRQ 22
>         I/O ports at 0400
>         Memory at 80800000 (32-bit, non-prefetchable) [disabled]
>         Expansion ROM at 80840000 [disabled]
>
> I'm guessing that there is a conflict between my ethernet and video cards,

Yep, it seems like the MMIO aperture for the video card might overlap the
ethernet controller memory resource (depending on the size of that memory
resource).

It should never hang in that case though. And I thought the initial PCI
resource allocation takes care of resolving overlaps?

Can you boot some other way (i.e. no BootX)?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Kernel cannot allocate resource region
  2001-11-02  8:34 ` Michael Schmitz
@ 2001-11-03  4:11   ` tahoward
  2001-11-04 14:17     ` Michael Schmitz
  0 siblings, 1 reply; 6+ messages in thread
From: tahoward @ 2001-11-03  4:11 UTC (permalink / raw)
  To: Michael Schmitz; +Cc: linuxppc-dev


I tried miboot, and it worked, but everything was VERY slow.  After
thinking about it, I realized my G3 processor was not enabled.  My machine
has a Sonnet G3 upgrade in its L2 cache slot, and it needs a MacOS
extension to enable it.

Then, I tried using BootX with the extension disabled, and 2.4 booted.  In
both cases, I still got the "cannot allocate resource region" message, but
video and ethernet both work fine.  I'm guessing this may be a red herring.

I'm wondering if it's significant that the last message printed before the
hang (it's not a panic, no reboot after 180 seconds) is "Macinto"?  When
I boot without the G3 enabled, the full line is:
Macintosh CUDA driver v0.5 for Unified ADB.

Tony

On Fri, 2 Nov 2001, Michael Schmitz wrote:

>
> > PCI: Cannot allocate resource region 0 of device 00:11.0
> > 00:0e.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE
> > (prog-if 00 [VGA])
> >         Subsystem: Unknown device b530:0408
> >         Flags: bus master, stepping, medium devsel, latency 32, IRQ 25
> >         Memory at 84000000 (32-bit, prefetchable)
> >         I/O ports at 0400
> >         Memory at 80804000 (32-bit, non-prefetchable)
> >         Expansion ROM at 80820000 [disabled]
> >         Capabilities: [5c] Power Management version 1
> >
> > 00:11.0 Ethernet controller: Digital Equipment Corporation DECchip
> > 21142/43 (rev 30)
> >         Subsystem: Standard Microsystems Corp [SMC]: Unknown device 2401
> >         Flags: bus master, medium devsel, latency 32, IRQ 22
> >         I/O ports at 0400
> >         Memory at 80800000 (32-bit, non-prefetchable) [disabled]
> >         Expansion ROM at 80840000 [disabled]
> >
> > I'm guessing that there is a conflict between my ethernet and video cards,
>
> Yep, it seems like the MMIO aperture for the video card might overlap the
> ethernet controller memory resource (depending on the size of that memory
> resource).
>
> It should never hang in that case though. And I thought the initial PCI
> resource allocation takes care of resolving overlaps?
>
> Can you boot some other way (i.e. no BootX)?
>
> 	Michael
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Kernel cannot allocate resource region
  2001-11-03  4:11   ` tahoward
@ 2001-11-04 14:17     ` Michael Schmitz
  2001-11-04 20:16       ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 6+ messages in thread
From: Michael Schmitz @ 2001-11-04 14:17 UTC (permalink / raw)
  To: tahoward; +Cc: linuxppc-dev


> I'm wondering if it's significant that the last message printed before the
> hang (it's not a panic, no reboot after 180 seconds) is "Macinto"?  When
> I boot without the G3 enabled, the full line is:
> Macintosh CUDA driver v0.5 for Unified ADB.

That may be a timing difference hitting in some driver - in the m68k ADB
code, I had been using a local (stack) adb_request struct for some
asyncronous ADB request. Most of the time the async operation would
complete while that variable was still valid (the calling routine hadn't
returned yet). Someetimes it would only complete later ;-(

The current ADB code should be free from such gross errors, but maybe
something else doesn't cope with async probing of devices? ADB probing
happens asynchronously these days (but then, BenH won't have used
non-static variables for that). And I'd expect the kernel to throw a
panic() for data or illegal instruction errors. Maybe some deadlock - what
other task is active during ADB probe?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Kernel cannot allocate resource region
  2001-11-04 14:17     ` Michael Schmitz
@ 2001-11-04 20:16       ` Benjamin Herrenschmidt
  2001-11-06  7:32         ` tahoward
  0 siblings, 1 reply; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2001-11-04 20:16 UTC (permalink / raw)
  To: Michael Schmitz; +Cc: linuxppc-dev, tahoward


>That may be a timing difference hitting in some driver - in the m68k ADB
>code, I had been using a local (stack) adb_request struct for some
>asyncronous ADB request. Most of the time the async operation would
>complete while that variable was still valid (the calling routine hadn't
>returned yet). Someetimes it would only complete later ;-(
>
>The current ADB code should be free from such gross errors, but maybe
>something else doesn't cope with async probing of devices? ADB probing
>happens asynchronously these days (but then, BenH won't have used
>non-static variables for that). And I'd expect the kernel to throw a
>panic() for data or illegal instruction errors. Maybe some deadlock - what
>other task is active during ADB probe?

Well, it' s possible that I left or added such bugs ;)

If you are using my rsync tree (or since recently the bk _devel tree),
there's an "adb_sync" option you can add to your kernel command line
to force ADB probe to be synchronous.

Tell me if that helps.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Kernel cannot allocate resource region
  2001-11-04 20:16       ` Benjamin Herrenschmidt
@ 2001-11-06  7:32         ` tahoward
  0 siblings, 0 replies; 6+ messages in thread
From: tahoward @ 2001-11-06  7:32 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: Michael Schmitz, linuxppc-dev


I had been using the bk linuxppc_2_4 tree.  I tried the _devel tree, and
it worked both with and without adb_sync, so all seems well.  Thanks!

Tony

On Sun, 4 Nov 2001, Benjamin Herrenschmidt wrote:

>
> >That may be a timing difference hitting in some driver - in the m68k ADB
> >code, I had been using a local (stack) adb_request struct for some
> >asyncronous ADB request. Most of the time the async operation would
> >complete while that variable was still valid (the calling routine hadn't
> >returned yet). Someetimes it would only complete later ;-(
> >
> >The current ADB code should be free from such gross errors, but maybe
> >something else doesn't cope with async probing of devices? ADB probing
> >happens asynchronously these days (but then, BenH won't have used
> >non-static variables for that). And I'd expect the kernel to throw a
> >panic() for data or illegal instruction errors. Maybe some deadlock - what
> >other task is active during ADB probe?
>
> Well, it' s possible that I left or added such bugs ;)
>
> If you are using my rsync tree (or since recently the bk _devel tree),
> there's an "adb_sync" option you can add to your kernel command line
> to force ADB probe to be synchronous.
>
> Tell me if that helps.
>
> Ben.
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-11-06  7:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-11-02  3:13 Kernel cannot allocate resource region tahoward
2001-11-02  8:34 ` Michael Schmitz
2001-11-03  4:11   ` tahoward
2001-11-04 14:17     ` Michael Schmitz
2001-11-04 20:16       ` Benjamin Herrenschmidt
2001-11-06  7:32         ` tahoward

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).