Bugzilla

> Each of these error numbers has three "fields": "nnnn:nn:nn".

I've managed to figure out the third of these fields -- it's the least significant byte of the "conventional" error number that would normally have been used in its place. I confirmed this by comparing calls to `IOAccelContext2::setContextError(unsigned int error)` in the `AMDRadeonX4000` graphics kernel driver on macOS 10.15.7 (build 19H1030) to those in the same kernel driver on macOS 11.4 (build 20F71).

So error number `0x67900fc` on macOS 11.4 and up is comparable to error number `0xfffffffc` ("out of memory") on prior versions of macOS. Likewise, error number `0x1be385f9` is comparable to `0xfffffff9` ("internal error"). These two "conventional" errors have been by far the most common ones on AMD Radeon hardware. So it looks like the new, "custom" error numbers are tracking the same bug or bugs.

I still haven't figured out the first field. I can see patterns in them: For example, calls to `setContextError()` that are close together have very similar first fields, and the one at the larger address always has the larger first field. So they are offsets of some kind, but I haven't yet figured out what kind.

As I noted above, the second field is the "token id" of the token currently being processed.

> Each of these error numbers has three "fields": "nnnn:nn:nn".

I've managed to figure out the third of these fields -- it's the least significant byte of the "conventional" error number that would normally have been used in its place. I confirmed this by comparing calls to `IOAccelContext2::setContextError(unsigned int error)` in the `AMDRadeonX4000` graphics kernel driver on macOS 10.15.7 (build 19H1030) to those in the same kernel driver on macOS 11.4 (build 20F71).

So error number `0x67900fc` on macOS 11.4 and up is comparable to error number `0xfffffffc` ("internal error") on prior versions of macOS. Likewise, error number `0x1be385f9` is comparable to `0xfffffff9` ("out of memory"). These two "conventional" errors have been by far the most common ones on AMD Radeon hardware. So it looks like the new, "custom" error numbers are tracking the same bug or bugs.

I still haven't figured out the first field. I can see patterns in them: For example, calls to `setContextError()` that are close together have very similar first fields, and the one at the larger address always has the larger first field. So they are offsets of some kind, but I haven't yet figured out what kind.

As I noted above, the second field is the "token id" of the token currently being processed.

> Each of these error numbers has three "fields": "nnnn:nn:nn".

I've managed to figure out the third of these fields -- it's the least significant byte of the "conventional" error number that would normally have been used in its place. I confirmed this by comparing calls to `IOAccelContext2::setContextError(unsigned int error)` in the `AMDRadeonX4000` graphics kernel driver on macOS 10.15.7 (build 19H1030) to those in the same kernel driver on macOS 11.4 (build 20F71).

So error number `0x67900fc` on macOS 11.4 and up is comparable to error number `0xfffffffc` ("internal error") on prior versions of macOS. Likewise, error number `0x1be385f9` is comparable to `0xfffffff9` ("out of memory"). These two "conventional" errors have been by far the most common ones on AMD Radeon hardware. So it looks like the new, "custom" error numbers are tracking the same bug or bugs.

I still haven't figured out the first field. I can see patterns in them: For example, calls to `setContextError()` that are close together have very similar first fields, and the one at the larger address always has the larger first field. So they are offsets of some kind, but I haven't yet figured out what kind.

Edit: It's possible the first field is source code line numbers. But we won't ever have the source code, so this won't help us.

As I noted above, the second field is the "token id" of the token currently being processed.