Good Day...
I am not sure you received my previous e-mail. Is this e-mail still valid and
secured? We are an Investment Company that specializes in raising capital for
public or privately owned companies through acquisition, private placement, or
reverse merger.
We are seeking investment
Bjorn,
On 4/28/2018 9:03 AM, ok...@codeaurora.org wrote:
>> Hmm, if it is the remove() method then kexec does not use it. kexec use
>> the shutdown() method instead. I missed this details when I replied.
>
> Portdrv hooks up remove handler to shutdown. That's why remove is getting
> called.
Rahul Lakkireddy writes:
> v6:
> - Reworked device dump elf note name to contain vendor identifier.
> - Added vmcoredd_header that precedes actual dump in the Elf Note.
> - Device dump's name is moved inside vmcoredd_header.
> - Added "CHELSIO" string as vendor
Register callback to collect hardware/firmware dumps in second kernel
before hardware/firmware is initialized. The dumps for each device
will be available as elf notes in /proc/vmcore in second kernel.
Signed-off-by: Rahul Lakkireddy
Signed-off-by: Ganesh Goudar
The sequence of actions done by device drivers to append their device
specific hardware/firmware logs to /proc/vmcore are as follows:
1. During probe (before hardware is initialized), device drivers
register to the vmcore module (via vmcore_add_device_dump()), with
callback function, along with
Update read and mmap logic to append device dumps as additional notes
before the other elf notes. We add device dumps before other elf notes
because the other elf notes may not fill the elf notes buffer
completely and we will end up with zero-filled data between the elf
notes and the device dumps.
On production servers running variety of workloads over time, kernel
panic can happen sporadically after days or even months. It is
important to collect as much debug logs as possible to root cause
and fix the problem, that may not be easy to reproduce. Snapshot of
underlying hardware/firmware