Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
what is the last working kernel on SGI/mips machine ?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures
View previous topic :: View next topic  
Author Message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Fri Dec 14, 2012 8:08 pm    Post subject: what is the last working kernel on SGI/mips machine ? Reply with quote

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
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Fri Dec 14, 2012 8:44 pm    Post subject: Reply with quote

3.7 should work.
Back to top
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Fri Dec 14, 2012 8:47 pm    Post subject: Reply with quote

have you tested it ?
on which SGI/mips machine ?
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Fri Dec 14, 2012 10:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Fri Dec 14, 2012 11:22 pm    Post subject: Reply with quote

we are not talking about MIPS CPU, we are talking about SGI/MIPS systems, which are experimental systems with reduced support.
Back to top
View user's profile Send private message
nuts
Veteran
Veteran


Joined: 10 Jan 2004
Posts: 1630

PostPosted: Tue Mar 05, 2013 5:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
armanox
n00b
n00b


Joined: 03 Jan 2008
Posts: 36
Location: Baltimore, MD

PostPosted: Fri Apr 12, 2013 3:10 am    Post subject: Reply with quote

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
View user's profile Send private message
mattst88
Developer
Developer


Joined: 28 Oct 2004
Posts: 422

PostPosted: Fri Jul 19, 2013 9:05 pm    Post subject: Reply with quote

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
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Sun Jul 21, 2013 12:14 am    Post subject: Reply with quote

cooking 2.6.29 just now =D
Back to top
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Mon Jul 22, 2013 10:05 am    Post subject: Reply with quote

.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
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Tue Jul 23, 2013 8:38 am    Post subject: Reply with quote

Quote:

>> bootp():
Setting $netaddr to 192.168.1.3 (from server )
Obtaining from server
13601280+308208 entry: 0xa800000020009cd0


- dead -
Back to top
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Tue Jul 23, 2013 9:25 am    Post subject: Reply with quote

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
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Tue Jul 23, 2013 10:23 am    Post subject: Reply with quote

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
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Wed Jul 24, 2013 4:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Thu Jul 25, 2013 12:19 pm    Post subject: Reply with quote

anyone that could provide me a copy of 2.6.19 ebuild and files for ip30 ?
Back to top
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Fri Jul 26, 2013 5:21 am    Post subject: Reply with quote

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
View user's profile Send private message
legacy
Tux's lil' helper
Tux's lil' helper


Joined: 10 Sep 2012
Posts: 144

PostPosted: Fri Jul 26, 2013 5:28 am    Post subject: Reply with quote

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
View user's profile Send private message
Kumba
Developer
Developer


Joined: 16 Jul 2002
Posts: 393
Location: Sigma 957

PostPosted: Mon Feb 03, 2014 12:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
armanox
n00b
n00b


Joined: 03 Jan 2008
Posts: 36
Location: Baltimore, MD

PostPosted: Thu Feb 06, 2014 3:24 am    Post subject: Reply with quote

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
View user's profile Send private message
Kumba
Developer
Developer


Joined: 16 Jul 2002
Posts: 393
Location: Sigma 957

PostPosted: Wed May 07, 2014 4:03 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures All times are GMT
Page 1 of 1

 
Jump to:  
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