Hi Stan!

On Mon, 2023-07-24 at 15:46 -0600, Stan Johnson wrote:

The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
Ultra 30 with the following error at the PROM:

-----
...
Loaded kernel version 6.4.4
Loading initial ramdisk (23022746 bytes at 0x64000000 phys, 0x40C00000 virt)...
Fast Data Access MMU Miss
ok
-----

I have been running a custom 6.2.10 kernel, and that continues to work.
I'm not sure whether this is related to Joacim Nilsson's cgroup fail
error on his Sun Ultra 5, but the failure message is different. I'll
have to investigate whether this could be a kernel regression.

Thanks for the report.

If you could bisect this issue and report the commit to the original author
who introduced it while CC'ing the SPARC LKML, that would be extremely helpful.

I have some older SPARCs myself, but currently no space to set them up for testing.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 24, 2023 at 03:46:12PM -0600, Stan Johnson wrote:

Hello,

The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
Ultra 30 with the following error at the PROM:

-----
...
Loaded kernel version 6.4.4
Loading initial ramdisk (23022746 bytes at 0x64000000 phys, 0x40C00000 virt)...
Fast Data Access MMU Miss
ok
-----

I have been running a custom 6.2.10 kernel, and that continues to work.
I'm not sure whether this is related to Joacim Nilsson's cgroup fail
error on his Sun Ultra 5, but the failure message is different. I'll
have to investigate whether this could be a kernel regression.

The previous Debian SID kernel that I have is vmlinux-6.1.0-7-sparc64,
and it also results in the "Fast Data Access MMU Miss" error.

An earlier kernel (vmlinux-5.16.0-6-sparc64) works as expected:

# uname -a
Linux ultra-30 5.16.0-6-sparc64 #1 Debian 5.16.18-1 (2022-03-29) sparc64 GNU/Linux

# cat /proc/cpuinfo
cpu : TI UltraSparc II (BlackBird)
fpu : UltraSparc II integrated FPU
pmu : ultra12
prom : OBP 3.9.5 1997/04/11 10:03
type : sun4u
ncpus probed : 1
ncpus active : 1
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0ClkTck : 0000000011a4783f
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis
MMU Type : Spitfire
MMU PGSZs : 8K,64K,512K,4MB

root@ultra-30:~# cat /proc/swaps
Filename Type Size Used Priority
/dev/sda2 partition 1052248 0 -2

# fdisk -l
Disk /dev/sda: 136.73 GiB, 146815737856 bytes, 286749488 sectors
Disk model: ST3146807LC
Geometry: 255 heads, 63 sectors/track, 17849 cylinders
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: sun

Device Start End Sectors Size Id Type Flags /dev/sda1 0 1060289 1060290 517.7M 1 Boot
/dev/sda2 1060290 3164804 2104515 1G 82 Linux swap
/dev/sda3 0 286744184 286744185 136.7G 5 Whole disk
/dev/sda4 3164805 19936664 16771860 8G 83 Linux native
/dev/sda5 19936665 53496449 33559785 16G 83 Linux native
/dev/sda6 53496450 87056234 33559785 16G 83 Linux native
/dev/sda7 87056235 103828094 16771860 8G 83 Linux native
/dev/sda8 103828095 286744184 182916090 87.2G 83 Linux native

-Stan

I will install Debian on my Sun Fire V440 and se whats happen

--
Mvh
Joacim Nilsson
realnovum@gmail.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

SGksDQoNCmludGVyZXN0aW5nIGVycm9yIGFzIHRoZSBsYXRlc3QgT3BlbmluZGlhbmEvU1BBUkMg KEJldGEpICAoaHR0cHM6Ly9kbGMub3BlbmluZGlhbmEuYXVyb3JhLW9wZW5jbG91ZC5vcmcvU1BB UkMvcmVsZWFzZSkgd2FzIHNob3dpbmcgdGhlIHNhbWUgZXJyb3IgQlVUIGluIGEgTVAgZW52aXJv bm1lbnQuDQoNCkVSUk9SOiBMYXN0IFRyYXA6IEZhc3QgRGF0YSBBY2Nlc3MgTU1VIE1pc3MNCg0K Q2hlZXJzDQoNCklnZ2kNCg0KDQrvu79BbSAyNS4wNy4yMywgMTI6MDcgc2NocmllYiAiSm9hY2lt IE5pbHNzb24iIDxyZWFsbm92dW1AZ21haWwuY29tIDxtYWlsdG86cmVhbG5vdnVtQGdtYWlsLmNv bT4+Og0KDQoNCk9uIE1vbiwgSnVsIDI0LCAyMDIzIGF0IDAzOjQ2OjEyUE0gLTA2MDAsIFN0YW4g Sm9obnNvbiB3cm90ZToNCj4gSGVsbG8sDQo+IA0KPiBUaGUgbGF0ZXN0IERlYmlhbiBTSUQga2Vy bmVsICh2bWxpbnV4LTYuNC4wLTEtc3BhcmM2NCkgZmFpbHMgb24gYSBTdW4NCj4gVWx0cmEgMzAg d2l0aCB0aGUgZm9sbG93aW5nIGVycm9yIGF0IHRoZSBQUk9NOg0KPiANCj4gLS0tLS0NCj4gLi4u DQo+IExvYWRlZCBrZXJuZWwgdmVyc2lvbiA2LjQuNA0KPiBMb2FkaW5nIGluaXRpYWwgcmFtZGlz ayAoMjMwMjI3NDYgYnl0ZXMgYXQgMHg2NDAwMDAwMCBwaHlzLCAweDQwQzAwMDAwDQo+IHZpcnQp Li4uDQo+IEZhc3QgRGF0YSBBY2Nlc3MgTU1VIE1pc3MNCj4gb2sNCj4gLS0tLS0NCj4gDQo+IEkg aGF2ZSBiZWVuIHJ1bm5pbmcgYSBjdXN0b20gNi4yLjEwIGtlcm5lbCwgYW5kIHRoYXQgY29udGlu dWVzIHRvIHdvcmsuDQo+IEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgcmVsYXRlZCB0byBK b2FjaW0gTmlsc3NvbidzIGNncm91cCBmYWlsDQo+IGVycm9yIG9uIGhpcyBTdW4gVWx0cmEgNSwg YnV0IHRoZSBmYWlsdXJlIG1lc3NhZ2UgaXMgZGlmZmVyZW50LiBJJ2xsDQo+IGhhdmUgdG8gaW52 ZXN0aWdhdGUgd2hldGhlciB0aGlzIGNvdWxkIGJlIGEga2VybmVsIHJlZ3Jlc3Npb24uDQo+IA0K PiBUaGUgcHJldmlvdXMgRGViaWFuIFNJRCBrZXJuZWwgdGhhdCBJIGhhdmUgaXMgdm1saW51eC02 LjEuMC03LXNwYXJjNjQsDQo+IGFuZCBpdCBhbHNvIHJlc3VsdHMgaW4gdGhlICJGYXN0IERhdGEg QWNjZXNzIE1NVSBNaXNzIiBlcnJvci4NCj4gDQo+IEFuIGVhcmxpZXIga2VybmVsICh2bWxpbnV4 LTUuMTYuMC02LXNwYXJjNjQpIHdvcmtzIGFzIGV4cGVjdGVkOg0KPiANCj4gIyB1bmFtZSAtYQ0K PiBMaW51eCB1bHRyYS0zMCA1LjE2LjAtNi1zcGFyYzY0ICMxIERlYmlhbiA1LjE2LjE4LTEgKDIw MjItMDMtMjkpIHNwYXJjNjQNCj4gR05VL0xpbnV4DQo+IA0KPiAjIGNhdCAvcHJvYy9jcHVpbmZv DQo+IGNwdSA6IFRJIFVsdHJhU3BhcmMgSUkgKEJsYWNrQmlyZCkNCj4gZnB1IDogVWx0cmFTcGFy YyBJSSBpbnRlZ3JhdGVkIEZQVQ0KPiBwbXUgOiB1bHRyYTEyDQo+IHByb20gOiBPQlAgMy45LjUg MTk5Ny8wNC8xMSAxMDowMw0KPiB0eXBlIDogc3VuNHUNCj4gbmNwdXMgcHJvYmVkIDogMQ0KPiBu Y3B1cyBhY3RpdmUgOiAxDQo+IEQkIHBhcml0eSB0bDEgOiAwDQo+IEkkIHBhcml0eSB0bDEgOiAw DQo+IENwdTBDbGtUY2sgOiAwMDAwMDAwMDExYTQ3ODNmDQo+IGNwdWNhcHMgOiBmbHVzaCxzdGJh cixzd2FwLG11bGRpdix2OSxtdWwzMixkaXYzMix2OHBsdXMsdmlzDQo+IE1NVSBUeXBlIDogU3Bp dGZpcmUNCj4gTU1VIFBHU1pzIDogOEssNjRLLDUxMkssNE1CDQo+IA0KPiByb290QHVsdHJhLTMw On4jIGNhdCAvcHJvYy9zd2Fwcw0KPiBGaWxlbmFtZSBUeXBlIFNpemUgVXNlZCBQcmlvcml0eQ0K PiAvZGV2L3NkYTIgcGFydGl0aW9uIDEwNTIyNDggMCAtMg0KPiANCj4gIyBmZGlzayAtbA0KPiBE aXNrIC9kZXYvc2RhOiAxMzYuNzMgR2lCLCAxNDY4MTU3Mzc4NTYgYnl0ZXMsIDI4Njc0OTQ4OCBz ZWN0b3JzDQo+IERpc2sgbW9kZWw6IFNUMzE0NjgwN0xDDQo+IEdlb21ldHJ5OiAyNTUgaGVhZHMs IDYzIHNlY3RvcnMvdHJhY2ssIDE3ODQ5IGN5bGluZGVycw0KPiBVbml0czogc2VjdG9ycyBvZiAx ICogNTEyID0gNTEyIGJ5dGVzDQo+IFNlY3RvciBzaXplIChsb2dpY2FsL3BoeXNpY2FsKTogNTEy IGJ5dGVzIC8gNTEyIGJ5dGVzDQo+IEkvTyBzaXplIChtaW5pbXVtL29wdGltYWwpOiA1MTIgYnl0 ZXMgLyA1MTIgYnl0ZXMNCj4gRGlza2xhYmVsIHR5cGU6IHN1bg0KPiANCj4gRGV2aWNlIFN0YXJ0 IEVuZCBTZWN0b3JzIFNpemUgSWQgVHlwZSBGbGFncw0KPiAvZGV2L3NkYTEgMCAxMDYwMjg5IDEw NjAyOTAgNTE3LjdNIDEgQm9vdA0KPiAvZGV2L3NkYTIgMTA2MDI5MCAzMTY0ODA0IDIxMDQ1MTUg MUcgODIgTGludXggc3dhcA0KPiAvZGV2L3NkYTMgMCAyODY3NDQxODQgMjg2NzQ0MTg1IDEzNi43 RyA1IFdob2xlIGRpc2sNCj4gL2Rldi9zZGE0IDMxNjQ4MDUgMTk5MzY2NjQgMTY3NzE4NjAgOEcg ODMgTGludXggbmF0aXZlDQo+IC9kZXYvc2RhNSAxOTkzNjY2NSA1MzQ5NjQ0OSAzMzU1OTc4NSAx NkcgODMgTGludXggbmF0aXZlDQo+IC9kZXYvc2RhNiA1MzQ5NjQ1MCA4NzA1NjIzNCAzMzU1OTc4 NSAxNkcgODMgTGludXggbmF0aXZlDQo+IC9kZXYvc2RhNyA4NzA1NjIzNSAxMDM4MjgwOTQgMTY3 NzE4NjAgOEcgODMgTGludXggbmF0aXZlDQo+IC9kZXYvc2RhOCAxMDM4MjgwOTUgMjg2NzQ0MTg0 IDE4MjkxNjA5MCA4Ny4yRyA4MyBMaW51eCBuYXRpdmUNCj4gDQo+IC1TdGFuDQo+IA0KSSB3aWxs IGluc3RhbGwgRGViaWFuIG9uIG15IFN1biBGaXJlIFY0NDAgYW5kIHNlIHdoYXRzIGhhcHBlbg0K DQoNCi0tIA0KTXZoDQpKb2FjaW0gTmlsc3Nvbg0KcmVhbG5vdnVtQGdtYWlsLmNvbSA8bWFpbHRv OnJlYWxub3Z1bUBnbWFpbC5jb20+DQoNCg0KDQoNCg==

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 25, 2023 at 12:36:57PM +0000, Ignacio Soriano Hernandez wrote:

Hi,

interesting error as the latest Openindiana/SPARC (Beta) (https://dlc.openindiana.aurora-opencloud.org/SPARC/release) was showing the same error BUT in a MP environment.

ERROR: Last Trap: Fast Data Access MMU Miss

Cheers

Iggi

Am 25.07.23, 12:07 schrieb "Joacim Nilsson" <realnovum@gmail.com <mailto:realnovum@gmail.com>>:

On Mon, Jul 24, 2023 at 03:46:12PM -0600, Stan Johnson wrote:

Hello,

The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
Ultra 30 with the following error at the PROM:

-----
...
Loaded kernel version 6.4.4
Loading initial ramdisk (23022746 bytes at 0x64000000 phys, 0x40C00000 virt)...
Fast Data Access MMU Miss
ok
-----

I have been running a custom 6.2.10 kernel, and that continues to work.
I'm not sure whether this is related to Joacim Nilsson's cgroup fail
error on his Sun Ultra 5, but the failure message is different. I'll
have to investigate whether this could be a kernel regression.

The previous Debian SID kernel that I have is vmlinux-6.1.0-7-sparc64,
and it also results in the "Fast Data Access MMU Miss" error.

An earlier kernel (vmlinux-5.16.0-6-sparc64) works as expected:

# uname -a
Linux ultra-30 5.16.0-6-sparc64 #1 Debian 5.16.18-1 (2022-03-29) sparc64 GNU/Linux

# cat /proc/cpuinfo
cpu : TI UltraSparc II (BlackBird)
fpu : UltraSparc II integrated FPU
pmu : ultra12
prom : OBP 3.9.5 1997/04/11 10:03
type : sun4u
ncpus probed : 1
ncpus active : 1
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0ClkTck : 0000000011a4783f
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis
MMU Type : Spitfire
MMU PGSZs : 8K,64K,512K,4MB

root@ultra-30:~# cat /proc/swaps
Filename Type Size Used Priority
/dev/sda2 partition 1052248 0 -2

# fdisk -l
Disk /dev/sda: 136.73 GiB, 146815737856 bytes, 286749488 sectors
Disk model: ST3146807LC
Geometry: 255 heads, 63 sectors/track, 17849 cylinders
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: sun

Device Start End Sectors Size Id Type Flags
/dev/sda1 0 1060289 1060290 517.7M 1 Boot
/dev/sda2 1060290 3164804 2104515 1G 82 Linux swap
/dev/sda3 0 286744184 286744185 136.7G 5 Whole disk
/dev/sda4 3164805 19936664 16771860 8G 83 Linux native
/dev/sda5 19936665 53496449 33559785 16G 83 Linux native
/dev/sda6 53496450 87056234 33559785 16G 83 Linux native
/dev/sda7 87056235 103828094 16771860 8G 83 Linux native
/dev/sda8 103828095 286744184 182916090 87.2G 83 Linux native

-Stan

I will install Debian on my Sun Fire V440 and se whats happen

--
Mvh
Joacim Nilsson
realnovum@gmail.com <mailto:realnovum@gmail.com>

My SunFire V440 fails in a similar way as my U5.
I dont get any errors bouncing me back to the ok promt though.
Let me know if you want any logs or anything.


--
Mvh
Joacim Nilsson
realnovum@gmail.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jul 31, 2023, at 4:33 PM, Stan Johnson <userm57@yahoo.com> wrote:

I don't think a kernel bisect will identify the issue, since the kernel
boots ok. This has something to do with the initrd, and I don't know how
to troubleshoot that. Any recommendations?

It can still be a bug in the kernel, especially since we’re not seeing this issue on the T5220 and the SPARC-T4.

I bet if you rebuild the initrd for the older kernels, these will still boot fine which would prove my theory.

Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)