Here's a followup on what I said in comment #0, with more detail and a few corrections. The "sideband buffer" is a memory buffer used by graphics drivers, which is double-mapped into kernel-space and user-space. At least on AMD Radeon hardware, there's one buffer per `IOAccelContext`, and (at least in Firefox and Chrome) there's one `IOAccelContext` per browser session. User-mode graphics drivers write "tokens" to this buffer, then send it to kernel-mode graphics drivers to be processed (via calls to `gpusSubmitDataBuffers()` and `IOAccelContextSubmitDataBuffersExt2()`). On AMD Radeon hardware and in Firefox and Chrome, the first three tokens in every batch to be processed are: Token id Name `0x1` Start `0x0` BindDataBuffer `0x85` ResourceList Here's the format of the first part of every "token": typedef struct _token_header { // Offset in IOAccelResource2* fCurrentDataBuffer[2] uint8_t texbuf_id; // Offset 0x0 uint8_t token_id; // Offset 0x1 // The size, in "words" (actually dwords), of the token uint16_t token_size; // Offset 0x2 } token_header; The first context error from comment #0 (`0x67900fc`) is set in `AMDRadeonX4000_AMDSIGLContext::processSidebandToken(IOAccelCommandStreamInfo& info)`, just after a call to `IOAccelGLContext2::processSidebandToken(IOAccelCommandStreamInfo& info)` in its superclass. This error is set if the token's `texbuf_id` and `token_id` are both '0' and `fCurrentDataBuffer[0]` is NULL. So the token in question is "BindDataBuffer", and the error is that `IOAccelContext2::process_token_BindDataBuffer(IOAccelCommandStreamInfo& info)` failed to set `fCurrentDataBuffer[0]` to the `AMDRadeonX4000_AMDAccelResource*` corresponding to the "resource id" in the token's `uint32_t` field at offset `0x8`. The second context error from comment #0 (`0x1be385f9`) is set in `AMDRadeonX4000_AMDSIGLContext::process_ResourceList(IOAccelCommandStreamInfo& info)`, just after a failed call to `AMDRadeonX4000_AMDAccelResource::BatchPrepare()`. A "ResourceList" token is just what it says -- an array of `uint32_t` "resource ids", starting at offset `0x8` in the token, and continuing to its end (some of these may be '0', but they are ignored by `process_ResourceList()`). `BatchPrepare()` is called after `process_ResourceList()` successfully creates an array of `AMDRadeonX4000_AMDAccelResource*` by looking them up by their "resource ids". `BatchPrepare()` is complex, and I haven't yet analyzed why it can fail. All the "custom" error numbers we've seen so far indicate problems that happen at or close to the beginning of the token array in the sideband buffer. I'm going to wait a while for more of these error numbers to accumulate. If they all match the patterns we've seen so far, I'll try to find ways to trigger them (using a [HookCase](https://github.com/steven-michaud/HookCase) hook library).
Bug 1713230 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Here's a followup on what I said in comment #0, with more detail and a few corrections. The "sideband buffer" is a memory buffer used by graphics drivers, which is double-mapped into kernel-space and user-space. At least on AMD Radeon hardware, there's one buffer per `IOAccelContext`, and (at least in Firefox and Chrome) there's one `IOAccelContext` per browser session. User-mode graphics drivers write "tokens" to this buffer, then send it to kernel-mode graphics drivers to be processed (via calls to `gpusSubmitDataBuffers()` and `IOAccelContextSubmitDataBuffersExt2()`). On AMD Radeon hardware and in Firefox and Chrome, the first three tokens in every batch to be processed are: Token id Name 0x1 Start 0x0 BindDataBuffer 0x85 ResourceList Here's the format of the first part of every "token": typedef struct _token_header { // Offset in IOAccelResource2* fCurrentDataBuffer[2] uint8_t texbuf_id; // Offset 0x0 uint8_t token_id; // Offset 0x1 // The size, in "words" (actually dwords), of the token uint16_t token_size; // Offset 0x2 } token_header; The first context error from comment #0 (`0x67900fc`) is set in `AMDRadeonX4000_AMDSIGLContext::processSidebandToken(IOAccelCommandStreamInfo& info)`, just after a call to `IOAccelGLContext2::processSidebandToken(IOAccelCommandStreamInfo& info)` in its superclass. This error is set if the token's `texbuf_id` and `token_id` are both '0' and `fCurrentDataBuffer[0]` is NULL. So the token in question is "BindDataBuffer", and the error is that `IOAccelContext2::process_token_BindDataBuffer(IOAccelCommandStreamInfo& info)` failed to set `fCurrentDataBuffer[0]` to the `AMDRadeonX4000_AMDAccelResource*` corresponding to the "resource id" in the token's `uint32_t` field at offset `0x8`. The second context error from comment #0 (`0x1be385f9`) is set in `AMDRadeonX4000_AMDSIGLContext::process_ResourceList(IOAccelCommandStreamInfo& info)`, just after a failed call to `AMDRadeonX4000_AMDAccelResource::BatchPrepare()`. A "ResourceList" token is just what it says -- an array of `uint32_t` "resource ids", starting at offset `0x8` in the token, and continuing to its end (some of these may be '0', but they are ignored by `process_ResourceList()`). `BatchPrepare()` is called after `process_ResourceList()` successfully creates an array of `AMDRadeonX4000_AMDAccelResource*` by looking them up by their "resource ids". `BatchPrepare()` is complex, and I haven't yet analyzed why it can fail. All the "custom" error numbers we've seen so far indicate problems that happen at or close to the beginning of the token array in the sideband buffer. I'm going to wait a while for more of these error numbers to accumulate. If they all match the patterns we've seen so far, I'll try to find ways to trigger them (using a [HookCase](https://github.com/steven-michaud/HookCase) hook library).
Here's a followup on what I said in comment #0, with more detail and a few corrections. The "sideband buffer" is a memory buffer used by graphics drivers, which is double-mapped into kernel-space and user-space. At least on AMD Radeon hardware, there's one buffer per `IOAccelContext`, and (at least in Firefox and Chrome) there's one `IOAccelContext` per browser session. User-mode graphics drivers write "tokens" to this buffer, then send it to kernel-mode graphics drivers to be processed (via calls to `gpusSubmitDataBuffers()` and `IOAccelContextSubmitDataBuffersExt2()`). On AMD Radeon hardware and in Firefox and Chrome, the first three tokens in every batch to be processed are: Token id Name 0x1 Start 0x0 BindDataBuffer 0x85 ResourceList Here's the format of the first part of every "token": typedef struct _token_header { // Offset in IOAccelResource2* fCurrentDataBuffer[2] uint8_t texbuf_id; // Offset 0x0 uint8_t token_id; // Offset 0x1 // The size, in "words" (actually dwords), of the token uint16_t token_size; // Offset 0x2 } token_header; The first context error from comment #0 (`0x67900fc`) is set in `AMDRadeonX4000_AMDSIGLContext::processSidebandToken(IOAccelCommandStreamInfo& info)`, just after a call to `IOAccelGLContext2::processSidebandToken(IOAccelCommandStreamInfo& info)` in its superclass. This error is set if the token's `texbuf_id` and `token_id` are both '0' and `fCurrentDataBuffer[0]` is NULL. So the token in question is "BindDataBuffer", and the error is that `IOAccelContext2::process_token_BindDataBuffer(IOAccelCommandStreamInfo& info)` failed to set `fCurrentDataBuffer[0]` to the `AMDRadeonX4000_AMDAccelResource*` corresponding to the "resource id" in the token's `uint32_t` field at offset `0x8`. The second context error from comment #0 (`0x1be385f9`) is set in `AMDRadeonX4000_AMDSIGLContext::process_ResourceList(IOAccelCommandStreamInfo& info)`, just after a failed call to `AMDRadeonX4000_AMDAccelResource::BatchPrepare()`. A "ResourceList" token is just what it says -- an array of `uint32_t` "resource ids", starting at offset `0x8` in the token, and continuing to its end (some of these may be '0', but they are ignored by `process_ResourceList()`). `BatchPrepare()` is called after `process_ResourceList()` successfully creates an array of `AMDRadeonX4000_AMDAccelResource*` by looking them up by their "resource ids". `BatchPrepare()` is complex, and I haven't yet analyzed why it can fail. All the "custom" error numbers we've seen so far indicate problems that happen at or close to the beginning of the token array in the sideband buffer. I'm going to wait a while for more of these error numbers to accumulate. If they all match the patterns we've seen so far, I'll try to find ways to trigger them (using a [HookCase](https://github.com/steven-michaud/HookCase) hook library).
Here's a followup on what I said in comment #0, with more detail and a few corrections. The "sideband buffer" is a memory buffer used by graphics drivers, which is double-mapped into kernel-space and user-space. At least on AMD Radeon hardware, there's one buffer per `IOAccelContext`, and (at least in Firefox and Chrome) there's one `IOAccelContext` per browser session. User-mode graphics drivers write "tokens" to this buffer, then send it to kernel-mode graphics drivers to be processed (via calls to `gpusSubmitDataBuffers()` and `IOAccelContextSubmitDataBuffersExt2()`). On AMD Radeon hardware and in Firefox and Chrome, the first three tokens in every batch to be processed are: Token id Name 0x1 Start 0x0 BindDataBuffer 0x85 ResourceList Here's the format of the first part of every "token": typedef struct _token_header { // Offset in IOAccelResource2* fCurrentDataBuffer[2] uint8_t texbuf_id; // Offset 0x0 uint8_t token_id; // Offset 0x1 // The size, in "words" (actually dwords), of the token uint16_t token_size; // Offset 0x2 } token_header; The first context error from comment #0 (`0x67900fc`) is set in `AMDRadeonX4000_AMDSIGLContext::processSidebandToken(IOAccelCommandStreamInfo& info)`, just after a call to `IOAccelGLContext2::processSidebandToken(IOAccelCommandStreamInfo& info)` in its superclass. This error is set if the token's `texbuf_id` and `token_id` are both '0' and `fCurrentDataBuffer[0]` is NULL. So the token in question is "BindDataBuffer", and the error is that `IOAccelContext2::process_token_BindDataBuffer(IOAccelCommandStreamInfo& info)` failed to set `fCurrentDataBuffer[0]` to the `AMDRadeonX4000_AMDAccelResource*` corresponding to the "resource id" in the token's `uint32_t` field at offset `0x8`. The second context error from comment #0 (`0x1be385f9`) is set in `AMDRadeonX4000_AMDSIGLContext::process_ResourceList(IOAccelCommandStreamInfo& info)`, just after a failed call to `AMDRadeonX4000_AMDAccelResource::BatchPrepare()`. A "ResourceList" token is just what it says -- an array of `uint32_t` "resource ids", starting at offset `0x8` in the token, and continuing to its end (some of these may be '0', but they are ignored by `process_ResourceList()`). `BatchPrepare()` is called after `process_ResourceList()` successfully creates an array of `AMDRadeonX4000_AMDAccelResource*` by looking them up by their "resource ids". `BatchPrepare()` is complex, and I haven't yet analyzed why it can fail. All the "custom" error numbers we've seen so far indicate problems that happen at or close to the beginning of the token array in the sideband buffer. I'm going to wait a while for more of these error numbers to accumulate. If they all match the patterns we've seen so far, I'll try to find ways to trigger them (using a [HookCase](https://github.com/steven-michaud/HookCase) hook library).
Here's a followup on what I said in comment #0, with more detail and a few corrections. The "sideband buffer" is a memory buffer used by graphics drivers, which is double-mapped into kernel-space and user-space. At least on AMD Radeon hardware, there's one buffer per `IOAccelContext`, and (at least in Firefox and Chrome) there's one `IOAccelContext` per browser session. User-mode graphics drivers write "tokens" to this buffer, then send it to kernel-mode graphics drivers to be processed (via calls to `gpusSubmitDataBuffers()` and `IOAccelContextSubmitDataBuffersExt2()`). On AMD Radeon hardware and in Firefox and Chrome, the first three tokens in every batch to be processed are: Token id Name 0x1 Start 0x0 BindDataBuffer 0x85 ResourceList Here's the format of the first part of every "token": typedef struct _token_header { // Offset in IOAccelResource2* fCurrentDataBuffer[2] uint8_t texbuf_id; // Offset 0x0 uint8_t token_id; // Offset 0x1 // The size, in "words" (actually dwords), of the token uint16_t token_size; // Offset 0x2 } token_header; The first context error from comment #0 (`0x67900fc`) is set in `AMDRadeonX4000_AMDSIGLContext::processSidebandToken(IOAccelCommandStreamInfo& info)`, just after a call to `IOAccelGLContext2::processSidebandToken(IOAccelCommandStreamInfo& info)` in its superclass. This error is set if the token's `texbuf_id` and `token_id` are both '0' and `fCurrentDataBuffer[0]` is NULL. So the token in question is "BindDataBuffer", and the error is that `IOAccelContext2::process_token_BindDataBuffer(IOAccelCommandStreamInfo& info)` failed to set `fCurrentDataBuffer[0]` to the `AMDRadeonX4000_AMDAccelResource*` corresponding to the "resource id" in the token's `uint32_t` field at offset `0x8`. The second context error from comment #0 (`0x1be385f9`) is set in `AMDRadeonX4000_AMDSIGLContext::process_ResourceList(IOAccelCommandStreamInfo& info)`, just after a failed call to `AMDRadeonX4000_AMDAccelResource::BatchPrepare()`. A "ResourceList" token is just what it says -- an array of `uint32_t` "resource ids", starting at offset `0x8` in the token, and continuing to its end (some of these may be '0', but they are ignored by `process_ResourceList()`). `BatchPrepare()` is called after `process_ResourceList()` successfully creates an array of `AMDRadeonX4000_AMDAccelResource*` by looking them up by their "resource ids". `BatchPrepare()` is complex, and I haven't yet analyzed why it can fail. All the "custom" error numbers we've seen so far indicate problems that happen at or close to the beginning of the token array in the sideband buffer. I'm going to wait a while for more of these error numbers to accumulate. If they all match the patterns we've seen so far, I'll try to find ways to trigger them (using a [HookCase](https://github.com/steven-michaud/HookCase) hook library).
Here's a followup on what I said in comment #0, with more detail and a few corrections. The "sideband buffer" is a memory buffer used by graphics drivers, which is double-mapped into kernel-space and user-space. At least on AMD Radeon hardware, there's one buffer per `IOAccelContext`, and (at least in Firefox and Chrome) there's one `IOAccelContext` per browser session. User-mode graphics drivers write "tokens" to this buffer, then send it to kernel-mode graphics drivers to be processed (via calls to `gpusSubmitDataBuffers()` and `IOAccelContextSubmitDataBuffersExt2()`). On AMD Radeon hardware and in Firefox and Chrome, the first three tokens in every batch to be processed are: Token id Name 0x1 Start 0x0 BindDataBuffer 0x85 ResourceList Here's the format of the first part of every "token": typedef struct _token_header { // Offset in IOAccelResource2* fCurrentDataBuffer[2] uint8_t texbuf_id; // Offset 0x0 uint8_t token_id; // Offset 0x1 // The size, in "words" (actually dwords), of the token uint16_t token_size; // Offset 0x2 } token_header; The first context error from comment #0 (`0x67900fc`) is set in `AMDRadeonX4000_AMDSIGLContext::processSidebandToken(IOAccelCommandStreamInfo& info)`, just after a call to `IOAccelGLContext2::processSidebandToken(IOAccelCommandStreamInfo& info)` in its superclass. This error is set if the token's `texbuf_id` and `token_id` are both '0' and `fCurrentDataBuffer[0]` is NULL. So the token in question is "BindDataBuffer", and the error is that `IOAccelContext2::process_token_BindDataBuffer(IOAccelCommandStreamInfo& info)` failed to set `fCurrentDataBuffer[0]` to the `AMDRadeonX4000_AMDAccelResource*` corresponding to the "resource id" in the token's `uint32_t` field at offset `0x8`. The second context error from comment #0 (`0x1be385f9`) is set in `AMDRadeonX4000_AMDSIGLContext::process_ResourceList(IOAccelCommandStreamInfo& info)`, just after a failed call to `AMDRadeonX4000_AMDAccelResource::BatchPrepare()`. A "ResourceList" token is just what it says -- an array of `uint32_t` "resource ids", starting at offset `0x8` in the token, and continuing to its end (some of these may be '0', but they are ignored by `process_ResourceList()`). `BatchPrepare()` is called after `process_ResourceList()` successfully creates an array of `AMDRadeonX4000_AMDAccelResource*` by looking them up by their "resource ids". `BatchPrepare()` is complex, and I haven't yet analyzed why it can fail. All the "custom" error numbers we've seen so far indicate problems close to the beginning of the token array in the sideband buffer. I'm going to wait a while for more of these error numbers to accumulate. If they all match the patterns we've seen so far, I'll try to find ways to trigger them (using a [HookCase](https://github.com/steven-michaud/HookCase) hook library).