[OpenAFS-devel] AIX debugging help - kernel panic with Open XL C 17.1.0

[Cheyenne Wills]

Hi Ben,

I might be able to give you a hand in this (going off email-list to
avoid flooding the email list)


I'm looking through your changes and I will provide some feedback.

We can also do a zoom chat if you want to talk about some of this.


-- 
Cheyenne Wills
cwills@sinenomine.net



On Mon, 20 Oct 2025 16:23:25 +0000
Ben Huntsman <ben@huntsmans.net> wrote:
> Hi everyone-
>    I could use a little help with this if anyone knows even a little
> about CLANG, and also knows this code better than I do.  I'm still
> working on getting the kernel extension to work under AIX when
> compiled using the new CLANG-based Open XL C 17.1.0.  I have put
> together a few patches which allow it compile successfully and load
> into the kernel without causing a panic.  My changes are on my
> private branch here:
> 
> https://github.com/bhuntsman/openafs/tree/xlc-17.1.0-support
> 
>    Loading of the modules is successful, and once it is, bosserver
> runs fine.  But as soon as I try to start afsd, I get the following
> kernel panic:
> 
> VSX Unavailable
> .afs_UpdateCellLRU+000074           xxlxor    vsr0,vsr0,vsr0
> KDB(1)> where
> pvthread+097F00 STACK:
> [F10009D5B06C22C4]afs_UpdateCellLRU+000074 (00000000017F013F)
> [F10009D5B06C21C0]afs_GetCellByName+000080 (0000000000000000,
> F10009D5B096F390) [F10009D5B06D0680]afs_InitDynroot+00008C ()
> [F10009D5B074F274]afs_syscall_call+000F18 (0000000000000000,
> 0000000020024758, F00000002FF47170, 2800223400000000,
> 000000000079D570, 3B302355DEADBEEF) [F10009D5B074DEFC]syscall+0000C8
> (000000002009C3E8, 000000002009C408, 000000002009C528,
> 0000000000000000, 0000000000000000, 0000000000000000,
> 0000000000000000) [00014D70].hkey_legacy_gate+00004C ()
> [00003984]syscall+000244 ()
> [kdb_get_virtual_doubleword] no real storage @ FFFFFFFF3FFFE70
> 
> KDB(1)>
> 
>    This looks like it's in src/afs/afs_cell.c.  Not entirely sure
> what's going on here but looks like some null pointer problems
> possibly?  This code works fine when compiled using XL C 16.1, even
> with the changes in my private branch linked above.  Is there perhaps
> a CLANG option someone is aware of that might be of use?
> 
>    Any pointers (haha) would be greatly appreciated!
> 
> -Ben
> 
>