From: Robert E Brose II <hidden> Date: 2003-11-03 03:35:29
In trying to get OpenGL working on a YDL 3.0 system with kernel 2.4.22-ben2
and XFree86-4.3.0-2.1e, I get a warning on X initialization:
(II) R128(0): [drm] failure adding irq handler, there is a device already using
that irq
Digging into it more, I'm having a hard time understanding why there is a
problem and how the interrupts are allocated on a S900 (w/G3 card).
With the folowing configuration:
Slot 1:
00:0d.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG (prog-if 00 [VGA])
Flags: bus master, stepping, medium devsel, latency 32, IRQ 23
Slot 2:
00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 21)
Flags: bus master, medium devsel, latency 32, IRQ 24
Slot 3:
01:00.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 04)
Flags: bus master, medium devsel, latency 32, IRQ 25
Slot 4:
01:01.0 Communication controller: Comtrol Corporation RocketPort 8 Intf (rev 02)
Flags: medium devsel, IRQ 25
Slot 5:
01:02.0 FireWire (IEEE 1394): Texas Instruments FireWire Controller (rev 01) (pr
og-if 10 [OHCI])
Flags: bus master, medium devsel, latency 32, IRQ 25
Slot 6:
01:03.0 USB Controller: Lucent Microelectronics USS-312 USB Controller (rev 10)
(prog-if 10 [OHCI])
Flags: bus master, medium devsel, latency 32, IRQ 25
and /proc/interrupts
2: 0 PMAC-PIC Edge MACE-txdma
3: 77087 PMAC-PIC Edge MACE-rxdma
8: 345 PMAC-PIC Edge Built-in Sound out
9: 0 PMAC-PIC Edge Built-in Sound in
13: 71 PMAC-PIC Edge MESH
14: 77840 PMAC-PIC Edge MACE
17: 0 PMAC-PIC Edge Built-in Sound misc
18: 4352 PMAC-PIC Edge ADB
19: 0 PMAC-PIC Edge SWIM3
24: 21259 PMAC-PIC Level eth0
25: 72922493 PMAC-PIC Level sym53c8xx, usb-ohci, ohci1394
A couple of things right off, the rage128 appears to be the only thing on
irq 23 however 23 doesn't show up in /proc/interrupts meaning, I suppose,
that it's not using the interrupt. So why does the drm complain?
How come everything from slots 3-6 says it's on the same interrupt (25)?
Bob
--
/~\ The ASCII | Robert E. Brose II N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
X Help cure | mailto:bob@qbjnet.com
/ \ HTML Email | public key at http://www.qbjnet.com/key.html
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-11-03 06:54:41
On Mon, 2003-11-03 at 14:35, Robert E Brose II wrote:
A couple of things right off, the rage128 appears to be the only thing on
irq 23 however 23 doesn't show up in /proc/interrupts meaning, I suppose,
that it's not using the interrupt. So why does the drm complain?
How come everything from slots 3-6 says it's on the same interrupt (25)?
I don't know what's up with the DRM not liking your interrupt. I can
answer for the sharing of USB, symbios and firewire interrupts: all 3
slots share one interrupt because of bad motherboard design :)
Basicallly, what they did when designing that machine was to use a
standard powersurge design with 3 slots and replace one of them
with a PCI<->PCI bridge. Since they didn't "know" how to get more
interrupt lines out of Grand Central, they just also stuffed all
interrupt lines together for those 4 slots (I'm pretty sure GC do
have spare lines they could have used, but that would have meant
updating Open Firmware to understand the layout, I doubt the people
who designed that machine wanted to dive into that).
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Dänzer <hidden> Date: 2003-11-03 11:30:24
On Mon, 2003-11-03 at 04:35, Robert E Brose II wrote:
In trying to get OpenGL working on a YDL 3.0 system with kernel 2.4.22-ben2
and XFree86-4.3.0-2.1e, I get a warning on X initialization:
(II) R128(0): [drm] failure adding irq handler, there is a device already using
that irq
Not sure what's up with that (depending on how old the DRM is, the error
could be misleading though), but this shouldn't prevent the DRI from
working.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Bob Brose <hidden> Date: 2003-11-03 14:11:25
User Benjamin Herrenschmidt says:
On Mon, 2003-11-03 at 14:35, Robert E Brose II wrote:
quoted
A couple of things right off, the rage128 appears to be the only thing on
irq 23 however 23 doesn't show up in /proc/interrupts meaning, I suppose,
that it's not using the interrupt. So why does the drm complain?
How come everything from slots 3-6 says it's on the same interrupt (25)?
I don't know what's up with the DRM not liking your interrupt. I can
answer for the sharing of USB, symbios and firewire interrupts: all 3
slots share one interrupt because of bad motherboard design :)
Basicallly, what they did when designing that machine was to use a
standard powersurge design with 3 slots and replace one of them
with a PCI<->PCI bridge. Since they didn't "know" how to get more
interrupt lines out of Grand Central, they just also stuffed all
interrupt lines together for those 4 slots (I'm pretty sure GC do
have spare lines they could have used, but that would have meant
updating Open Firmware to understand the layout, I doubt the people
who designed that machine wanted to dive into that).
Ben.
I suppose then that I should reorder the cards so that the ones generating
the most interrupts would be in the first 2 slots? It's pretty funny
having the possibility of the use of lots of irqs then ending up with
x86 style sharing. :(
Bob
--
/~\ The ASCII | Robert E. Brose II N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
X Help cure | mailto:bob@qbjnet.com
/ \ HTML Email | public key at http://www.qbjnet.com/key.html
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, 2003-11-03 at 14:35, Robert E Brose II wrote:
quoted
A couple of things right off, the rage128 appears to be the only thing on
irq 23 however 23 doesn't show up in /proc/interrupts meaning, I suppose,
that it's not using the interrupt. So why does the drm complain?
How come everything from slots 3-6 says it's on the same interrupt (25)?
I don't know what's up with the DRM not liking your interrupt. I can
answer for the sharing of USB, symbios and firewire interrupts: all 3
slots share one interrupt because of bad motherboard design :)
Basicallly, what they did when designing that machine was to use a
standard powersurge design with 3 slots and replace one of them
with a PCI<->PCI bridge. Since they didn't "know" how to get more
interrupt lines out of Grand Central, they just also stuffed all
interrupt lines together for those 4 slots (I'm pretty sure GC do
Tsss... They could at least have `swizzled' the lines...
quoted
have spare lines they could have used, but that would have meant
updating Open Firmware to understand the layout, I doubt the people
who designed that machine wanted to dive into that).
Ben.
I suppose then that I should reorder the cards so that the ones generating
the most interrupts would be in the first 2 slots? It's pretty funny
having the possibility of the use of lots of irqs then ending up with
x86 style sharing. :(
Yes, try to spread out interrupts evenly across interrupt lines.
Furthermore the presence of the bridge will probably incur a slight slowdown
for the last 3 slots, too. Don't know whether it's significant (should reread
PCI specs first).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Robert E. Brose II <hidden> Date: 2003-11-03 14:40:58
Michel Dänzer wrote:
On Mon, 2003-11-03 at 04:35, Robert E Brose II wrote:
quoted
In trying to get OpenGL working on a YDL 3.0 system with kernel 2.4.22-ben2
and XFree86-4.3.0-2.1e, I get a warning on X initialization:
(II) R128(0): [drm] failure adding irq handler, there is a device already using
that irq
Not sure what's up with that (depending on how old the DRM is, the error
could be misleading though), but this shouldn't prevent the DRI from
working.
The reason I was wondering about the IRQ is I've been trying to get 3d
stuff (like tuxracer) to run and I get the error message:
*** tuxracer error: Couldn't initialize video: X11 driver not configured
with OpenGL (Success)
Now the glxgears programs runs with about 400 fps (1024x768x24 400 mhz g3)
I can't run tuxracer compiled by me or the stock ydl3.0 one. Other 3d
stuff I compile fails as well with the same message. I'm pretty sure I
have the X and kernel configuration right. (similar settings work on an
x86 box with a 3dfx card).
Load "GLcore"
Load "dbe"
Load "extmod"
Load "fbdevhw"
Load "dri"
Load "glx"
Load "record"
Load "freetype"
Load "type1"
And I'm building the kernel with 4.1 rage 128 drm support and the r128
module is loaded and there are no errors on X startup other than that
IRQ error (which is also noted in the dmesg when the r128 kernel module
loads)
also glxinfo looks ok to me so I'm having a hard time figuring out the
problem.
root# glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: VA Linux Systems, Inc.
OpenGL renderer string: Mesa DRI Rage128 20020221 AGP 1x
OpenGL version string: 1.2 Mesa 4.0.4
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram,
GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object,
GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos,
GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
Any more suggestions are appreciated!
Thanks,
Bob
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-11-03 21:40:55
I suppose then that I should reorder the cards so that the ones generating
the most interrupts would be in the first 2 slots? It's pretty funny
having the possibility of the use of lots of irqs then ending up with
x86 style sharing. :(
From: Jeff Walther <hidden> Date: 2003-11-04 08:55:40
At 17:54 +1100 11/03/2003, Benjamin Herrenschmidt wrote:
On Mon, 2003-11-03 at 14:35, Robert E Brose II wrote:
quoted
A couple of things right off, the rage128 appears to be the only thing on
irq 23 however 23 doesn't show up in /proc/interrupts meaning, I suppose,
that it's not using the interrupt. So why does the drm complain?
How come everything from slots 3-6 says it's on the same interrupt (25)?
I don't know what's up with the DRM not liking your interrupt. I can
answer for the sharing of USB, symbios and firewire interrupts: all 3
slots share one interrupt because of bad motherboard design :)
I'm not sure it was bad motherboard design--at least, not unless
following specifications leads to bad motherboard design. I can't
find the reference now, but I could swear that I read that the proper
procedure when implementing a PCI-PCI Bridge is to tie the
subordinate slot's interrupts into the interrupt for the host slot.
The firmware for the host machine is supposed to be able to sort this
out, if written properly.
After all, one can, in theory, add 1024 PCI slots to a machine using
PPBs. There aren't going to be 1024 interrupts available. The
specification for PCI-PCI Bridges had to have some more general
method of handling interrupts for slots behind a PPB, and tieing them
to the host slot interrupt makes the most sense.
All that said, the firmware for the x500 and x600 Macs is not written
properly, at least with respect to implementing PCI-PCI Bridges.
Basicallly, what they did when designing that machine was to use a
standard powersurge design with 3 slots and replace one of them
with a PCI<->PCI bridge. Since they didn't "know" how to get more
interrupt lines out of Grand Central, they just also stuffed all
interrupt lines together for those 4 slots (I'm pretty sure GC do
have spare lines they could have used,
The interrupts for the slots (in the 9500/9600) go to the following pins on GC:
Slot # GC pin #
1 193
2 194
3 189
4 188
5 173
6 174
On the S900 (and J700) the interrupts for slots 3 through 6 are tied
to pin 189.
Slots 1 through 3 are also correct for all other PowerSurge machines.
I would love to know if there are other unused interrupts available,
as the PowerSurge architecture supposedly can support up to four
Bandit chips, but as far as I know, if one constructed such a beast,
there'd be no interrupts available for any PCI slots beyond six.
This seems to be born out (limited interrupts available) by the
gymnastics they went through to arrange the interrupts in the Apple
Network Server, which has six PCI slots, but also four built-in PCI
devices (including Grand Central) on the motherboard. They didn't
use any previously unused interrupts on GC in the ANS, they just
rearranged and combined the interrupts used in the 9500.
However, I can't help but wonder if all that lovely video circuitry
on the 7500 and 8500 requires any interrupts and if so, where they
come from. Do they recycle the interrupts for slots 4 -6 or are
there other interrupts available on GC besides the ones for the six
slots?
but that would have meant
updating Open Firmware to understand the layout, I doubt the people
who designed that machine wanted to dive into that).
At 14:16 +1100 11/04/2003, Benjamin Herrenschmidt wrote:
Probably because updating Apple's 1.0.5 OF code to assign them properly
with the P2P setup was beyond their ability to deal with crappy code :)
What is P2P setup?
The cloners just soldered Apple ROMs down in their machines. The
ROM/firmware used in the PowerComputing and Umax machines (except
PowerBase and C series) was the same ROM/firmware used in the x500
series of machines--the $77D.28F2. This ROM was used in the 7200,
7500, 8500, 9500, all of PCC's Catalyst clones, PowerWave, PowerTower
Pro, S900 and the J700.
I'm not sure if the cloner's license even allowed them to modify the
ROM. The chips are labeled with Apple part numbers and Apple
markings, so I think they really did purchase them from Apple, rather
than licensing their production.
Anyway, the point being that even if Umax had wanted to go that route
(rewrite/modify/fix OF 1.05), I'm not sure it was technically
feasible under the licensing agreement. Is hacking the interrupt
assignment for the PCI slots the kind of thing one could squeeze into
the NVRAMrc?
Jeff Walther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-11-04 09:14:29
I'm not sure it was bad motherboard design--at least, not unless
following specifications leads to bad motherboard design. I can't
find the reference now, but I could swear that I read that the proper
procedure when implementing a PCI-PCI Bridge is to tie the
subordinate slot's interrupts into the interrupt for the host slot.
The firmware for the host machine is supposed to be able to sort this
out, if written properly.
Hrm... nah nah nah :) If you tie them together, you get one
interrupt shared for all in the end... what you can do on
platforms with an irq router like x86 is to make use of the
4 different irq lines of the bridge and route them to the
sub-slots, but on macs, like on lots of othre platforms, the
4 lines are just or-ed together.
Anyway, such a rule really only apply when you design a PCI
card with a P2P bridge on it. As long as you are on the
motherboard, you do what you want.
After all, one can, in theory, add 1024 PCI slots to a machine using
PPBs. There aren't going to be 1024 interrupts available.
Why ? Some iSeries have up to 2048 irq lines afaik ;)
The
specification for PCI-PCI Bridges had to have some more general
method of handling interrupts for slots behind a PPB, and tieing them
to the host slot interrupt makes the most sense.
No. The P2P specification provides nothing for interrupts, just
a generic "guideline" that you may or may not follow depending on
what you are designing. The way you route a motherboard interrupt
line (regardless of it beeing on a bridge or not) is a matter
of commen sense rather.
All that said, the firmware for the x500 and x600 Macs is not written
properly, at least with respect to implementing PCI-PCI Bridges.
Well... Again, do not mix what happens on the mobo and what happens
in slots. Indeed, the x500 and x600 machines have an OF bug that
cause it to not properly assign the shared irq line to the child
devices, but that's really only a concern for _slots_.
quoted
Basicallly, what they did when designing that machine was to use a
standard powersurge design with 3 slots and replace one of them
with a PCI<->PCI bridge. Since they didn't "know" how to get more
interrupt lines out of Grand Central, they just also stuffed all
interrupt lines together for those 4 slots (I'm pretty sure GC do
have spare lines they could have used,
The interrupts for the slots (in the 9500/9600) go to the following pins on GC:
Slot # GC pin #
1 193
2 194
3 189
4 188
5 173
6 174
On the S900 (and J700) the interrupts for slots 3 through 6 are tied
to pin 189.
Yup. My point is that those could have been dispatched to the GC pins
Slots 1 through 3 are also correct for all other PowerSurge machines.
I would love to know if there are other unused interrupts available,
as the PowerSurge architecture supposedly can support up to four
Bandit chips, but as far as I know, if one constructed such a beast,
there'd be no interrupts available for any PCI slots beyond six.
I don't know how much exactly GC provides. It has a single mask
register of 32 interrupts, so if you count all the GC internal ones,
that still leaves a few of them I beleive... You'd need the pinout
of GC, I don't have it (maybe you do ? :) I'm interested in any spec
for these old chipsets...)
This seems to be born out (limited interrupts available) by the
gymnastics they went through to arrange the interrupts in the Apple
Network Server, which has six PCI slots, but also four built-in PCI
devices (including Grand Central) on the motherboard. They didn't
use any previously unused interrupts on GC in the ANS, they just
rearranged and combined the interrupts used in the 9500.
Yup. Still... it would have made a lot of sense for the S900 designers
to actually route the additional slot interrupts to separate GC
interrupt pins. The main problem with that would have been the need to
"teach" Apple's OF about the binding, which of course would have been
a total mess....
However, I can't help but wonder if all that lovely video circuitry
on the 7500 and 8500 requires any interrupts and if so, where they
come from. Do they recycle the interrupts for slots 4 -6 or are
there other interrupts available on GC besides the ones for the six
slots?
Maybe compare the interrupt numbers ? I don't have my datas at hand
but that should give you an idea of who goes where. IIRC, some Mklinux
source (or maybe it's early darwin source) had a map of all the irqs
of GC as well.
quoted
but that would have meant
updating Open Firmware to understand the layout, I doubt the people
who designed that machine wanted to dive into that).
At 14:16 +1100 11/04/2003, Benjamin Herrenschmidt wrote:
quoted
Probably because updating Apple's 1.0.5 OF code to assign them properly
with the P2P setup was beyond their ability to deal with crappy code :)
What is P2P setup?
PCI 2 PCI bridge setup.
The cloners just soldered Apple ROMs down in their machines. The
ROM/firmware used in the PowerComputing and Umax machines (except
PowerBase and C series) was the same ROM/firmware used in the x500
series of machines--the $77D.28F2. This ROM was used in the 7200,
7500, 8500, 9500, all of PCC's Catalyst clones, PowerWave, PowerTower
Pro, S900 and the J700.
Yup. That is part of the problem.
I'm not sure if the cloner's license even allowed them to modify the
ROM. The chips are labeled with Apple part numbers and Apple
markings, so I think they really did purchase them from Apple, rather
than licensing their production.
Yah, though they probably could have dealt some small change to OF
to deal with that issue, or have an nvramrc patch (ugh !) at worst.
Anyway, the point being that even if Umax had wanted to go that route
(rewrite/modify/fix OF 1.05), I'm not sure it was technically
feasible under the licensing agreement. Is hacking the interrupt
assignment for the PCI slots the kind of thing one could squeeze into
the NVRAMrc?
Yes, that's doable. A bit more tricky, they could have put a routing
circuit optionally or'ing them all together. By default, the machine
boots with them all or'ed. If the nvramrc script (or whatever other
possible software patch) doesn't load, they stay that way. The software
patch ticks an IO disabling that OR'ing after patching either the
device-tree (nvramrc patch) or whatever MacOS used for routing.
Probably doable with a few gates, or bits of a PLD if any was already
there.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/