> > On the other hand, patch 5/5 changes the format by adding sequence counter.
> > But efi_pstore_read is modied to work correctly in it.
> >
> > dump-type0-1-1-1351113059-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
> >
> > Variable Name: dump-type0-1-1-1351113059
> > GUID:
On Thu, Oct 25, 2012 at 1:51 PM, Seiji Aguchi wrote:
>> So doesn't this break erasing of existing dumps in pstore-efivars?
>> Unless efi_pstore_read still understands the older variable name formats,
>> users will be stranded with dumps consuming space in
>> efivars that aren't exported via
> So doesn't this break erasing of existing dumps in pstore-efivars?
> Unless efi_pstore_read still understands the older variable name formats,
> users will be stranded with dumps consuming space in
> efivars that aren't exported via pstore anymore.
Patch 2/5, 3/5 and 4/5 don't change an
On Thu, Oct 25, 2012 at 1:03 PM, Seiji Aguchi wrote:
>> > - list_del(>list);
>> > + sprintf(name, "dump-type%u-%u-%lu", type, part,
>> > + get_seconds());
>>
>> Actually, nothing seems to be ensuring that the value used here ends up
>> being the same as the
> > - list_del(>list);
> > + sprintf(name, "dump-type%u-%u-%lu", type, part,
> > + get_seconds());
>
> Actually, nothing seems to be ensuring that the value used here ends up being
> the same as the ctime :\ Consider what happens if the
> get_seconds() call
On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi wrote:
> [Issue]
>
> Currently, efi_pstore driver simply overwrites existing panic messages in
> NVRAM.
> So, in the following scenario, we will lose 1st panic messages.
>
> 1. kernel panics.
> 2. efi_pstore is kicked and writes panic messages to
Acked-by: Mike Waychison
On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi wrote:
> [Issue]
>
> Currently, efi_pstore driver simply overwrites existing panic messages in
> NVRAM.
> So, in the following scenario, we will lose 1st panic messages.
>
> 1. kernel panics.
> 2. efi_pstore is kicked and
Acked-by: Mike Waychison mi...@google.com
On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi seiji.agu...@hds.com wrote:
[Issue]
Currently, efi_pstore driver simply overwrites existing panic messages in
NVRAM.
So, in the following scenario, we will lose 1st panic messages.
1. kernel panics.
On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi seiji.agu...@hds.com wrote:
[Issue]
Currently, efi_pstore driver simply overwrites existing panic messages in
NVRAM.
So, in the following scenario, we will lose 1st panic messages.
1. kernel panics.
2. efi_pstore is kicked and writes panic
- list_del(found-list);
+ sprintf(name, dump-type%u-%u-%lu, type, part,
+ get_seconds());
Actually, nothing seems to be ensuring that the value used here ends up being
the same as the ctime :\ Consider what happens if the
get_seconds() call here
On Thu, Oct 25, 2012 at 1:03 PM, Seiji Aguchi seiji.agu...@hds.com wrote:
- list_del(found-list);
+ sprintf(name, dump-type%u-%u-%lu, type, part,
+ get_seconds());
Actually, nothing seems to be ensuring that the value used here ends up
being the same as
So doesn't this break erasing of existing dumps in pstore-efivars?
Unless efi_pstore_read still understands the older variable name formats,
users will be stranded with dumps consuming space in
efivars that aren't exported via pstore anymore.
Patch 2/5, 3/5 and 4/5 don't change an existing
On Thu, Oct 25, 2012 at 1:51 PM, Seiji Aguchi seiji.agu...@hds.com wrote:
So doesn't this break erasing of existing dumps in pstore-efivars?
Unless efi_pstore_read still understands the older variable name formats,
users will be stranded with dumps consuming space in
efivars that aren't
On the other hand, patch 5/5 changes the format by adding sequence counter.
But efi_pstore_read is modied to work correctly in it.
dump-type0-1-1-1351113059-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
Variable Name: dump-type0-1-1-1351113059
GUID:
[Issue]
Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM.
So, in the following scenario, we will lose 1st panic messages.
1. kernel panics.
2. efi_pstore is kicked and writes panic messages to NVRAM.
3. system reboots.
4. kernel panics again before a user checks
[Issue]
Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM.
So, in the following scenario, we will lose 1st panic messages.
1. kernel panics.
2. efi_pstore is kicked and writes panic messages to NVRAM.
3. system reboots.
4. kernel panics again before a user checks
16 matches
Mail list logo
