SGI O2 unable to boot 9.0+

[Mike Shields]

Hello port-mips folks.

I've been trying to get NetBSD running on a Silicon Graphics O2. I have a few of these machines, with various complements of memory and CPU. I've tested on an R5k 180MHz, an R5k 200MHz, and an R12k 400MHz. All the machines work flawlessly in IRIX and OpenBSD 6.9 so I'm confident hardware is not the issue. All exhibit the same results - booting either from CD or from bootp/tftp.

The kernel loads, and will print between 1 and a few dozen lines before hard freezing, requiring power plug removal to reboot. Faster CPUs get farther before freezing (the 400MHz is often able to print out the copyright message) - one interesting bit is the timestamp on the kernel messages is always [ 1.0000000] - as if it freezes on the first timer tick.

I've tried booting all versions of 9.x and 10.0 that are available with the same results

I'd love to help get it working again on this platform, though I'm not certain where to begin. I was able to install NetBSD 8.3, in the hopes I could possibly upgrade from there, compile kernels, debug, etc - but I'm not sure 8.3 is a suitable platform to start with, it being so old.

Is anyone else interested in getting O2s back up to working status in NetBSD 10.0?
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andrius V]

Hi

On Mon, Jun 24, 2024 at 4:24 AM Mike Shields <***@shieldsworld.com> wrote:
>
>
> Is anyone else interested in getting O2s back up to working status in NetBSD 10.0?

There was some recent bug fix for the boot process
(port-sgimips/58269), it was also recently pulled up to netbsd-10
branch as well. You may try recent HEAD or netbsd-10 kernels from
https://nycdn.netbsd.org/pub/NetBSD-daily/ to see if those boot.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Shields]

Ah, you got my hopes up!

But unfortunately, this makes it freeze even before the first line of kernel output! (Maybe that’s a clue?)

I built a 10.0 system on an arm64 system to use as a faster platform to cross-compile kernels on for testing (I don’t fancy building kernels at 200MHz if I’m going to do it many times). I’ll follow Warner’s suggestion and start with 8.3 + some interval and see if I can find the breaking point.


> On Jun 24, 2024, at 3:18 AM, Andrius V <***@gmail.com> wrote:
>
> Hi
>
> On Mon, Jun 24, 2024 at 4:24 AM Mike Shields <***@shieldsworld.com> wrote:
>>
>>
>> Is anyone else interested in getting O2s back up to working status in NetBSD 10.0?
>
> There was some recent bug fix for the boot process
> (port-sgimips/58269), it was also recently pulled up to netbsd-10
> branch as well. You may try recent HEAD or netbsd-10 kernels from
> https://nycdn.netbsd.org/pub/NetBSD-daily/ to see if those boot.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andrius V]

On Mon, Jun 24, 2024 at 7:10 PM Mike Shields <***@shieldsworld.com> wrote:
>
> Ah, you got my hopes up!
>
> But unfortunately, this makes it freeze even before the first line of kernel output! (Maybe that’s a clue?)
>
> I built a 10.0 system on an arm64 system to use as a faster platform to cross-compile kernels on for testing (I don’t fancy building kernels at 200MHz if I’m going to do it many times). I’ll follow Warner’s suggestion and start with 8.3 + some interval and see if I can find the breaking point.
>

Yes, that's one of the ways to try to identify at least the commit
causing the issue, but might be a bit tedious exercise. I would
suggest to put old kernel to the new image and see if it still boots
to rule out some bootloader issues (not sure how sgimips works here,
but had experience with x86 then the problem was a bootloader, not a
kernel). You can follow sys/sys/param.h 8.99.x version commits for
example (between one version can be lots of commits but, it may help
to narrow the search).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Shields]

On Jun 24, 2024, at 1:20 PM, Andrius V <***@gmail.com> wrote:
>
> On Mon, Jun 24, 2024 at 7:10 PM Mike Shields <***@shieldsworld.com> wrote:
>>
>> I’ll follow Warner’s suggestion and start with 8.3 + some interval and see if I can find the breaking point.
>>
>
> Yes, that's one of the ways to try to identify at least the commit
> causing the issue, but might be a bit tedious exercise. I would
> suggest to put old kernel to the new image and see if it still boots
> to rule out some bootloader issues (not sure how sgimips works here,
> but had experience with x86 then the problem was a bootloader, not a
> kernel). You can follow sys/sys/param.h 8.99.x version commits for
> example (between one version can be lots of commits but, it may help
> to narrow the search).

Just thought I’d give a status update on the attempts to get R5k/R10k IP32 sgimips back to life:

I was able to find the point via bisection, only took about 9 or 10 iterations. On the freebsd-8 branch, the failure starts between 2018-03-07 and 2018-03-08 (a build of 03-97 boots fine, a build of 03-08 freezes after a few lines).

I have been sifting through the changes, and am finding some updates in src/sys/arch/mips/mips/locore.S to be the most suspicious.

I am not familiar with R5k/R10k core setup steps, so I’m just fooling around in the dark for now, testing various reversions in that file, but with no success so far.

I’ll keep plugging away, but if any other interested eyes have more familiarity, feel free to bail me out of these depths! ;-)



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew green]

Mike Shields writes:
> Just thought I'd give a status update on the attempts to get R5k/R10k IP32 sgimips back to life:
>
> I was able to find the point via bisection, only took about 9 or 10 iterations. On the freebsd-8 branch, the failure starts between 2018-03-07 and 2018-03-08 (a build of 03-97 boots fine, a build of 03-08 freezes after a few lines).
>
> I have been sifting through the changes, and am finding some updates in src/sys/arch/mips/mips/locore.S to be the most suspicious.
>
> I am not familiar with R5k/R10k core setup steps, so I'm just fooling around in the dark for now, testing various reversions in that file, but with no success so far.
>
> I'll keep plugging away, but if any other interested eyes have more familiarity, feel free to bail me out of these depths! ;-)

cc: maya@ who made these changes to locore.S rev's 1.211-1.217.


.mrg.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew green]

looking at the total diff, i see two parts that affect sgimips:

- in start: the bits set in cop0 status change. before, we
disabled all but MIPS_SR_BEV (0x400000), then wrote "zero" to
it to disable interrupts as well.
now, we clear everything but MIPS_SR_INT_IE (0x1), then keep
bits (MIPS_SR_TS | MIPS3_SR_RE) (0x200000 | 0x2000000), except
we already cleared those bits just above"(!!!). this ends up
writing zero to cop0 status, like old i guess.

in both cases, we'd then write 0 to cop0 cause.

so the main different will be maybe writing 0 or 0x400000,
then 0, vs maybe writing 0 or 1, and then 0.

- the code to fetch the fpuid now enables MIPS_SR_COP_1_BIT
(0x20000000) in cop0 status before reading MIPS_FIR.


where the other mips changes around this time besides locore.S?

anyway, it shouldn't too hard to try making these the same as
the old code for sgimips (you can ignore eg new octeon or
hpcmips code, for instance.) if you're not sure, we can help.


.mrg.

matthew green writes:
> Mike Shields writes:
> > Just thought I'd give a status update on the attempts to get R5k/R10k IP32 sgimips back to life:
>
> > I was able to find the point via bisection, only took about 9 or 10 iterations. On the freebsd-8 branch, the failure starts between 2018-03-07 and 2018-03-08 (a build of 03-97 boots fine, a build of 03-08 freezes after a few lines).
>
> > I have been sifting through the changes, and am finding some updates in src/sys/arch/mips/mips/locore.S to be the most suspicious.
>
> > I am not familiar with R5k/R10k core setup steps, so I'm just fooling around in the dark for now, testing various reversions in that file, but with no success so far.
>
> > I'll keep plugging away, but if any other interested eyes have more familiarity, feel free to bail me out of these depths! ;-)
>
> cc: maya@ who made these changes to locore.S rev's 1.211-1.217.
>
>
> .mrg.
>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maciej W. Rozycki]

On Sat, 26 Oct 2024, DiTBho Down in The Bunny hole wrote:

> I mean, I know what coherence of the cache means in a multiprocessor
> environment, but I'm a bit confused by what I read for these mono
> processor systems.

For UP it means that there is no bus snooping implemented in the CPU to
support DMA bus masters. Consequently DMA reads will supply data from RAM
regardless if there's dirty data in the CPU's cache for the corresponding
location and DMA writes will update data in RAM only regardless if there's
corresponding data (dirty or clean) in the CPU's cache.

So you need to synchronise RAM with the CPU's cache by hand via software
means for the affected memory area ahead of any DMA transfer, normally by
issuing write-back and invalidate requests for the relevant cache lines
(the MIPS architecture has suitable CPU machine instructions for this
purpose).

In a cache-coherent system this is resolved transparently by hardware and
such synchronisation happens automatically.

HTH,

Maciej

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

> On Oct 27, 2024, at 3:50 PM, DiTBho Down in The Bunny hole <***@gmail.com> wrote:
>
> I wonder why the linux kernel perfectly runs on an O2/R5K, while it
> crashes in less than 10 seconds from boot on an O2/R10K?
> If we assume that it is the CPU that does not implement any
> cache-coherency mechanism, then why does Linux kernel run perfectly on
> an Octane/R10K?

The obvious answer is that there’s a bug in the NetBSD R10K support. My guess is that it doesn’t get tested all that often.

Anyway, a good first crack at figuring out what the bug is would be to know exactly how it crashes. Can you provide that information? Be as specific and detailed as possible.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[i***@t3.rim.or.jp]

Hi All,

I have two O2s, an R12000 400MHz and an R5000SC 200MHz.

1)R12000
On my O2, 9.4 boots fine. Both netbsd-GENERIC32_IP3x and
netbsd-INSTALL32_IP3x are OK.
The log when starting a kernel placed in the IRIX file system via sash is as
follows.

> hinv
System: IP32
Processor: 400 Mhz R12000, with FPU
Primary I-cache size: 32 Kbytes
Primary D-cache size: 32 Kbytes
Secondary cache size: 2 Mbytes
Memory size: 448 Mbytes
Graphics: CRM, Rev C
Audio: A3 version 1
SCSI Disk: scsi(0)disk(2)
SCSI CDROM: scsi(0)cdrom(4)
SCSI Disk: scsi(1)disk(2)
SCSI Disk: scsi(1)disk(3)
> version


PROM Monitor (BE)
Tue Oct 22 10:58:00 PDT 2002
VERSION 4.18
O2 R5K/R7K/R10K/R12K
IRIX 6.5.x IP32prom IP32PROM-v4

> boot -f scsi(1)disk(3)rdisk(0)partition(8)sash
scsi(1)disk(3)rdisk(0)partition(0)NetBSD/netbsd-INSTALL32_IP3x_94
136992+22896+3248+341792+49584d+4620+6880 entry: 0x8ffa5e50
11898512+131872 entry: 0x80069000
[ 1.0000000] phys segment: 0x5e000 @ 0x2000
[ 1.0000000] adding 0x5e000 @ 0x2000 to freelist 0
[ 1.0000000] phys segment: 0xb7a000 @ 0x60000
[ 1.0000000] adding 0x6000 @ 0x60000 to freelist 0
[ 1.0000000] skipping 0xb74000 @ 0x66000 (kernel)
[ 1.0000000] phys segment: 0x176000 @ 0xbda000
[ 1.0000000] adding 0x176000 @ 0xbda000 to freelist 0
[ 1.0000000] phys segment: 0xeb84000 @ 0x1400000
[ 1.0000000] adding 0xeb84000 @ 0x1400000 to freelist 0
[ 1.0000000] phys segment: 0x7c000 @ 0xff84000
[ 1.0000000] adding 0x7c000 @ 0xff84000 to freelist 0
[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
2013,
[ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022,
2023,
[ 1.0000000] 2024
[ 1.0000000] The NetBSD Foundation, Inc. All rights reserved.
[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[ 1.0000000] The Regents of the University of California. All rights
reserved.

[ 1.0000000] NetBSD 9.4 (INSTALL32_IP3x) #0: Sat Apr 20 13:32:22 UTC 2024
[ 1.0000000]
***@mkrepro.NetBSD.org:/usr/src/sys/arch/sgimips/compile/INSTALL32_IP3x
[ 1.0000000] total memory = 255 MB
[ 1.0000000] (6848 KB reserved for ARCS)
[ 1.0000000] avail memory = 235 MB
[ 1.0000000] mainbus0 (root): SGI-IP32 [SGI, 6], 1 processor
[ 1.0000000] cpu0 at mainbus0: MIPS R12000 CPU (0xe35) Rev. 3.5 with
unknown FPC type (0x900) Rev. 0.0
[ 1.0000000] cpu0: 64 TLB entries, 16MB max page size
[ 1.0000000] cpu0: 32KB/64B 2-way set-associative L1 instruction cache
[ 1.0000000] cpu0: 32KB/32B 2-way set-associative write-back L1 data cache
[ 1.0000000] cpu0: 2048KB/64B 2-way set-associative write-back L2 data
cache
[ 1.0000000] crime0 at mainbus0 addr 0x14000000: rev 1.4 (CRIME_ID:
17592186044577)
[ 1.0000000] crmfb0 at mainbus0 addr 0x16000000: SGI CRIME Graphics
Display Engine
[ 1.0000000] crmfb0: device unusable if not setup by firmware
[ 1.0000000] mace0 at mainbus0 addr 0x1f000000
[ 1.0000000] lpt0 at mace0 offset 0x380000 intr 4 intrmask 0xf0000
[ 1.0000000] com0 at mace0 offset 0x390000 intr 4 intrmask 0x3f00000:
ns16550a, working fifo
[ 1.0000000] com0: console
[ 1.0000000] com1 at mace0 offset 0x398000 intr 4 intrmask 0xfc000000:
ns16550a, working fifo
[ 1.0000000] macekbc0 at mace0 offset 0x320000 intr 5 intrmask 0x0: PS2
controller
[ 1.0000000] mcclock0 at mace0 offset 0x3a0000 intrmask 0x0
[ 1.0000000] mec0 at mace0 offset 0x280000 intr 3 intrmask 0x0: MAC-110
Ethernet, rev 1
[ 1.0000000] mec0: Ethernet address 08:00:69:0e:cd:96
[ 1.0000000] nsphy0 at mec0 phy 8: DP83840 10/100 media interface, rev. 1
[ 1.0000000] nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[ 1.0000000] mavb0 at mace0 offset 0x300000 intr 6 intrmask 0x0: AD1843
rev 1
[ 1.0000000] audio0 at mavb0: playback
[ 1.0000000] audio0: slinear_be:16 -> slinear_be:24 2ch 48000Hz, blk 3840
bytes (10ms) for playback
[ 1.0000000] spkr0 at audio0: PC Speaker (synthesized)
[ 1.0000000] wsbell at spkr0 not configured
[ 1.0000000] macepci0 at mace0 offset 0x80000 intr 7 intrmask 0x0: rev 1
[ 1.0000000] pci0 at macepci0 bus 0
[ 1.0000000] ahc0 at pci0 dev 1 function 0: Adaptec aic7880 Ultra SCSI
adapter
[ 1.0000000] ahc0: interrupting at crime interrupt 8
[ 1.0000000] ahc0: Using left over BIOS settings
[ 1.0000000] ahc0: Host Adapter has no SEEPROM. Using default SCSI target
parameters
[ 1.0000000] ahc0: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
[ 1.0000000] scsibus0 at ahc0: 16 targets, 8 luns per target
[ 1.0000000] ahc1 at pci0 dev 2 function 0: Adaptec aic7880 Ultra SCSI
adapter
[ 1.0000000] ahc1: interrupting at crime interrupt 9
[ 1.0000000] ahc1: Using left over BIOS settings
[ 1.0000000] ahc1: Host Adapter has no SEEPROM. Using default SCSI target
parameters
[ 1.0000000] ahc1: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
[ 1.0000000] scsibus1 at ahc1: 16 targets, 8 luns per target
[ 1.0000030] scsibus0: waiting 2 seconds for devices to settle...
[ 1.0710811] scsibus1: waiting 2 seconds for devices to settle...
[ 3.3933196] sd0 at scsibus0 target 2 lun 0: <SGI, IBM DCHS04Y, 3030>
disk fixed
[ 3.6236201] sd0: 4340 MB, 6077 cyl, 9 head, 162 sec, 512 bytes/sect x
8888543 sectors
[ 3.7142354] sd0: sync (50.00ns offset 8), 16-bit (40.000MB/s) transfers,
tagged queueing
[ 4.0847792] cd0 at scsibus0 target 4 lun 0: <TOSHIBA, CD-ROM XM-5401TA,
3605> cdrom removable
[ 4.1975116] cd0: sync (236.00ns offset 15), 8-bit (4.237MB/s) transfers
[ 12.4612445] sd1 at scsibus1 target 2 lun 0: <AVID, ST3146707LW, AS01>
disk fixed
[ 12.5515746] sd1: 136 GB, 90774 cyl, 4 head, 789 sec, 512 bytes/sect x
286749610 sectors
[ 12.6493940] sd1: sync (50.00ns offset 8), 16-bit (40.000MB/s) transfers,
tagged queueing
[ 12.7505645] sd2 at scsibus1 target 3 lun 0: <IBM, DCAS-34330, S65A> disk
fixed
[ 12.9017837] sd2: 4134 MB, 8205 cyl, 6 head, 171 sec, 512 bytes/sect x
8467200 sectors
[ 12.9963642] sd2: sync (50.00ns offset 15), 8-bit (20.000MB/s) transfers,
tagged queueing
[ 16.2460696] WARNING: 1 error while detecting hardware; check system log.
[ 16.3282530] boot device: sd2
[ 16.4328125] root on md0a dumps on md0b
[ 16.4785376] root file system type: ffs
[ 16.5267143] kern.module.path=/stand/sgimips/9.4/modules
Created mfs /dev (282624 byte, 480 inodes)
-sh: tset: not found
erase ^?, werase ^W, kill ^U, intr ^C

Previously, I was able to boot netbsd-INSTALL32_IP3x of 10.0, but it hung up
during the installation. However, when I tried it recently, it just shut
down during the boot up and I couldn't boot it.
After this, it wouldn't turn on, but I've only just managed to revive it
using jumpstart, so I don't have any adding information.

2)R5000SC
On my O2 I could boot 9.0, 8.3 and 7.2 but not 9.1 or later.
When 9.1 or later failed to boot, my O2 froze during kernel boot and the LED
turned amber. At this point, pressing the reset button restarted it. (With
some exceptions noted in P.S.)
I suspect it is PR#57654.
I tried 9.1 by replacing the three changed files with the 9.0 ones, and it
booted up.

> hinv
System: IP32
Processor: 200 Mhz R5000, with FPU
Primary I-cache size: 32 Kbytes
Primary D-cache size: 32 Kbytes
Secondary cache size: 1024 Kbytes
Memory size: 256 Mbytes
Graphics: CRM, Rev C
Audio: A3 version 1
SCSI Disk: scsi(0)disk(1)
SCSI Disk: scsi(0)disk(2)
SCSI CDROM: scsi(0)cdrom(4)
> version


PROM Monitor (BE)
Tue Oct 22 10:58:00 PDT 2002
VERSION 4.18
O2 R5K/R7K/R10K/R12K
IRIX 6.5.x IP32prom IP32PROM-v4

> boot -f scsi(0)cdrom(4)partition(8)ip3xboot
54464+1792 entry: 0x80002000

NetBSD/sgimips 9.1 Bootstrap, Revision 1.5 (Wed Oct 11 17:23:46 UTC 2023)

devopen: scsi(0)cdrom(4)partition(0) type scsi file ip3x
11845872+131824=0xb6c878
[ 1.0000000] phys segment: 0xe000 @ 0x2000
[ 1.0000000] adding 0xe000 @ 0x2000 to freelist 0
[ 1.0000000] phys segment: 0xd40000 @ 0x10000
[ 1.0000000] adding 0x56000 @ 0x10000 to freelist 0
[ 1.0000000] adding 0x182000 @ 0xbce000 to freelist 0
[ 1.0000000] phys segment: 0xec00000 @ 0x1400000
[ 1.0000000] adding 0xec00000 @ 0x1400000 to freelist 0
[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
2004, 2005,
[ 1.0000000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014,
2015, 2016, 2017,
[ 1.0000000] 2018, 2019, 2020 The NetBSD Foundation, Inc. All rights
reserved.
[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[ 1.0000000] The Regents of the University of California. All rights
reserved.

[ 1.0000000] NetBSD 9.1 (INSTALL32_IP3x) #0: Thu Oct 12 02:55:22 JST 2023
[ 1.0000000]
***@netbsd-v.led.t3.rim.or.jp:/home/iwama/NetBSD-9.1-sgimips-indy/usr/obj/
sys/arch/sgimips/compile/INSTALL32_IP3x
[ 1.0000000] total memory = 255 MB
[ 1.0000000] (6848 KB reserved for ARCS)
[ 1.0000000] avail memory = 235 MB
[ 1.0000000] mainbus0 (root): SGI-IP32 [SGI, 0], 1 processor
[ 1.0000000] cpu0 at mainbus0: MIPS R5000 CPU (0x2321) Rev. 2.1 with
built-in FPU Rev. 1.0
[ 1.0000000] cpu0: 48 TLB entries, 16MB max page size
[ 1.0000000] cpu0: 32KB/32B 2-way set-associative L1 instruction cache
[ 1.0000000] cpu0: 32KB/32B 2-way set-associative write-back L1 data cache
[ 1.0000000] cpu0: 1024KB/32B direct-mapped write-through L2 unified cache
[ 1.0000000] crime0 at mainbus0 addr 0x14000000: rev 1.1 (CRIME_ID: 161)
[ 1.0000000] crmfb0 at mainbus0 addr 0x16000000: SGI CRIME Graphics
Display Engine
[ 1.0000000] crmfb0: device unusable if not setup by firmware
[ 1.0000000] mace0 at mainbus0 addr 0x1f000000
[ 1.0000000] lpt0 at mace0 offset 0x380000 intr 4 intrmask 0xf0000
[ 1.0000000] com0 at mace0 offset 0x390000 intr 4 intrmask 0x3f00000:
ns16550a, working fifo
[ 1.0000000] com0: console
[ 1.0000000] com1 at mace0 offset 0x398000 intr 4 intrmask 0xfc000000:
ns16550a, working fifo
[ 1.0000000] macekbc0 at mace0 offset 0x320000 intr 5 intrmask 0x0: PS2
controller
[ 1.0000000] mcclock0 at mace0 offset 0x3a0000 intrmask 0x0
[ 1.0000000] mec0 at mace0 offset 0x280000 intr 3 intrmask 0x0: MAC-110
Ethernet, rev 1
[ 1.0000000] mec0: Ethernet address 08:00:69:05:a4:60
[ 1.0000000] nsphy0 at mec0 phy 31: DP83840 10/100 media interface, rev. 1
[ 1.0000000] nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
100baseT4, auto
[ 1.0000000] mavb0 at mace0 offset 0x300000 intr 6 intrmask 0x0: AD1843
rev 1
[ 1.0000000] audio0 at mavb0: playback
[ 1.0000000] audio0: slinear_be:16 -> slinear_be:24 2ch 48000Hz, blk 3840
bytes (10ms) for playback
[ 1.0000000] spkr0 at audio0: PC Speaker (synthesized)
[ 1.0000000] wsbell at spkr0 not configured
[ 1.0000000] macepci0 at mace0 offset 0x80000 intr 7 intrmask 0x0: rev 1
[ 1.0000000] pci0 at macepci0 bus 0
[ 1.0000000] ahc0 at pci0 dev 1 function 0: Adaptec aic7880 Ultra SCSI
adapter
[ 1.0000000] ahc0: interrupting at crime interrupt 8
[ 1.0000000] ahc0: Using left over BIOS settings
[ 1.0000000] ahc0: Host Adapter has no SEEPROM. Using default SCSI target
parameters
[ 1.0000000] ahc0: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
[ 1.0000000] scsibus0 at ahc0: 16 targets, 8 luns per target
[ 1.0000000] ahc1 at pci0 dev 2 function 0: Adaptec aic7880 Ultra SCSI
adapter
[ 1.0000000] ahc1: interrupting at crime interrupt 9
[ 1.0000000] ahc1: Using left over BIOS settings
[ 1.0000000] ahc1: Host Adapter has no SEEPROM. Using default SCSI target
parameters
[ 1.0000000] ahc1: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
[ 1.0000000] scsibus1 at ahc1: 16 targets, 8 luns per target
[ 1.0000030] scsibus0: waiting 2 seconds for devices to settle...
[ 1.0716207] scsibus1: waiting 2 seconds for devices to settle...
[ 3.1338656] sd0 at scsibus0 target 1 lun 0: <FUJITSU, MAN3184MC, 0108>
disk fixed
[ 3.2250875] sd0: 17366 MB, 30050 cyl, 2 head, 591 sec, 512 bytes/sect x
35566483 sectors
[ 3.3233260] sd0: sync (50.00ns offset 8), 16-bit (40.000MB/s) transfers,
tagged queueing
[ 3.4230386] sd1 at scsibus0 target 2 lun 0: <MAXTOR, ATLAS10K5_73SCA,
JS03> disk fixed
[ 3.5177076] sd1: 69809 MB, 81782 cyl, 2 head, 874 sec, 512 bytes/sect x
142969680 sectors
[ 3.6180393] sd1: sync (50.00ns offset 8), 16-bit (40.000MB/s) transfers,
tagged queueing
[ 3.9886950] cd0 at scsibus0 target 4 lun 0: <TOSHIBA, CD-ROM XM-5401TA,
3605> cdrom removable
[ 4.1015337] cd0: sync (236.00ns offset 15), 8-bit (4.237MB/s) transfers
[ 16.0253745] WARNING: 1 error while detecting hardware; check system log.
[ 16.1071668] boot device: <unknown>
[ 16.1480027] root on md0a dumps on md0b
[ 16.1898947] root file system type: ffs
[ 16.2380823] kern.module.path=/stand/sgimips/9.1/modules
[ 16.3009134] WARNING: clock lost 10145 days
[ 16.3501358] WARNING: using filesystem time
[ 16.3993676] WARNING: CHECK AND RESET THE DATE!
Created mfs /dev (282624 byte, 480 inodes)
-sh: tset: not found
erase ^?, werase ^W, kill ^U, intr ^C

The three files replaced:
sys/arch/mips/include/cache_r5k.h
sys/arch/mips/mips/cache_r5k.c
sys/arch/mips/mips/cache_r5k_subr.S

I was also able to get 10.0 to boot by replacing three files.

> boot -f scsi(0)disk(1)rdisk(0)partition(8)sash
scsi(0)disk(1)rdisk(0)partition(0)NetBSD/10.0-r5k/netbsd-INSTALL32_IP3x
136992+22896+3248+341792+49584d+4620+6880 entry: 0x8ffa5e50
12132496+130944 entry: 0x80069000
[ 1.0000000] phys segment: 0x5e000 @ 0x2000
[ 1.0000000] adding 0x5e000 @ 0x2000 to freelist 0
[ 1.0000000] phys segment: 0xbb2000 @ 0x60000
[ 1.0000000] adding 0x6000 @ 0x60000 to freelist 0
[ 1.0000000] skipping 0xbac000 @ 0x66000 (kernel)
[ 1.0000000] phys segment: 0x13c000 @ 0xc14000
[ 1.0000000] adding 0x13c000 @ 0xc14000 to freelist 0
[ 1.0000000] phys segment: 0xeb84000 @ 0x1400000
[ 1.0000000] adding 0xeb84000 @ 0x1400000 to freelist 0
[ 1.0000000] phys segment: 0x7c000 @ 0xff84000
[ 1.0000000] adding 0x7c000 @ 0xff84000 to freelist 0
[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
2013,
[ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022,
2023,
[ 1.0000000] 2024
[ 1.0000000] The NetBSD Foundation, Inc. All rights reserved.
[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[ 1.0000000] The Regents of the University of California. All rights
reserved.

[ 1.0000000] NetBSD 10.0 (INSTALL32_IP3x) #0: Wed Jul 3 12:20:58 JST 2024
[ 1.0000000]
***@netbsd-v.led.t3.rim.or.jp:/home/iwama/NetBSD-10.0-sgimips-r5k/usr/obj/
sys/arch/sgimips/compile/INSTALL32_IP3x
[ 1.0000000] total memory = 255 MB
[ 1.0000000] (6848 KB reserved for ARCS)
[ 1.0000000] avail memory = 234 MB
[ 1.0000000] mainbus0 (root): SGI-IP32 [SGI, 0], 1 processor
[ 1.0000000] cpu0 at mainbus0: MIPS R5000 CPU (0x2321) Rev. 2.1 with
built-in FPU Rev. 1.0
[ 1.0000000] cpu0: 48 TLB entries, 16MB max page size
[ 1.0000000] cpu0: 32KB/32B 2-way set-associative L1 instruction cache
[ 1.0000000] cpu0: 32KB/32B 2-way set-associative write-back L1 data cache
[ 1.0000000] cpu0: 1024KB/32B direct-mapped write-through L2 unified cache
[ 1.0000000] crime0 at mainbus0 addr 0x14000000: rev 1.1 (CRIME_ID: 161)
[ 1.0000000] crmfb0 at mainbus0 addr 0x16000000: SGI CRIME Graphics
Display Engine
[ 1.0000000] crmfb0: device unusable if not setup by firmware
[ 1.0000000] mace0 at mainbus0 addr 0x1f000000
[ 1.0000000] lpt0 at mace0 offset 0x380000 intr 4 intrmask 0xf0000
[ 1.0000000] com0 at mace0 offset 0x390000 intr 4 intrmask 0x3f00000:
ns16550a, 16-byte FIFO
[ 1.0000000] com0: console
[ 1.0000000] com1 at mace0 offset 0x398000 intr 4 intrmask 0xfc000000:
ns16550a, 16-byte FIFO
[ 1.0000000] macekbc0 at mace0 offset 0x320000 intr 5 intrmask 0x0: PS2
controller
[ 1.0000000] mcclock0 at mace0 offset 0x3a0000 intrmask 0x0
[ 1.0000000] mec0 at mace0 offset 0x280000 intr 3 intrmask 0x0: MAC-110
Ethernet, rev 1
[ 1.0000000] mec0: Ethernet address 08:00:69:05:a4:60
[ 1.0000000] nsphy0 at mec0 phy 31: DP83840 10/100 media interface, rev. 1
[ 1.0000000] nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
100baseT4, auto
[ 1.0000000] mavb0 at mace0 offset 0x300000 intr 6 intrmask 0x0: AD1843
rev 1
[ 1.0000000] audio0 at mavb0: playback
[ 1.0000000] audio0: slinear_be:16 -> slinear_be:24 2ch 48000Hz, blk 3840
bytes (10ms) for playback
[ 1.0000000] spkr0 at audio0: PC Speaker (synthesized)
[ 1.0000000] wsbell at spkr0 not configured
[ 1.0000000] macepci0 at mace0 offset 0x80000 intr 7 intrmask 0x0: rev 1
[ 1.0000000] pci0 at macepci0 bus 0
[ 1.0000000] ahc0 at pci0 dev 1 function 0: Adaptec aic7880 Ultra SCSI
adapter
[ 1.0000000] ahc0: interrupting at crime interrupt 8
[ 1.0000000] ahc0: Using left over BIOS settings
[ 1.0000000] ahc0: Host Adapter has no SEEPROM. Using default SCSI target
parameters
[ 1.0000000] ahc0: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
[ 1.0000000] scsibus0 at ahc0: 16 targets, 8 luns per target
[ 1.0000000] ahc1 at pci0 dev 2 function 0: Adaptec aic7880 Ultra SCSI
adapter
[ 1.0000000] ahc1: interrupting at crime interrupt 9
[ 1.0000000] ahc1: Using left over BIOS settings
[ 1.0000000] ahc1: Host Adapter has no SEEPROM. Using default SCSI target
parameters
[ 1.0000000] ahc1: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
[ 1.0000000] scsibus1 at ahc1: 16 targets, 8 luns per target
[ 1.0000030] scsibus0: waiting 2 seconds for devices to settle...
[ 1.0720794] scsibus1: waiting 2 seconds for devices to settle...
[ 1.1443046] WARNING: system needs entropy for security; see entropy(7)
[ 3.2063158] sd0 at scsibus0 target 1 lun 0: <FUJITSU, MAN3184MC, 0108>
disk fixed
[ 3.2997954] sd0: 17366 MB, 30050 cyl, 2 head, 591 sec, 512 bytes/sect x
35566483 sectors
[ 3.3979275] sd0: sync (50.00ns offset 8), 16-bit (40.000MB/s) transfers,
tagged queueing
[ 3.4974353] sd1 at scsibus0 target 2 lun 0: <MAXTOR, ATLAS10K5_73SCA,
JS03> disk fixed
[ 3.5959757] sd1: 69809 MB, 81782 cyl, 2 head, 874 sec, 512 bytes/sect x
142969680 sectors
[ 3.6952592] sd1: sync (50.00ns offset 8), 16-bit (40.000MB/s) transfers,
tagged queueing
[ 4.3447666] cd0 at scsibus0 target 4 lun 0: <TOSHIBA, CD-ROM XM-5401TA,
3605> cdrom removable
[ 4.4547315] cd0: sync (236.00ns offset 15), 8-bit (4.237MB/s) transfers
[ 18.2085692] WARNING: 1 error while detecting hardware; check system log.
[ 18.2960639] boot device: sd0
[ 18.3406213] root on md0a dumps on md0b
[ 18.3877962] root file system type: ffs
[ 18.4359858] kern.module.path=/stand/sgimips/10.0/modules
Created mfs /dev (282624 byte, 480 inodes)
[ 19.0399028] entropy: best effort
-sh: tset: not found
erase ^?, werase ^W, kill ^U, intr ^C

Regards,
--
Yoshihiko Iwama

P.S.
With some kernels, the power would suddenly shut off during boot, and after
that, the power would not turn on even when I pressed the power switch.
I tried
jumpstart(https://wiki.preterhuman.net/O2_Diagnostics:_The_Jumpstart_Procedu
re) and both were able to boot again.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[i***@t3.rim.or.jp]

Hi All,

I checked a few more things.

1)R12000
I checked whether it would boot on my O2 with R12000, and it all booted with
7.2, 8.3 and 9.[0-3].
This check, and all the previous checks, were done using the serial console.

2)R5000
I regularly use the serial console, but I tried to check whether it would
boot using the graphics console.
I have only tried one so far, but I was unable to boot netbsd-GENERIC32_IP3x
of 9.0 (which could be booted with the serial console).
The kernel started, displayed a few messages, then suddenly shut down before
displaying the copyright message. It won't turn on, so I'm planning on using
jumpstart to recover it.
There seem to be other problems besides PR#57654 mentioned in the previous
email.

Regards,
--
Yoshihiko Iwama



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jonathan Stone]

[[ non-cache-coherent question, rather than speculative execution ]]

For uniprocessor MIPS systems, "non-cache-coherent" usually means that changing memory via DMA is not reflected in the caches.
Software has to explicitly invalidate any cache entries for a page, after a DMA write (I/O read operation) on a page completes. That includes both I-cache(s) and D-cache(s). If your caches are write-back rather than write-through, you may also need to push any matching (and therefore dirty) D-cache lines to memory, before a DMA read (I/O write operation).

The I-cache and D-cache are also not coherent with each other. So if you modify code on the fly -- for example, setting a breakpoint by writing an invalid instruction into code -- you will need to flush any possible I-cache hit for the modified memory location(s).

The above is accurate for MIPS R2000A/R3000 and R4000/R4400. I've not personally delved that deep on an R10000.

[DiTBho Down in The Bunny hole]

> A hardware workaround may have been implemented in a later system, or a
> later stepping of the CPU may have the erratum fixed. Also the crash may
> be unrelated. You may have to debug it yourself.

Linux never worked on O2/R10K, while, as far as I know, it worked on
IP28 only with patched gcc to force "cache barrier" workarounds.
I cannot find those patches, and I haven't yet understood the issue.

> > I think (my speculation) the hw-mechanism, it implemented, is external
> > to the CPU, but there is more that is not yet clear to me.
>
> In the R4k and R10k architecture coherency logic is on-chip of all the
> participating agents, both CPU(s) and DMA masters. See the diagrams in
> the respective processor manuals for an overview.

So, I wonder why IP30 doesn't suffer from this issue ...

I see that Linux, NetBSD and OpenBSD all work fine on IP30, even with
a couple of { R10K, R12K, R14K } CPUs!

The R10K is documented as a four-way superscalar design that
implements register renaming and executes instructions out-of-order.
I wonder if the problem is related to this "out-of-order" nature of
the CPU paired with the Branch Prediction and Speculative Execution
nature of a purist RISC design.

Thinking about that, although one or more instructions may begin
execution during each cycle, and each instruction takes several or
many cycles to complete, when a branch instruction is decoded, its
branch condition may not yet be known. However, the R10000 processor
can predict whether the branch is taken, and then continue decoding
and executing subsequent instructions along the predicted path.

When a branch prediction is wrong, the processor must back up to the
original branch and take the other path. This technique is called
"speculative execution", and whenever the processor discovers a
mispredicted branch, it aborts all speculatively-executed instructions
and restores the processor's state to the state it held before the
branch.

However - the manual says - the cache state is not restored, and this
is clearly a side effect of speculative execution.
Worse still, if the speculative approach involved a Conditional Store
(SC): will it be restored? No, because - the manual says - if the
cache is involved, then it won't be restored, so this is a real mess
that needs at least a sw barrier.

(I can't find software examples, I would like to read them)

I wonder ... is there any hw-mechanism with the IP30 (missing in IP28
and IP32) that saves you when you are playing with cached-memory and
or LL/SC instructions in a conditional block (e.g. semaphore, mutex,
etc)?

if this is *THE* problem.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[DiTBho Down in The Bunny hole]

hi
I remember the XIO-PCI was only supported in Linux kernel 2.6.17
(Vanilla + custom patches).

What is the status in NetBSD?

I'd like to use a XIO-PCI "shoe box" to interface a few PCI_cards.
Especially a programmable PCI-FPGA board.

What is the current status of the PCI support?

Please let me know.
D.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[DiTBho Down in The Bunny hole]

Anyone?
Is ip30 of no interest?
Let me know

On Wed, Nov 27, 2024, 9:52 PM DiTBho Down in The Bunny hole <
***@gmail.com> wrote:

> hi
> I remember the XIO-PCI was only supported in Linux kernel 2.6.17
> (Vanilla + custom patches).
>
> What is the status in NetBSD?
>
> I'd like to use a XIO-PCI "shoe box" to interface a few PCI_cards.
> Especially a programmable PCI-FPGA board.
>
> What is the current status of the PCI support?
>
> Please let me know.
> D.
>

[DiTBho Down in The Bunny hole]

hi
I'm using the linux kernel v4.04.197, which is the most stable I have
ever used on rb532.
It seems that the rb532 firmware can't load kernels larger than 7.7Mb

What is the status of linux support for this router?

Does anyone have any idea how to load the latest kernel?

Please let me know!

D.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paul Goyette]

Why are you asking for linux help/support on a netbsd mailing list?


On Wed, 18 Dec 2024, DiTBho Down in The Bunny hole wrote:

> hi
> I'm using the linux kernel v4.04.197, which is the most stable I have
> ever used on rb532.
> It seems that the rb532 firmware can't load kernels larger than 7.7Mb
>
> What is the status of linux support for this router?
>
> Does anyone have any idea how to load the latest kernel?
>
> Please let me know!
>
> D.
>
> !DSPAM:6762f27c61849643976419!
>
>

+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | 1B11 1849 721C 56C8 F63A | ***@whooppee.com |
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | ***@netbsd.org |
| & Network Engineer | | ***@gmail.com |
+---------------------+--------------------------+----------------------+

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[DiTBho Down in The Bunny hole]

hi
found a typo in a #define, see the char "_" is missing.
It silently causes catastrophic consequences to miniPCI devices such
as uart, crypto accelerators, wifi, ...

I found this bug from kernel 4.4 to kernel 6.12.
I think it should be fixed

D.

--- arch/mips/include/asm/h.original 2024-12-17 19:18:40.199000000 -0000
+++ arch/mips/include/asm/mach-rc32434/pci.h 2024-12-17
19:18:40.189000000 -0000
@@ -167,7 +167,7 @@
#define PCI_CFGA_DEV 0x0000f800
#define PCI_CFGA_DEV_INTERN 0
#define PCI_CFGA_BUS_BIT 16
-#define PCI CFGA_BUS 0x00ff0000
+#define PCI_CFGA_BUS 0x00ff0000
#define PCI_CFGA_BUS_TYPE0 0
#define PCI_CFGA_EN (1 << 31)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[DiTBho Down in The Bunny hole]

> For UP it means that there is no bus snooping implemented in the CPU to
> support DMA bus masters. Consequently DMA reads will supply data from RAM
> regardless if there's dirty data in the CPU's cache for the corresponding
> location and DMA writes will update data in RAM only regardless if there's
> corresponding data (dirty or clean) in the CPU's cache.
>
> So you need to synchronise RAM with the CPU's cache by hand via software
> means for the affected memory area ahead of any DMA transfer, normally by
> issuing write-back and invalidate requests for the relevant cache lines
> (the MIPS architecture has suitable CPU machine instructions for this
> purpose).
>
> In a cache-coherent system this is resolved transparently by hardware and
> such synchronisation happens automatically.

Thanks for the clarification =)

I wonder why the linux kernel perfectly runs on an O2/R5K, while it
crashes in less than 10 seconds from boot on an O2/R10K?
If we assume that it is the CPU that does not implement any
cache-coherency mechanism, then why does Linux kernel run perfectly on
an Octane/R10K?

I found these (2) lines in the Linux kernel. Interesting.

Do NetBSD and OpenBSD work on O2/R10K?

I think (my speculation) the hw-mechanism, it implemented, is external
to the CPU, but there is more that is not yet clear to me.
The post(1) on the mailing list talks about a problem specifically
related to the speculatively execution of loads and stores on a
superscalar MIPS4 CPU { R10K, R12K, R14K, R16K }.
R5K belongs to the MIPS3 class, and it's not superscalar.

(1) Post to NetBSD sgimips Mailing List on 29 Jun 2000
http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html

(2) https://github.com/torvalds/linux/blob/master/arch/mips/mm/dma-noncoherent.c

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maciej W. Rozycki]

On Sun, 27 Oct 2024, DiTBho Down in The Bunny hole wrote:

> > In a cache-coherent system this is resolved transparently by hardware and
> > such synchronisation happens automatically.
>
> Thanks for the clarification =)

You are welcome.

> I wonder why the linux kernel perfectly runs on an O2/R5K, while it
> crashes in less than 10 seconds from boot on an O2/R10K?

I think MIPS/Linux matters will best be discussed at
<linux-***@vger.kernel.org>. There are people there who have experience
with running Linux on SGI hardware there (I don't).

> If we assume that it is the CPU that does not implement any
> cache-coherency mechanism, then why does Linux kernel run perfectly on
> an Octane/R10K?

A hardware workaround may have been implemented in a later system, or a
later stepping of the CPU may have the erratum fixed. Also the crash may
be unrelated. You may have to debug it yourself.

> Do NetBSD and OpenBSD work on O2/R10K?

I'll leave answers to this question to the others; I don't know.

> I think (my speculation) the hw-mechanism, it implemented, is external
> to the CPU, but there is more that is not yet clear to me.

In the R4k and R10k architecture coherency logic is on-chip of all the
participating agents, both CPU(s) and DMA masters. See the diagrams in
the respective processor manuals for an overview.

> The post(1) on the mailing list talks about a problem specifically
> related to the speculatively execution of loads and stores on a
> superscalar MIPS4 CPU { R10K, R12K, R14K, R16K }.

There is a section on this erratum in the R10k manual, section 1.7, pp.
21-25. I suggest that you read it, it may help debugging the problem.

> R5K belongs to the MIPS3 class, and it's not superscalar.

The R5k is actually a MIPS IV CPU. And it's dual-issue (between CPU and
FPU instructions). It doesn't implement speculative execution or coherent
operation though.

Maciej

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[m***@NetBSD.org]

On Mon, Jul 01, 2024 at 01:39:56PM +1000, matthew green wrote:
> Mike Shields writes:
> > Just thought I'd give a status update on the attempts to get R5k/R10k IP32 sgimips back to life:
> >
> > I was able to find the point via bisection, only took about 9 or 10 iterations. On the freebsd-8 branch, the failure starts between 2018-03-07 and 2018-03-08 (a build of 03-97 boots fine, a build of 03-08 freezes after a few lines).
> >
> > I have been sifting through the changes, and am finding some updates in src/sys/arch/mips/mips/locore.S to be the most suspicious.
> >
> > I am not familiar with R5k/R10k core setup steps, so I'm just fooling around in the dark for now, testing various reversions in that file, but with no success so far.
> >
> > I'll keep plugging away, but if any other interested eyes have more familiarity, feel free to bail me out of these depths! ;-)
>
> cc: maya@ who made these changes to locore.S rev's 1.211-1.217.
>
>
> .mrg.

I only briefly looked at this, sorry, but I vaguely recall a regression
after my commit that was fixed by macallan.

locore.S 1.219
re-enable 64bit addressing in n32 kernels
Now these work again, at least on my Indy.

I'll try to take a closer look and will replyif I have anything.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[DiTBho Down in The Bunny hole]

hi
"Speculative Execution" is a feature of the R10000 Processor.
I read that is problematic on machines that are Non-Cache Coherent,
such as the IP28 Indigo2 and on R10000/R12000-based IP32 O2 systems.

The first thing I don't understand is what does it mean that they are
"Non-Cache Coherent" systems.

I mean, I know what coherence of the cache means in a multiprocessor
environment, but I'm a bit confused by what I read for these mono
processor systems.

A few more details on the nature of Speculative Execution, and the
issues it poses to the Indigo2 can be found at the following URLs:

1) MIPS R10000 Microprocessor User's Manual (pages 51-55 )
https://web.archive.org/web/20051028113506/http://techpubs.sgi.com/library/manuals/2000/007-2490-001/pdf/007-2490-001.pdf

2) Post to NetBSD sgimips Mailing List on 29 Jun 2000
http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html

however there are no examples.

Can someone explain this matter to me?

Thanks

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Izumi Tsutsui]

> The first thing I don't understand is what does it mean that they are
> "Non-Cache Coherent" systems.

Maybe the following text would help:
"Unix Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers"
https://www.amazon.com/dp/0201633388

and also NetBSD's bus_dma(9) paper:
"A Machine-Independent DMA Framework for NetBSD"
https://www.netbsd.org/docs/kernel/bus_dma.pdf

>> The semantics of the host systemfs cache are also
>> important to devices which wish to perform DMA.
>> Some systems are capable of cache-coherent DMA. On
>> such systems, the cache is often write-through (i.e.
>> stores are written both to the cache and to host mem-
>> ory), or the cache has special snooping logic that can
>> detect access to a memory location for which there is a
>> dirty cache line (which causes the cache to be flushed
>> automatically). Other systems are not capable of cache-
>> coherent DMA. On these systems, software must
>> explicitly flush any data caches before memory-to-
>> device DMA transfers, as well as invalidate soon-to-be-
>> stale cache lines before device-to-memory DMA.

Actually O2 doesn't have bus-snoop, as far as I could see when
I implemented NetBSD's mec(4) and other NIC drivers.
(and it looked SGI used "cacheline size" DMA descriptors to handle it)

---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[DiTBho Down in The Bunny hole]

> Maybe the following text would help:
> "Unix Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers"

thanks for the book, already ordered :)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

I recently bought a new ER-4 device as a backup for my aging ER-3
and installed NetBSD-10 on it. The installation to a USB stick was
flawless, and everything seems to work. I haven't yet tried building
any pkgsrc packages, though.

Denis Ovsienko wrote:
> For posterity, when I raised the dk1 problem last time, the workaround
> was to give either "root=dk1" or "root=wedge:octeon-root" parameter to
> NetBSD kernel from U-boot.

The workaround is still needed but it isn't a big problem because
you'll be prompted to enter it, and the kernel will list all devices.

These U-boot commands boot NetBSD 10 for me:

usb reset
fatload usb 0 $loadaddr netbsd
bootoctlinux root=wedge:octeon-root

PS I would prefer a more common GPT label for a root partition. For
encrypted disks we have NAME=cgd.conf to find and mount /etc/cgd with
cgd configs and NAME=cgdroot to mount an encrypted root partition.

Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

On Sat, Dec 07, 2024 at 03:05:29PM +0000, Alexander Nasonov wrote:
> PS I would prefer a more common GPT label for a root partition. For
> encrypted disks we have NAME=cgd.conf to find and mount /etc/cgd with
> cgd configs and NAME=cgdroot to mount an encrypted root partition.

Is that documented anywhere? I have a root-on-cgd setup and it is completely
different, maybe I can simplify it.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

Martin Husemann wrote:
> On Sat, Dec 07, 2024 at 03:05:29PM +0000, Alexander Nasonov wrote:
> > PS I would prefer a more common GPT label for a root partition. For
> > encrypted disks we have NAME=cgd.conf to find and mount /etc/cgd with
> > cgd configs and NAME=cgdroot to mount an encrypted root partition.
>
> Is that documented anywhere? I have a root-on-cgd setup and it is completely
> different, maybe I can simplify it.

I wanted to document new naming when I worked on it but a manual page
for cgdroot.kmod didn't exist and I didn't have time to write a new
manual page.

Alex


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

On Sat, Dec 07, 2024 at 03:30:48PM +0000, Alexander Nasonov wrote:
> I wanted to document new naming when I worked on it but a manual page
> for cgdroot.kmod didn't exist and I didn't have time to write a new
> manual page.

I don't even use cgdroot.kmod - we should collect relevant documentation
somewhere more central and link it from boot(8) or something.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

Martin Husemann wrote:
> I don't even use cgdroot.kmod - we should collect relevant documentation
> somewhere more central and link it from boot(8) or something.

Wow, I didn't know it was possible. We should definitely work on it
but it's an offtopic on this list.

Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joel]

On 12/8/2024 03:59, Martin Husemann wrote:
> You need to add a coremask option to the bootoctlinux command.
> Mine looks like:
>
> bootoctlinux 0 coremask=0x3

On 12/8/2024 04:03, Nick Hudson wrote:
> I seem to remember you need to pass coremask=0x3 (or similar) to
> bootoctlinux for it to start the AP(s).

Thank you both. My u-boot understanding is minimal (although with any
dive into NetBSD on a new device I'll learn something) but I assume
coremask is handled by u-boot to initialize the cpu before booting the
NetBSD kernel.
With that param, sure enough I see another core in dmesg:
[ 1.0000000] cpu1 at cpunode0 core 1: 500.00MHz
Also checks out with top -1.

For a quick test of multiprocessor, I did a couple simple builds (but
couldn't try make -j 2 on anything in pkgsrc) with no crashes. But I had
a hard freeze pretty quickly with 2 tmux windows each running find / (no
freeze with uniprocessor).

> I have some candidate fixes you might like to try if you do have
problems.
I started with stable but I'm willing to adventure into current as long
as this device has my attention...and patience. Wow, the usb stick I
have on it is slow. I had to let it go overnight to install comp.tgz and
pkgsrc.tgz to play with some minimal packages.

-Joel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

Nick Hudson wrote:
> Last time I tried MP on my erlite2 it wasn't stable, but there have been
> lots of changes since.
>
> I have some candidate fixes you might like to try if you do have problems.

I'm interested too. I have both ER-3 and ER-4, and I can sacrifice one
for experiments.

--
Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[DiTBho Down in The Bunny hole]

that's no good
also it seems there is NO interest for the XIO-PCI of the SGI Octane2

On Mon, Dec 2, 2024 at 6:27 PM Jonathan Stone <***@yahoo.com> wrote:
>
> I have one, and a Shoehorn I got from SGI employees for my O2k. Interested in one for an octane 2, but no access to HW docs.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de