https://forums.developer.nvidia.com/...gfaults/240261

https://forums.developer.nvidia.com/...080ti/217512/6

ALSA and a few other .ko also had similar issues i found: not just nvidia.ko

I "solved this problem kinda" by building kernel without CONFIG_FS_POSIX_ACL. http://totally-built-linux-distro.s3...com/index.html

However, I'm wondering if anyone knows what the solution is for when ACL is enabled and or why linux-5.11.8 doesn't work "automagically" as one might expect. (if ACL is changes inode offsets and i_rdev is masked why wouldn't new kernel know and work with that??).

I ask assuming alsa nvidia is well known and they've avoid "destroying compatibility with existing released .ko" and that their use of i_rdev is well known (ie, should not required patches from kernel.org). (note: hpfsplus is also effected: not just alsa and nvidia)

(see posts for details of binary differences in .ko, and question about why the new kernel wouldn't like the new "inode offsets" which is really the advanced question)

If you mean segfaults instead of written "sefaults" consider following:

Segfaults (segfault = short for: segmentation fault) are mostly caused by faulty hardware, e.g. bad RAM sticks, corroded contacts, loose contacts, dying components, incompatible components, misconfigured components (in BIOS/UEFI), overheated components and last but not least OC.

> Arnulf

thank you but no. that's entirely incorrect for Linux (originally for 386 class)

The most common segfault is the "page table" segfault due a program accessing memory outside of it's kernel registered multi-tasking boundaries. Programming the 80386, John H Crawford and Patrick P. Gelsinger (Intel employee). Unlike the competing motorola at the time which could not detect the same fault.

protected mode page table faults are OFTEN printed to screen as segfaults by running programs "for short". segmentation is actually an offsetted memory access technique which can cause page faults. as for "a kernel code reporting a trapped error the memory segmentation was not aligned and so not accessible" - those are truely rare in "C programmed invironments".

Your message is entirely off topic since I already expressed it all works using the RIGHT KERNEL OPTIONS (and or other OS).

update

on nvidia forum, 0x34 v. 0x44 i did "escape" the question if MINOR(inode->i_dev) resulting in 0x34 being in-correct

I evaded asking: if the mask is supposed to always be the same ...

0) i mask i_rdev so I am not asking I/O to set things unrelated which are maybe already stale states and or i'm not allowed to set

1) does ACL cause i_rdev to differ? are the fields in i_rdev changed? if so alsa is popular how could that not be updated?

2) shouldn't masking i_rdev be same value despite where in the struct it IS? always 0x34?

2b) if kernel spoke non-ACL and driver though ACL, then obvious 0x44 would be mask of some random inode entry not the i_rdev one. therfore it wouldn't represent ACL offset stuck into inode struct. nor any change in i_rdev either.

a) the kernel talked to driver with ACL disabled due to lack of some new pre-call? but the driver talked to the kernel with ACL enabled? but how could well known alsa not be update with this pre-call?

b) the header applied bitmask, given the higher value, the mask fails numerically giving the wrong value. someone has fixed it ouside kernel.org GIT for ... "not the right reasons"

b2) the icore2 didn't do the bit operations the way the C kernel header hacker expected? (which is why bit operations should be done extremely carefully with full knowlege of hardware) ie? what is 1U to CPP and is that correctly translated bit per unsigned to gcc and in ASM zero flag pre-set before INSTR if needed? it's allot to expect to say Y. some compilers goof up bitops. (msvc++ has)

? is it the driver's fault for not upgrading itself? but not really: ubuntu's fault for making a change that killed nvidia intel HP/apple mounting competitively. definitely not the driver's fault.

Either way. Alsa is "so prevalent" and an HPFSPLUS disk driver so "critical an application". I just wonder how it could be that enabling ACL causes the problem and I can find no information anywhere about it.

(now, i am solved since i can make a kernel, an OS, and not be required to use ACL - this is not the case for others or if I want to run ubuntu bins in my OS that require ACL - which at this time i don't need)

I didn't say all that trying to keep simple.

But I consider it un-resolved. How could anything so prevalant as ALSA + NVIDIA + HP FS PLUS go "simply un-noticed"?

How could I enable ACL without being warned it could cause hardware damage or freeze mounts?

How could ACL be required by UBUNTU REDHAT if it kills well known drivers thus the hardware?

How could this be happening for say 10 years - me only noticing it recently?

I mean this is NOT a mistake obviously people know the answers. It's too big not to be well known of.

normally i would just say "ok so what, bug, fix it show myself the code or shut up"

but this is not a small situation. these are not "BUGS". and the people who put it there won't accept any update from that would fix (my box).

this was intentional.

i actually am asking: what is it that i'm missing and didn't see? because it must be something big i haven't seen.

Funny, now I thought the segmentation fault related back to some stupid situation in the 8086 or 80286 where they had 20 address lines but only 16bit data registers. So they invented 4 bit paging or segmentation registers for the top 4 bits. Backward compatability ensures all errors and idiosyncrasies are faithfully preserved

These days, segmentation faults = any memory fault or error, usually software related IME.

I would certainly grab the driver again, just in case, check md5sum or whatever. If the sky was falling in, Nvidia would be quick onto any useful info. It's obviously not, so they think their driver is just fine, but have their doubts about you

I'd take that approach. It's your problem on your machine, and probably software. Have a hunt - smartctl, memtest, fsck, restore backup, etc. Hugely irritating, but I'd try to divide & conquer. Nvidia cards are power hungry beasts. Power connectors?