Fri, Mar 30, 2018 at 08:42:00PM CEST, ebiederm@xxxxxxxxxxxx wrote: >Rahul Lakkireddy <rahul.lakkireddy@xxxxxxxxxxx> writes: > >> 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. > >The concern was actually how you identify which device that came from. >Where you read the identifier changes but sysfs or /proc/vmcore the >change remains valid. Yeah. I still don't see how you link the dump and the device. Rahul, did you look at the patchset I pointed out? Thanks!
