View previous topic :: View next topic |
Author |
Message |
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Fri Dec 14, 2012 8:08 pm Post subject: what is the last working kernel on SGI/mips machine ? |
|
|
hi
i have a 2.6.17 running on my octane2, indy, o2 and impact
what is the last working kernel for these machines ?
i am a bit confused about |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Fri Dec 14, 2012 8:44 pm Post subject: |
|
|
3.7 should work. |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Fri Dec 14, 2012 8:47 pm Post subject: |
|
|
have you tested it ?
on which SGI/mips machine ? |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Fri Dec 14, 2012 10:21 pm Post subject: |
|
|
No, but there's no reason why it wouldn't work. The only arch support that's been dropped recently is i386 and a few obscure ARM CPUs. |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Fri Dec 14, 2012 11:22 pm Post subject: |
|
|
we are not talking about MIPS CPU, we are talking about SGI/MIPS systems, which are experimental systems with reduced support. |
|
Back to top |
|
|
nuts Veteran
Joined: 10 Jan 2004 Posts: 1630
|
Posted: Tue Mar 05, 2013 5:12 pm Post subject: |
|
|
Up
I'm interrested by the question too. I want to try Linux on my Octane system.
So, I'm using a netboot image from the year 2006 and I try the stage3-mips4-r10k for the installation.
So when I'll install the kernel, which version I have to use? _________________ nuts
PC: AMD Phenom 2 bi-core 555 + Asus M4A77T/USB3 + 2Go de RAM + wifi Ralink RT61 + Radeon HD 3450 - Disque dur 500Go.
SGI Octane ip30 R10000 |
|
Back to top |
|
|
armanox n00b
Joined: 03 Jan 2008 Posts: 36 Location: Baltimore, MD
|
Posted: Fri Apr 12, 2013 3:10 am Post subject: |
|
|
Ant P. wrote: | No, but there's no reason why it wouldn't work. The only arch support that's been dropped recently is i386 and a few obscure ARM CPUs. |
A lot of these archs were never supported to begin with. I was running Gentoo on an SGI Octane from 2006-2008, and the IP30 wasn't fully supported, and only one of the O2s I was working with at the time were supported as well (was it a 5K and 15K that we had? I don't remember anymore). Also, I'm not sure that portage if Gentoo still builds on these systems. The MIPS team was pretty sparse back then. |
|
Back to top |
|
|
mattst88 Developer
Joined: 28 Oct 2004 Posts: 422
|
Posted: Fri Jul 19, 2013 9:05 pm Post subject: |
|
|
Octane support was never upstream and it's bitrotted badly. The latest I heard of working on the Octane was 2.6.29.
Indy, Indigo2, and O2 are supported by the latest kernels. _________________ My Wiki page |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Sun Jul 21, 2013 12:14 am Post subject: |
|
|
cooking 2.6.29 just now =D |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Mon Jul 22, 2013 10:05 am Post subject: |
|
|
.29 is not booting at all =(
i cooked 2.6.17 + ramrootfs, it is perfectly running, wandering what is wrong with .29
i ve to investigate |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Tue Jul 23, 2013 8:38 am Post subject: |
|
|
Quote: |
>> bootp():
Setting $netaddr to 192.168.1.3 (from server )
Obtaining from server
13601280+308208 entry: 0xa800000020009cd0
|
- dead - |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Tue Jul 23, 2013 9:25 am Post subject: |
|
|
it seems there is a different behavior ...
i tried the same 2.6.29.1 kernel on two octanes
not booting kernel - octane2 with 1 CPU R12K 2Gbyte ram, without any pci-cartridge
90% running kernel - octane2 with 2 CPU R12K 1Gbyte ram, wiith pci-cartridge
2.6.17 is perfectly running on both these two systems, so ... may be something related to SMP or pci-cartridge or Ram ? |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Tue Jul 23, 2013 10:23 am Post subject: |
|
|
Code: |
Linux version 2.6.29.1-mipsgit-20090324-sgi-octane2 (root@kika) (gcc version 4.3.5 (Gentoo 4.3.5 p1.1) ) #1 SMP PREEMPT Tue Jul 23 05:12:44 CEST 2013
ARCH: SGI-IP30
PROMLIB: ARC firmware Version 64 Revision 0
CPU revision is: 00000e35 (R12000)
FPU revision is: 00000900
Checking for the multiply/shift bug... no.
Checking for the daddiu bug... no.
Silicon Graphics Octane (IP30) support: (c) 2004-2007 Stanislaw Skowronek.
Detected 1280 MB of physical memory.
Updating PROM memory size.
xtalk: Detected XBow (revision 2.0) at 0.
xtalk: Detected Heart (revision F) at 8.
xtalk: Detected HQ4 / ImpactSR (revision B) at 10.
xtalk: Detected Buzz / Odyssey (revision B) at 11.
xtalk: Detected Bridge (revision D) at 15.
BRIDGE chip at xtalk:15, initializing...
registering PCI controller with io_map_base unset
Determined physical RAM map:
memory: 0000000000004000 @ 0000000000000000 (reserved)
memory: 0000000000d44000 @ 0000000020004000 (reserved)
memory: 00000000001b8000 @ 0000000020d48000 (usable)
memory: 0000000000100000 @ 0000000020f00000 (ROM data)
memory: 000000003f000000 @ 0000000021000000 (usable)
memory: 0000000010000000 @ 0000000060000000 (reserved)
memory: 0000000010000000 @ 0000000060000000 (usable)
Wasting 7530432 bytes for tracking 134472 unused pages
Initrd not found or empty - disabling initrd
Zone PFN ranges:
DMA 0x00000000 -> 0x000a0000
Normal 0x000a0000 -> 0x000a0000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x00000004
0: 0x00020004 -> 0x00070000
On node 0 totalpages: 327680
free_area_init_node: node 0, pgdat a8000000204cb080, node_mem_map a800000021000000
DMA zone: 6272 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 321408 pages, LIFO batch:31
Detected 1 enabled CPU(s).
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 321408
Kernel command line: ip=on console=ttyS0,9600 rdinit=/sbin/init init=/bin/bash
Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes.
Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes
Unified secondary cache 2048kB 2-way, linesize 128 bytes.
IP30: interrupt controller initialized.
PID hash table entries: 4096 (order: 12, 32768 bytes)
IP30: initializing timer.
400 MHz CPU detected
start_kernel(): bug: interrupts were enabled early
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1267076k/1296096k available (3708k kernel code, 28276k reserved, 1215k data, 8360k init, 0k highmem)
Calibrating delay loop... 618.49 BogoMIPS (lpj=309248)
Mount-cache hash table entries: 256
Checking for the daddi bug... no.
Brought up 1 CPUs
net_namespace: 560 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pci 0000:00:00.0: reg 10 io port: [0x200000-0x2000ff]
pci 0000:00:00.0: reg 14 32bit mmio: [0x200000-0x200fff]
pci 0000:00:00.0: reg 30 32bit mmio: [0x210000-0x21ffff]
pci 0000:00:01.0: reg 10 io port: [0x400000-0x4000ff]
pci 0000:00:01.0: reg 14 32bit mmio: [0x400000-0x400fff]
pci 0000:00:01.0: reg 30 32bit mmio: [0x410000-0x41ffff]
pci 0000:00:02.0: reg 10 32bit mmio: [0x500000-0x5fffff]
pci 0000:00:03.0: reg 10 32bit mmio: [0x600000-0x601fff]
IP30: HEART ATTACK! Caught errors: 0x0040!
interrupt #63
interrupt #57
Switched to high resolution mode on CPU 0
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 4.0 (2009/01/31) Phillip Lougher
EFS: 1.0a - http://aeschi.ch.eu.org/efs/
msgmni has been set to 2476
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
loop: module loaded
qla1280: QLA1040 found on PCI bus 0, dev 0
BRIDGE: IO #0, size 0x100 for little-endian 0000:00:00.0 --> direct I/O at bus 0x01000000 vma 0x000000f101000000
BRIDGE: Memory #1, size 0x1000 for little-endian 0000:00:00.0 --> direct 32-bit at bus 0x01000000 vma 0x000000f041000000
BRIDGE: Memory #6, size 0x10000 for little-endian 0000:00:00.0 --> direct 32-bit at bus 0x01010000 vma 0x000000f041010000
PCI: Enabling device 0000:00:00.0 (0006 -> 0007)
scsi(0:0): Resetting SCSI BUS
scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter
Firmware version: 7.65.06, Driver version 3.26
qla1280: QLA1040 found on PCI bus 0, dev 1
BRIDGE: IO #0, size 0x100 for little-endian 0000:00:01.0 --> direct I/O at bus 0x01000100 vma 0x000000f101000100
BRIDGE: Memory #1, size 0x1000 for little-endian 0000:00:01.0 --> direct 32-bit at bus 0x01020000 vma 0x000000f041020000
BRIDGE: Memory #6, size 0x10000 for little-endian 0000:00:01.0 --> direct 32-bit at bus 0x01030000 vma 0x000000f041030000
PCI: Enabling device 0000:00:01.0 (0006 -> 0007)
scsi(1:0): Resetting SCSI BUS
scsi1 : QLogic QLA1040 PCI to SCSI Host Adapter
Firmware version: 7.65.06, Driver version 3.26
st: Version 20081215, fixed bufsize 32768, s/g segs 256
Driver 'st' needs updating - please use bus_type methods
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
usbmon: debugfs is not available
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd: block sizes: qh 160 qtd 96 itd 192 sitd 96
uhci_hcd: USB Universal Host Controller Interface driver
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
pl2303: Prolific PL2303 USB to serial adaptor driver
mice: PS/2 mouse device common for all mice
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.18a.
BRIDGE: Memory #0, size 0x2000 for little-endian 0000:00:03.0 --> direct 32-bit at bus 0x01040000 vma 0x000000f041040000
ALSA device list:
#0: SGI RAD Audio at 0xf041040000
BRIDGE: Memory #0, size 0x100000 for little-endian 0000:00:02.0 --> direct 32-bit at bus 0x01100000 vma 0x000000f041100000
IOC3 part: [030-0891-003], serial: [MBX420] => class IP30 system
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a800000020243fd0>] device_create_vargs+0x100/0x118
[<a80000002024400c>] device_create+0x24/0x30
[<a800000020224758>] misc_register+0x160/0x268
[<a800000020236ecc>] ioc3led_probe+0x6c/0x1e0
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a800000020243fd0>] device_create_vargs+0x100/0x118
[<a80000002024400c>] device_create+0x24/0x30
[<a800000020224758>] misc_register+0x160/0x268
[<a800000020237cac>] ioc3rtc_probe+0x74/0x260
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a80000002024361c>] device_del+0x164/0x1c0
[<a80000002024368c>] device_unregister+0x14/0x28
[<a8000000202436ec>] device_destroy+0x4c/0x60
[<a80000002023849c>] uart_remove_one_port+0xbc/0x150
[<a800000020240344>] serial8250_register_port+0x12c/0x360
[<a800000020241f88>] ioc3uart_probe+0x178/0x1f8
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
0000:00:02.0: ttyS0 at IOC3 0xf041120178 (irq = 64) is a 16550A
console [ttyS0] enabled
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a800000020243fd0>] device_create_vargs+0x100/0x118
[<a80000002024400c>] device_create+0x24/0x30
[<a800000020218304>] tty_register_device+0x114/0x170
[<a800000020238e34>] uart_add_one_port+0x1e4/0x4e0
[<a8000000202403e8>] serial8250_register_port+0x1d0/0x360
[<a800000020241f88>] ioc3uart_probe+0x178/0x1f8
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a80000002024361c>] device_del+0x164/0x1c0
[<a80000002024368c>] device_unregister+0x14/0x28
[<a8000000202436ec>] device_destroy+0x4c/0x60
[<a80000002023849c>] uart_remove_one_port+0xbc/0x150
[<a800000020240344>] serial8250_register_port+0x12c/0x360
[<a800000020241fa8>] ioc3uart_probe+0x198/0x1f8
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
0000:00:02.0: ttyS1 at IOC3 0xf041120170 (irq = 64) is a 16550A
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a800000020243fd0>] device_create_vargs+0x100/0x118
[<a80000002024400c>] device_create+0x24/0x30
[<a800000020218304>] tty_register_device+0x114/0x170
[<a800000020238e34>] uart_add_one_port+0x1e4/0x4e0
[<a8000000202403e8>] serial8250_register_port+0x1d0/0x360
[<a800000020241fa8>] ioc3uart_probe+0x198/0x1f8
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
Ethernet address is 08:00:69:13:a8:d1.
eth0 (SGI IOC3): not using net_device_ops yet
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a8000000203327a8>] register_netdevice+0x400/0x608
[<a8000000203329f4>] register_netdev+0x44/0x68
[<a80000002000ecb0>] ioc3eth_probe+0x358/0x518
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
eth0: Using PHY 1, vendor 0x15f42, model 2, rev 3.
eth0: IOC3 SSRAM has 128 kbyte.
IOC3 Master Driver loaded for 0000:00:02.0
atkbd.c: keyboard reset failed on ioc3/serio0kbd
atkbd.c: keyboard reset failed on ioc3/serio0aux
TCP cubic registered
NET: Registered protocol family 17
Freeing prom memory: 1024k freed
Freeing unused kernel memory: 8360k freed
|
|
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Wed Jul 24, 2013 4:01 pm Post subject: |
|
|
anybody has 2.6.19 mips-sources ebuild and files ?
is it known to be working on SMP 2xR12K octane2 ?
It seems like the Octane port nears serious work. |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Thu Jul 25, 2013 12:19 pm Post subject: |
|
|
anyone that could provide me a copy of 2.6.19 ebuild and files for ip30 ? |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Fri Jul 26, 2013 5:21 am Post subject: |
|
|
nuts wrote: | Up
I'm interrested by the question too. I want to try Linux on my Octane system.
So, I'm using a netboot image from the year 2006 and I try the stage3-mips4-r10k for the installation.
So when I'll install the kernel, which version I have to use? |
2.6.17.14 from my point of view is the last stable, unfortunately newer stages3 are not compatible
2.6.19.rc6 has issues with NFS, but may be usable |
|
Back to top |
|
|
legacy Tux's lil' helper
Joined: 10 Sep 2012 Posts: 144
|
Posted: Fri Jul 26, 2013 5:28 am Post subject: |
|
|
Code: |
version 2.6.29.1-mipsgit-20090324-sgi-octane2
gcc version 4.3.5 (Gentoo 4.3.5 p1.1) )
SMP PREEMPT Tue Jul 23 05:12:44 CEST 2013
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a800000020243fd0>] device_create_vargs+0x100/0x118
[<a80000002024400c>] device_create+0x24/0x30
[<a800000020224758>] misc_register+0x160/0x268
[<a800000020236ecc>] ioc3led_probe+0x6c/0x1e0
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
|
"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such
that means -> i do not trust 2.6.29 at all |
|
Back to top |
|
|
Kumba Developer
Joined: 16 Jul 2002 Posts: 393 Location: Sigma 957
|
Posted: Mon Feb 03, 2014 12:23 pm Post subject: |
|
|
legacy wrote: | Code: |
version 2.6.29.1-mipsgit-20090324-sgi-octane2
gcc version 4.3.5 (Gentoo 4.3.5 p1.1) )
SMP PREEMPT Tue Jul 23 05:12:44 CEST 2013
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a800000020243fd0>] device_create_vargs+0x100/0x118
[<a80000002024400c>] device_create+0x24/0x30
[<a800000020224758>] misc_register+0x160/0x268
[<a800000020236ecc>] ioc3led_probe+0x6c/0x1e0
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
|
"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such
that means -> i do not trust 2.6.29 at all |
I remember this one. Ran into it myself when playing around w/ 2.6.29 once. Never figured it out, as at this point, the userland was partially active, so most of the debugging one could do within the kernel were useless in figuing out what happened. Considering Octane's main issue was figuring out how to handle IRQ's correctly, betcha it's a bug in that core code. _________________ "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic |
|
Back to top |
|
|
armanox n00b
Joined: 03 Jan 2008 Posts: 36 Location: Baltimore, MD
|
Posted: Thu Feb 06, 2014 3:24 am Post subject: |
|
|
Kumba wrote: | legacy wrote: | Code: |
version 2.6.29.1-mipsgit-20090324-sgi-octane2
gcc version 4.3.5 (Gentoo 4.3.5 p1.1) )
SMP PREEMPT Tue Jul 23 05:12:44 CEST 2013
BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Call Trace:
[<a800000020010c90>] dump_stack+0x8/0x48
[<a8000000200119c0>] schedule+0x510/0x9f0
[<a800000020012268>] schedule_timeout+0x110/0x170
[<a8000000200113ec>] wait_for_common+0x164/0x190
[<a80000002005ebd4>] call_usermodehelper_exec+0x94/0xc8
[<a8000000201e2470>] kobject_uevent_env+0x4f8/0x530
[<a800000020243d4c>] device_add+0x5e4/0x740
[<a800000020243fd0>] device_create_vargs+0x100/0x118
[<a80000002024400c>] device_create+0x24/0x30
[<a800000020224758>] misc_register+0x160/0x268
[<a800000020236ecc>] ioc3led_probe+0x6c/0x1e0
[<a800000020318934>] ioc3_probe+0x5ac/0xdc0
[<a8000000201f9924>] local_pci_probe+0x1c/0x28
[<a8000000201f9c4c>] pci_device_probe+0x84/0xb0
[<a800000020246ba4>] driver_probe_device+0xdc/0x278
[<a800000020246de8>] __driver_attach+0xa8/0xb0
[<a8000000202460c0>] bus_for_each_dev+0x60/0xc8
[<a800000020245708>] bus_add_driver+0x2a0/0x388
[<a80000002024708c>] driver_register+0x84/0x190
[<a8000000201fa1b8>] __pci_register_driver+0x60/0xe0
[<a800000020014ac0>] __kprobes_text_end+0x48/0x1e8
[<a8000000204d346c>] kernel_init+0x298/0x348
[<a800000020017770>] kernel_thread_helper+0x10/0x18
|
"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such
that means -> i do not trust 2.6.29 at all |
I remember this one. Ran into it myself when playing around w/ 2.6.29 once. Never figured it out, as at this point, the userland was partially active, so most of the debugging one could do within the kernel were useless in figuing out what happened. Considering Octane's main issue was figuring out how to handle IRQ's correctly, betcha it's a bug in that core code. |
I remember seeing something like that on the Gentoo Octane I had running in college. I've got two at my house now (not the same two I was working with in college) - one is running IRIX, the other has no OS (I think the SCSI controller might be shot. Need to make sure everything is tight now), and I might be willing to give a new netboot image a test run on it. |
|
Back to top |
|
|
Kumba Developer
Joined: 16 Jul 2002 Posts: 393 Location: Sigma 957
|
Posted: Wed May 07, 2014 4:03 am Post subject: |
|
|
armanox wrote: | Kumba wrote: | legacy wrote: |
[snip]
"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such
that means -> i do not trust 2.6.29 at all |
I remember this one. Ran into it myself when playing around w/ 2.6.29 once. Never figured it out, as at this point, the userland was partially active, so most of the debugging one could do within the kernel were useless in figuing out what happened. Considering Octane's main issue was figuring out how to handle IRQ's correctly, betcha it's a bug in that core code. |
I remember seeing something like that on the Gentoo Octane I had running in college. I've got two at my house now (not the same two I was working with in college) - one is running IRIX, the other has no OS (I think the SCSI controller might be shot. Need to make sure everything is tight now), and I might be willing to give a new netboot image a test run on it. |
I've got Octane booting again somewhat in 3.14. The IRQ handler has been patched up thanks to a patch sent to me a few years ago that I forgot about. Had to mix and match some code, but I can boot to a console using only the Odyssey driver. Keyboard works again, probably mouse too. No serial console, no RAD1, and no ImpactSR right now, as I haven't been able to fix those drivers yet. SCSI access is extremely slow, probably because I need to tune the IRQ handling some more. Almost got the RTC to play nice...but ARCS keeps resetting the clock back to 1970 every two reboots for some absurd reason. No SMP either...and I don't look forward to tackling that code. But since I have an understanding of HEART's IRQ management now, maybe...
Oh, and ethernet does work, but like SCSI, I expect it to be a bit sluggish...though I have not tried benchmarking it yet. _________________ "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|