If there is any way to setup LTTng in a way that it writes to logs if there is overflow of log buffer (and hopefully with information how many messsages was dropped)?
For both LTTng tracers, LTTng-UST and LTTng-Modules, the default mode is discard mode which means that events are discarded if the packet is full. When that happens, a counter is incremented in the packet to keep track of how many events were dropped over the course of the trace. Trace readers, such as Babeltrace, can use this data and notify the user about the discarded events when reading the trace.
Babeltrace's output the following when encountering discarded events:
[warning] Tracer discarded 6207 events between [18:57:03.246561940] and [18:57:03.308063186] in trace UUID 6af3e5996b6d3446b41b79c33d81f2ae, at path: "/home/user/lttng-traces/auto-20191213-185557/kernel", within stream id 0, at relative path: "channel0_0". You should consider recording a new trace with larger buffers or with fewer events enabled.
See the doc on channel configuration to learn more on how that works.
If you are asking if it's possible to have an event indicating dropped events in a packet (alongside regular events), then the answer is no. It would be counter-productive to try to write an event about discarded events in an already full packet.
Related
I have been trying to implement a wrapper library for the Linux interface to SCTP sockets, and I am not sure how to integrate the asynchronous style of errors (where they are delivered via events). All example code I have seen, if it deals with the errors at all, simply prints out the information related to the error when it is received, but inserting error-handling code there seems like it would be ineffective, because by that point all of the context related to the original message which was sent has been lost and only a 32-bit integer sinfo_context remains. It also seems that there is no way to directly tell when a given message has been acknowledged successfully by the remote peer, which would make it impossible to implement an approach which listens for errors after sending a message, because the context information for successfully-delivered messages could never be freed.
Is there a way to handle the errors related to a given sending operation as part of the call to a send function, or is there a different way to approach error handling for SCTP which does not lose the context of the error?
One solution which I have considered is using the SCTP_SENDER_DRY notification to tell when packets have been sent, however this requires sending only one packet at a time. Another idea is to use the peer's receiver window size together with the sinfo_cumtsn field of sctp_sndrcvinfo to calculate how much data has been acknowledged as fully received using the cumulative TSN, however there are a couple of disadvantages to this: first, it requires bookkeeping overhead to calculate a number of bytes received by the peer based on the cumulative TSN (especially if the peer's window size may change); second, it requires waiting until all earlier packets were received before reporting success, which seems to defeat the purpose of SCTP's multistreaming; and third, it seems like it would not work for unordered packets.
I'm working on kmdf volume filter driver and wanted to handle shutdown. The article WDM IRPs and KMDF Event Callback and comments in the WDF book seems to suggest that the WDF supports IRP_MJ_SHUTDOWN only for control(non PNP) deivce. So I added call to WdfControlDeviceInitSetShutdownNotification(WdfDeviceShutdown) for my control object and that allowed me to save file to same volume at the time of shutdown. However the document sys that WdfDeviceShutdown is called before flush which I'm not seeing. I've callback for flush using EvtDeviceWdmIrpPreprocess(IRP_MJ_FLUSH). Looking at the Dbg print, I always see flush callback before WdfDeviceShutdown callback.
I wonder if I'm missing something. Any comments on this behavior will help me understand this better. I'm seeing flush before because control device is at volume filter level which is below file system hence executive flushes file system buffer before closing/notifying my device.
Note: If I use WdfControlDeviceInitSetShutdownNotification(WdfDeviceLastChanceShutdown) I get error 0xc0000189 (STATUS_TOO_LATE) when I try to write to the file.
I'm doing some performance testing of my app and noticed that it takes exceedingly long to run some integrations. After a while, I got a whole bunch of
Discarding message for event 0 because of too many unprocessed messages
in the xcode console. What does this mean precisely?
This what Apple Technical Support says about this (after paying $49 for a Developer Tech Support Incident):
These messages are coming from Core Location framework. The most likely cause of these messages is that there isn't a run loop running on the thread on which the CLLocationManager was created. (This implies that the CLLocationManager wasn't created on the main thread.) The messages that are being discarded are location messages: event 0 is a location and event 24 is an authorization status update, for example. Because the messages being discarded, you won't see the appropriate delegate callbacks being invoked. Did you set up a geofence or some other callback and isn't servicing it quickly enough? The queue limit appears to be 10 before it starts dumping events and logging this message.
This information isn't publicly documented yet. I'm working with the Core Location team to improve the reported messages and see if this can be better documented.
Michael is right, the reason is that location manager can only run on thread which has running loop on it (main thread by default), otherwise callbacks sent by it won't be handled. Please see following warning once I tried to initialize Zoosh SDK on a background thread:
NOTICE,A location manager (0x11b5c9d0) was created on a dispatch queue executing on a thread other than the main thread. It is the developer's responsibility to ensure that there is a run loop running on the thread on which the location manager object is allocated. In particular, creating location managers in arbitrary dispatch queues (not attached to the main queue) is not supported and will result in callbacks not being received.
It's clear. And putting the initialization into main thread clears this warning and no 'Discarding message for event 0 because of too many unprocessed messages' occurs.
I am currently working on a hobby OS, specifically the ATA driver. I am having some issues with PIO data-in commands with interrupts. I am trying to execute the READ MULTIPLE command to read multiple sectors from the drive, block by block, with an interrupt firing for each block.
If I request a read of 4 blocks (1 sector per block). I expect to get 4 interrupts, one for each data block. Upon receiving the 4th interrupt I can identify that I've transferred all data and update my request structure accordingly. However, in VirtualBox I've found that after the last data block has been transferred I received yet another interrupt (STATUS = 0x50, READY, OVERLAPPED MODE SERVER REQ). I can simply read the STATUS register then to clear it, but I don't think I should ever receive the 5th interrupt according to the specs.
So what is the proper way acknowledge an interrupt issued by an ATA device?
In this example I issue a READ MULTIPLE command, and then my ISR does the following:
disables CPU interrupts, sets nIEN
Read a single data block (not sector!) fro the DATA register,
If all data has been read, read the STATUS register to clear the 'extra' interrupt
Exit by clearing nIEN, and sending EOI's to both the master and slave PICs
The ATA specs for the PIO data-in command protocol don't indicate that you need to read the status register. From that I assumed that when I receive an interrupt all I have to do is follow the protocol and finish by sending the EOIs to the PICs. As for the setting/clearing of nIEN, in dealing with VirtualBox I've found that if I don't do this I don't receive any interrupts past the first one. So I set nIEN when entering the ISR, then clear it before I leave. I'd think that wouldn't have any effect, but it must be related to reading/writing that specific register.
This always happens to me, I post a question I've been struggling with, only to find the answer myself shortly after.
The ATA-6 spec I've been referencing has this one line in the PIO data-in section (9.5):
When in this state, the host shall read the device Status register.
With ATA the Status register has a side-effect: it clears a pending interrupt. I knew this, but I didn't correctly read this part before. It doesn't mention why you should read the register, it just states it exactly as above.
The important part is how this works with the interrupt handler. After issuing a PIO data-in command, once the INTRQ is asserted, you simply read the Status register once to clear the interrupt, then continue to processes the interrupt and return as normal (just sending EOIs to the PICs.) What had me confused is that none of the documentation I read mentioned exactly how this should work with interrupts (receive an INTRQ, read Status, processes interrupt.) Most online guides only deal with polled IO.
This is one of the difficulties with low-level programming, key details, such as needing to read the Status register in the ISR, are often glanced over. This one was left as a single line in the protocol description. Call me picky but I just would have expected more emphasis on this point.
This question already has an answer here:
How are data breakpoints created?
(1 answer)
Closed 1 year ago.
Requirements:
I need to generate an interrupt, when a memory location changes or is written to. From an ISR, I can trigger a blue screen which gives me a nice stack trace with method names.
Approaches:
Testing the value in the timer ISR. Obviously this doesn't give satisfying results.
I discovered the bochs virtual machine. It has a basic builtin debugger that can set data breakpoints and stop the program. But I can't seem to generate an interrupt at that point.
bochs allows one to connect a gdb to it. I haven't been able to build it with gdb support though.
Other thoughts:
A kind of "preview instruction" interrupt that triggers for every instruction before executing it. The set of used memory-writing instructions should be pretty manageable, but it would still be a PITA to extract the adress I think. And I think there is no such interrupt.
A kind of "preview memory access" interrupt. Again, I don't think its there.
Abuse paging. Mark the page of interest as not present and test the address in the page fault handler. One would still have to distinguish read and write operations and I think, the page fault handler doesn't get to know the exact address, just the page number.
See chapter 16 in Intel's Software Developer's Manual Volume 3A. It gives information about using the debug registers, which provide support for causing the debugger exception when accessing a certain address, among other things. The interrupt will be triggered after the instruction which caused it. Specifically, you will have to set one of dr0-dr3 to the address you want to watch, and dr7 with the proper values to tell the processor what types of accesses should cause the interrupt.