From: Christian Kujau <hidden> Date: 2004-12-04 22:45:22
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
upon receiving some calls about the status on this issue, i decided to
update http://bugme.osdl.org/show_bug.cgi?id=1494 , which i reported a
while back. yes, this is "just a PReP" and i am fully aware that PReP is
not used in recent setups any more and i too will not my PReP for HPC
applications. but perhaps someone has an idea about what's goin on here.
the bugreport should give you th full details, in short: linux 2.5.30 is
the last working kernel for ppc32/PReP with networking enabled.
(net)booting a recent 2.6 kernels spit out lots of these:
(with tulip NIC)
Dec 3 23:56:39 192.168.10.9 irq 9: nobody cared!
Dec 3 23:56:39 192.168.10.9 Call trace:
Dec 3 23:56:39 192.168.10.9 [c002e99c] __report_bad_irq+0x34/0xac
Dec 3 23:56:39 192.168.10.9 [c002eb00] note_interrupt+0xd0/0x104
Dec 3 23:56:39 192.168.10.9 [c002e480] __do_IRQ+0x174/0x184
Dec 3 23:56:39 192.168.10.9 [c00053e0] do_IRQ+0x38/0x98
Dec 3 23:56:39 192.168.10.9 [c00044cc] ret_from_except+0x0/0x14
Dec 3 23:56:39 192.168.10.9 [c002e748] setup_irq+0xd8/0x138
Dec 3 23:56:39 192.168.10.9 [c002e938] request_irq+0x90/0xc0
Dec 3 23:56:39 192.168.10.9 [c0103504] tulip_open+0x30/0xb6c
Dec 3 23:56:39 192.168.10.9 [c0117274] dev_open+0xb0/0xd8
Dec 3 23:56:39 192.168.10.9 [c0118a7c] dev_change_flags+0x6c/0x144
Dec 3 23:56:39 192.168.10.9 [c0123db4] netpoll_setup+0x1c4/0x364
Dec 3 23:56:39 192.168.10.9 [c0106fe0] init_netconsole+0x3c/0x94
Dec 3 23:56:39 192.168.10.9 [c0003a64] init+0xb8/0x230
Dec 3 23:56:39 192.168.10.9 [c0006524] kernel_thread+0x44/0x60
Dec 3 23:56:39 192.168.10.9 handlers:
Dec 3 23:56:39 192.168.10.9 [<c010101c>] (tulip_interrupt+0x0/0xd3c)
Dec 3 23:56:39 192.168.10.9 Disabling IRQ #9
(with 3c59x NIC)
192.168.10.9 NETDEV WATCHDOG: eth0: transmit timed out
192.168.10.9 eth0: transmit timed out, tx_status 00 status e800.
192.168.10.9 diagnostics: net 0cc0 media 8802 dma 002000b3 fifo 0000
192.168.10.9 eth0: Interrupt posted but not delivered -- IRQ blocked by
another device?
192.168.10.9 Flags; bus-master 1, dirty 67(3) current 68(4)
192.168.10.9 Transmit list 806fe480 vs. c06fe3e0.
192.168.10.9 0: @c06fe200 length 80000054 status 00000054
192.168.10.9 1: @c06fe2a0 length 8000005e status 0000005e
192.168.10.9 2: @c06fe340 length 80000064 status 00000064
192.168.10.9 3: @c06fe3e0 length 80000075 status 00000075
192.168.10.9 4: @c06fe480 length 8000005b status 0000005b
192.168.10.9 5: @c06fe520 length 80000051 status 00000051
192.168.10.9 6: @c06fe5c0 length 8000005a status 0000005a
192.168.10.9 7: @c06fe660 length 8000005a status 0000005a
192.168.10.9 8: @c06fe700 length 8000005a status 0000005a
192.168.10.9 9: @c06fe7a0 length 8000005a status 0000005a
192.168.10.9 10: @c06fe840 length 8000005a status 0000005a
192.168.10.9 11: @c06fe8e0 length 8000005a status 0000005a
192.168.10.9 12: @c06fe980 length 8000005a status 0000005a
192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
192.168.10.9 15: @c06feb60 length 8000005a status 0000005a
is it possible to use another irq for the network-device driver?
Documentation/kernel-parameters.txt gives some options about other
drivers, but i can't tell how to specify "use this irq" for tulip/3c59x.
especially the "IRQ blocked by another device?" message makes me think,
that manual irq config could help here. but maybe i'm wrong.
the results posted on http://nerdbynature.de/bits/sheep/2.6.10-rc2/ are
from current 2.6 kernels: the offical tree and the linuxppc25 tree was used.
thank you for comments,
Christian.
- --
BOFH excuse #441:
Hash table has woodworm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBsj3y+A7rjkF8z0wRAldLAJ9QFTfr8UeOtXbnSCGWBVJr7IAAKgCgiHRV
iB/ozetyCDIMSfAa+1MRxVc=
=b5BK
-----END PGP SIGNATURE-----
From: Sebastian Heutling <hidden> Date: 2004-12-05 00:46:29
You got the powerstack booting from scsi (reading and interpreting the
bug report). I had problems booting 2.6 kernels as well (never tested
any 2.5 kernels). It turned out that the pci slot numbering has changed
sometime and this wasn't reflected in arch/ppc/platforms/prep_pci.c.
After having set up the slot0...slot8 using the values of
slot10...slot18 (except for slot1 which got value 4 so IDE is usable out
of the box), the machine booted a 2.6 kernel (2.6.8).
Sebastian
On Sat, 2004-12-04 at 23:45 +0100, Christian Kujau wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
upon receiving some calls about the status on this issue, i decided to
update http://bugme.osdl.org/show_bug.cgi?id=1494 , which i reported a
while back. yes, this is "just a PReP" and i am fully aware that PReP is
not used in recent setups any more and i too will not my PReP for HPC
applications. but perhaps someone has an idea about what's goin on here.
the bugreport should give you th full details, in short: linux 2.5.30 is
the last working kernel for ppc32/PReP with networking enabled.
(net)booting a recent 2.6 kernels spit out lots of these:
(with tulip NIC)
Dec 3 23:56:39 192.168.10.9 irq 9: nobody cared!
Dec 3 23:56:39 192.168.10.9 Call trace:
Dec 3 23:56:39 192.168.10.9 [c002e99c] __report_bad_irq+0x34/0xac
Dec 3 23:56:39 192.168.10.9 [c002eb00] note_interrupt+0xd0/0x104
Dec 3 23:56:39 192.168.10.9 [c002e480] __do_IRQ+0x174/0x184
Dec 3 23:56:39 192.168.10.9 [c00053e0] do_IRQ+0x38/0x98
Dec 3 23:56:39 192.168.10.9 [c00044cc] ret_from_except+0x0/0x14
Dec 3 23:56:39 192.168.10.9 [c002e748] setup_irq+0xd8/0x138
Dec 3 23:56:39 192.168.10.9 [c002e938] request_irq+0x90/0xc0
Dec 3 23:56:39 192.168.10.9 [c0103504] tulip_open+0x30/0xb6c
Dec 3 23:56:39 192.168.10.9 [c0117274] dev_open+0xb0/0xd8
Dec 3 23:56:39 192.168.10.9 [c0118a7c] dev_change_flags+0x6c/0x144
Dec 3 23:56:39 192.168.10.9 [c0123db4] netpoll_setup+0x1c4/0x364
Dec 3 23:56:39 192.168.10.9 [c0106fe0] init_netconsole+0x3c/0x94
Dec 3 23:56:39 192.168.10.9 [c0003a64] init+0xb8/0x230
Dec 3 23:56:39 192.168.10.9 [c0006524] kernel_thread+0x44/0x60
Dec 3 23:56:39 192.168.10.9 handlers:
Dec 3 23:56:39 192.168.10.9 [<c010101c>] (tulip_interrupt+0x0/0xd3c)
Dec 3 23:56:39 192.168.10.9 Disabling IRQ #9
(with 3c59x NIC)
192.168.10.9 NETDEV WATCHDOG: eth0: transmit timed out
192.168.10.9 eth0: transmit timed out, tx_status 00 status e800.
192.168.10.9 diagnostics: net 0cc0 media 8802 dma 002000b3 fifo 0000
192.168.10.9 eth0: Interrupt posted but not delivered -- IRQ blocked by
another device?
192.168.10.9 Flags; bus-master 1, dirty 67(3) current 68(4)
192.168.10.9 Transmit list 806fe480 vs. c06fe3e0.
192.168.10.9 0: @c06fe200 length 80000054 status 00000054
192.168.10.9 1: @c06fe2a0 length 8000005e status 0000005e
192.168.10.9 2: @c06fe340 length 80000064 status 00000064
192.168.10.9 3: @c06fe3e0 length 80000075 status 00000075
192.168.10.9 4: @c06fe480 length 8000005b status 0000005b
192.168.10.9 5: @c06fe520 length 80000051 status 00000051
192.168.10.9 6: @c06fe5c0 length 8000005a status 0000005a
192.168.10.9 7: @c06fe660 length 8000005a status 0000005a
192.168.10.9 8: @c06fe700 length 8000005a status 0000005a
192.168.10.9 9: @c06fe7a0 length 8000005a status 0000005a
192.168.10.9 10: @c06fe840 length 8000005a status 0000005a
192.168.10.9 11: @c06fe8e0 length 8000005a status 0000005a
192.168.10.9 12: @c06fe980 length 8000005a status 0000005a
192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
192.168.10.9 15: @c06feb60 length 8000005a status 0000005a
is it possible to use another irq for the network-device driver?
Documentation/kernel-parameters.txt gives some options about other
drivers, but i can't tell how to specify "use this irq" for tulip/3c59x.
especially the "IRQ blocked by another device?" message makes me think,
that manual irq config could help here. but maybe i'm wrong.
the results posted on http://nerdbynature.de/bits/sheep/2.6.10-rc2/ are
from current 2.6 kernels: the offical tree and the linuxppc25 tree was used.
thank you for comments,
Christian.
- --
BOFH excuse #441:
Hash table has woodworm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBsj3y+A7rjkF8z0wRAldLAJ9QFTfr8UeOtXbnSCGWBVJr7IAAKgCgiHRV
iB/ozetyCDIMSfAa+1MRxVc=
=b5BK
-----END PGP SIGNATURE-----
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Christian Kujau <hidden> Date: 2004-12-05 17:47:06
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sebastian Heutling schrieb:
You got the powerstack booting from scsi (reading and interpreting the
yes, but now the disk is gone and i have to use nfsroot.
bug report). I had problems booting 2.6 kernels as well (never tested
any 2.5 kernels). It turned out that the pci slot numbering has changed
sometime and this wasn't reflected in arch/ppc/platforms/prep_pci.c.
After having set up the slot0...slot8 using the values of
slot10...slot18 (except for slot1 which got value 4 so IDE is usable out
of the box), the machine booted a 2.6 kernel (2.6.8).
boy! this *is* an early christmas present, for sure! how did you come to
this conclusion? something *must* have changed in the pci setup after
2.5.30, because the problem did not go away when i used a different NIC
driver. but i could not fiddle out the changeset to blame here, because i
failed to compile many kernels > 2.5.30.
changing one line in arch/ppc/platforms/prep_pci.c made my PReP booting a
recent 2.6-BK, patch attached.
it's booting now, "init=/bin/bash" is working, but i still can't ping to
the outside world, which is still a bit strange, but i hope i can work it out.
tausend dank (really),
Christian.
- --
BOFH excuse #304:
routing problems on the neural net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBs0hj+A7rjkF8z0wRAo3RAKDF+QYA6cosLH+kWtiAmiWtRzlQkQCeKcpx
FXOiNRfl9/vOynE8d4hDJJg=
=sKOm
-----END PGP SIGNATURE-----
From: Christian Kujau <hidden> Date: 2004-12-05 19:58:08
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
whoops! a bit too early, i had to change 3 lines, not one.
Signed-off-by: Christian Kujau <redacted>
(new patch attached; credits should go to Sebastian Heutling aka
sheutlin@gmx.de)
thanks,
Christian.
- --
BOFH excuse #304:
routing problems on the neural net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBs2hE+A7rjkF8z0wRAi+3AJ42GZlqMZen6lqMwtyQSMbS61tkbwCeMNET
nKgGhTpgwAcCJJ0hWUKoFqg=
=xyi5
-----END PGP SIGNATURE-----
From: Sebastian Heutling <hidden> Date: 2004-12-06 01:44:26
On Sun, 2004-12-05 at 18:41 +0100, Christian Kujau wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sebastian Heutling schrieb:
quoted
You got the powerstack booting from scsi (reading and interpreting the
yes, but now the disk is gone and i have to use nfsroot.
quoted
bug report). I had problems booting 2.6 kernels as well (never tested
any 2.5 kernels). It turned out that the pci slot numbering has changed
sometime and this wasn't reflected in arch/ppc/platforms/prep_pci.c.
After having set up the slot0...slot8 using the values of
slot10...slot18 (except for slot1 which got value 4 so IDE is usable out
of the box), the machine booted a 2.6 kernel (2.6.8).
boy! this *is* an early christmas present, for sure! how did you come to
this conclusion? something *must* have changed in the pci setup after
:-)
Pure trial and error in the first time. When realising that something is
wrong with the assigned interrupts (looking at the kernel output) we
tried to set the ones that were working in a 2.4 kernel. When the
machine finally booted a "lspci" showed that the slot number changed.
2.5.30, because the problem did not go away when i used a different NIC
driver. but i could not fiddle out the changeset to blame here, because i
failed to compile many kernels > 2.5.30.
changing one line in arch/ppc/platforms/prep_pci.c made my PReP booting a
recent 2.6-BK, patch attached.
it's booting now, "init=/bin/bash" is working, but i still can't ping to
the outside world, which is still a bit strange, but i hope i can work it out.
Is it that onboard network tulip kind of thingy? Do you have some other
PCI cards installed?
I used to have an extra symbios logic scsi-host-adapter installed.
On high network load and loading/writing to a HD (using onboard scsi), I
noticed a lot of problems: either the scsi-host-adapter lost the
interrupt or the network driver lost some packets or both. After having
removed the extra scsi-host-adapter it works fine now.
From: Christian Kujau <hidden> Date: 2004-12-06 04:16:06
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sebastian Heutling schrieb:
Pure trial and error in the first time. When realising that something is
wrong with the assigned interrupts (looking at the kernel output) we
tried to set the ones that were working in a 2.4 kernel. When the
machine finally booted a "lspci" showed that the slot number changed.
lspci, sounds easy ;-)
but i never would have looked at slot numbering....
Is it that onboard network tulip kind of thingy? Do you have some other
PCI cards installed?
the card is onboard. since i had some issues with this card in early 2.4
kernels too, i used to have another NIC. in fact, very often i only
compiled with 3c59x enabled - OF cared about the onboard NIC (tulip) and
once the kernel is loaded, the tulip is not needed any more and 3c59x
takes over.
http://nerdbynature.de/bits/sheep/2.6.10-rc3/ has some details.
I used to have an extra symbios logic scsi-host-adapter installed.
On high network load and loading/writing to a HD (using onboard scsi), I
noticed a lot of problems: either the scsi-host-adapter lost the
interrupt or the network driver lost some packets or both. After having
removed the extra scsi-host-adapter it works fine now.
hm, when i had 3 scsi-disks in this machine (fine IBM ones, hmmmm..) i
only used the on-board scsi-bus. there was no other scsi-host-adapter
inside, but i noticed the very same problems: upon massive i/o, the
machine got stuck for 30sec, sometimes longer, load increased to 30..40 or
so, then the machine got back, with a syslog full of scsi errors.
it's still so incredible that a 3-liner solved this issue. the bug-report
was opened over a year ago...
thanks again,
Christian.
- --
BOFH excuse #13:
we're waiting for [the phone company] to fix that line
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBs9zX+A7rjkF8z0wRArwBAKDZ2ywiukQl/b/uPTG1/1jWHrIsxQCeIcKb
ltnS8407uSUM+J6jiJABxxc=
=Ts4X
-----END PGP SIGNATURE-----
On Sun, Dec 05, 2004 at 08:57:57PM +0100, Christian Kujau wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
whoops! a bit too early, i had to change 3 lines, not one.
Signed-off-by: Christian Kujau <redacted>
(new patch attached; credits should go to Sebastian Heutling aka
sheutlin@gmx.de)
This doesn't cause anything bad to happen on mine (and it shouldn't,
being a Blackhawk and all :)), so I'll send this on. Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/