On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote: > Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkireddy@xxxxxxxxxxx wrote: > >Add a new module crashdd that exports the /sys/kernel/crashdd/ > >directory in second kernel, containing collected hardware/firmware > >dumps. > > > >The sequence of actions done by device drivers to append their device > >specific hardware/firmware logs to /sys/kernel/crashdd/ directory are > >as follows: > > > >1. During probe (before hardware is initialized), device drivers > >register to the crashdd module (via crashdd_add_dump()), with > >callback function, along with buffer size and log name needed for > >firmware/hardware log collection. > > > >2. Crashdd creates a driver's directory under > >/sys/kernel/crashdd/<driver>. Then, it allocates the buffer with > > This smells. I need to identify the exact ASIC instance that produced > the dump. To identify by driver name does not help me if I have multiple > instances of the same driver. This looks wrong to me. This looks like > a job for devlink where you have 1 devlink instance per 1 ASIC instance. > > Please see: > http://patchwork.ozlabs.org/project/netdev/list/?series=36524 > > I bevieve that the solution in the patchset could be used for > your usecase too. > > The sysfs approach proposed here had been dropped in favour exporting the dumps as ELF notes in /proc/vmcore. Will be posting the new patches soon. > >requested size and invokes the device driver's registered callback > >function. > > > >3. Device driver collects all hardware/firmware logs into the buffer > >and returns control back to crashdd. > > > >4. Crashdd exposes the buffer as a binary file via > >/sys/kernel/crashdd/<driver>/<dump_file>. > >
