I have made a command pool that does not have the VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT flag set. I submit command buffers, and when those command buffers are completed I reset the pool. I keep the command buffer around, and I get it again, and I begin recording, with the VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT. The validation layer gives me this error:
[VULKAN][INFO] Vulkan validation layer callback: Validation Error: [
VUID-vkBeginCommandBuffer-commandBuffer-00050 ] Object 0: handle =
0x20db70f20c0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle
= 0xcb1c7c000000001b, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0xb24f00f5 | Call to vkBeginCommandBuffer() on VkCommandBuffer 0x20db70f20c0[] attempts to implicitly reset cmdBuffer created from
VkCommandPool 0xcb1c7c000000001b[] that does NOT have the
VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT bit set. The Vulkan
spec states: If commandBuffer was allocated from a VkCommandPool which
did not have the VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT flag
set, commandBuffer must be in the initial state
Now, isn't it in the initial state after I reset the pool?
Related
I have a fairly simple HLSL shader that is being compiled into SPIR-V using DirectxShaderCompiler. Though, using scalar layout causes validation layer error. I have enabled the VK_EXT_SCALAR_BLOCK_LAYOUT_EXTENSION_NAME extension while creating the VkDevice. Is it a validation layer, or dxc bug or do I require an additional flag to generate SPIR-V?
Command to generate SPIR-V:
COMMAND $ENV{VULKAN_SDK}/bin/dxc -spirv -fvk-use-scalar-layout -fvk-invert-y -T vs_6_0 -E ${vertexEntry} ${file} -Fo ${CMAKE_SOURCE_DIR}/Assets/${vertexEntry}.spv
Validation layer error:
Validation Error: [ UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle = 0x1e320175dc0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 | SPIR-V module not valid: Structure id 7 decorated as BufferBlock for variable in Uniform storage class must follow relaxed storage buffer layout rules: member 1 is an improperly straddling vector at offset 12
%Vertex = OpTypeStruct %v3float %v3float %v2float
When calling vkQueuePresentKHR i get the following validation error:
Validation Error: [ VUID-vkMapMemory-size-00680 ] Object 0: handle = 0x8483000000000025, type = VK_OBJECT_TYPE_DEVICE_MEMORY; | MessageID = 0xff4787ab | VkMapMemory: Attempting to map memory range of size zero The Vulkan spec states: If size is not equal to VK_WHOLE_SIZE, size must be greater than 0 (https://vulkan.lunarg.com/doc/view/1.2.148.0/windows/1.2-extensions/vkspec.html#VUID-vkMapMemory-size-00680)
I never called vkMapMemory() directly.
Here is an excerpt of my code: https://gist.github.com/alexandru-cazacu/7847161564daa5f93d1bada39280faa8
Closing RivaTuner Statistics Server fixed the issue.
I had 3 other validation errors caused by it.
As stated in https://vulkan-tutorial.com/FAQ
I get an access violation error in the core validation layer: Make sure that MSI Afterburner / RivaTuner Statistics Server is not
running, because it has some compatibility problems with Vulkan.
How do I send a flow entry to drop a package using Ryu? I've learned from tutorials how to send package out flow entry:
I define the action:
actions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)]
Then the entry itself:
out = ofp_parser.OFPPacketOut(datapath=dp, buffer_id=msg.buffer_id, in_port=msg.in_port,actions=actions)
Send the message to the switch:
dp.send_msg(out)
I'm trying to find the documentation to make this code drop the package instead of flooding, without success. I imagine I'll have to change actions on the first step and fp_parser.OFPPacketOut on the second step. I need someone more experienced on Ryu and developing itself to point me to the right direction. Thank you.
The default disposition of a packet in OpenFlow is to drop the packet. Therefore if you have a Flow Rule that when it matches you want to drop the packet, you should simply have an instruction to CLEAR_ACTIONS and then no other instruction, which means that no other tables will be processed since there is no instruction to process (go to) another table and no actions on it.
Remember to keep in mind your flow priorities. If you have more than one flow rule that will match the packet, the one with the highest priority will be the one to take effect. So your "drop packet" could be hidden behind a higher priority flow rule.
Here is some code that I have that will drop all traffic that matches a given EtherType, assuming that no higher priority packet matches. The function is dependent on a couple of instance variables, namely datapath, proto, and parser.
def dropEthType(self,
match_eth_type = 0x0800):
parser = self.parser
proto = self.proto
match = parser.OFPMatch(eth_type = match_eth_type)
instruction = [
parser.OFPInstructionActions(proto.OFPIT_CLEAR_ACTIONS, [])
]
msg = parser.OFPFlowMod(self.datapath,
table_id = OFDPA_FLOW_TABLE_ID_ACL_POLICY,
priority = 1,
command = proto.OFPFC_ADD,
match = match,
instructions = instruction
)
self._log("dropEthType : %s" % str(msg))
reply = api.send_msg(self.ryuapp, msg)
if reply:
raise Exception
I am attempting to create a boot loader which allows me to update a processor's software remotely.
I am using keil uvision compiler (V5.20.0.0).
Flash.c, startup_efm32zg.s, startup_efm32zg.c and em_dma.c configured to execute from RAM (code, Zero init data, other data) via their options/properties tabs.
Stack size configured at 0x0000 0800 via the startup_efm32zg.s Configuration Wizard tab.
Using Silicon Labs flash.c and flash.h, removed RAMFUNC as this is redundant to Keil configuration, above.
I modified the flash.c code slightly so it stays in the FLASH_write function (supposedly in RAM) until the DMA is done doing its thing.
I moved the
while (DMA->CHENS & DMA_CHENS_CH0ENS);
line down to the end of the function and added a little wrapper around it like this:
/* Activate channel 0 */
DMA->CHENS = DMA_CHENS_CH0ENS;
if (DMA->CHENS & DMA_CHENS_CH0ENS)
{
/* Start the transfer */
MSC->WRITECMD = MSC_WRITECMD_WRITETRIG;
/* Wait until transfer is done */
while (DMA->CHENS & DMA_CHENS_CH0ENS)
{
//do nothing here
}
}
FLASH_init() is called as part of the initial setup prior to entering my infinite loop.
When called upon to update the flash.....
(1): I disable interrupts.
(2): I call FLASH_erasePage starting at 0x0000 2400. This works.
(3): I call FLASH_write.
FLASH_write(&startAddress, (uint32_t *)flashBuffer, (BLOCK_SIZE/4));
Where:
startAddress = 0x00002400,
flashBuffer = a buffer of type uint8_t flashBuffer[256],
#define BLOCK_SIZE = 256.
It gets stuck here in the function:
while (DMA->CHENS & DMA_CHENS_CH0ENS)
Eventually the debugger execution stops and the Call Stack clears to be left with 0x00000000 and ALL of memory is displayed as 0xAA.
I have set aside 9K of flash for the bootloader. After a build I am told:
Program size: Code=7524 RO-data=304 RW-data=664 ZI-data=3432
Target Memory Options for Target1:
IROM1: Start[0x0] Size[0x2400]
IRAM1: Start[0x20000000] Size:[0x1000]
So .... what on earth is going on? Any help?
One of my other concerns is that it is supposed to be executing from RAM. When I look in the in the Call Stack for the Location/Value for FLASH_write after having stepped into the FLASH_write function I see 0x000008A4. This is flash!(?)
I've tried the whole RAM_FUNC thing, too with the same results.
I am using pipes to transfer information between two vxWorks tasks.
Here is a code sample:
Init()
{
fd = open("/pipe/mydev", O_RDWR, 0777);
...
}
taskRx()
{
...
len = read(fd, rxbuf, MAX_RX_LEN);
...
}
taskTx()
{
...
len = write(fd, txbuf, txLen);
...
}
If we send a message that is longer than MAX_RX_LEN, (ie txLen > MAX_RX_LEN) we do 2 reads to get the remainder of the message.
What we noticed is that the 2nd read didn't receive any data!
Why is that?
VxWorks' pipe mechanism is not stream based (unlike unix named pipes).
It is a layer on top of the vxWorks message Queue facility. As such, it has the same limitations as a message queue: when reading from the pipe, you are really reading the entire message. If your receive buffer does not have enough space to store the received data, the overflow is simply discarded.
When doing a receive on a message Queue or a pipe, always make sure the buffer is set to the maximum size of a queue element.