Commit 68d929862e29 'efi: be more paranoid about available space when creating variables' caused a regression on my EFI-booting desktop. (I'm actually testing on 3.2.41 with several more fixes backported, but this shouldn't matter.) The meaningful DMI IDs for this system are: /sys/devices/virtual/dmi/id/bios_date:08/22/2012 /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/bios_version:4003 /sys/devices/virtual/dmi/id/board_name:P8Z68-V LX /sys/devices/virtual/dmi/id/board_vendor:ASUSTeK Computer INC. It is no longer possible to write any variables; this always fails with -ENOSPC. (It also wasn't possible to delete variables - but I introduced that bug in backporting.) With some extra debug logging I found that query_variable_information yielded: storage_size = 65536 remaining_size = 23760 max_size = 23734 This is not full enough to trigger garbage collection; in fact remaining_size and max_size continue to drop by 36 bytes after each reboot as the BIOS is updating the variable MonotonicCounter-8be4df61-93ca-11d2-aa0d-00e098032b8c. 13 reboots later I had: remaining_size = 23292 I removed the size check and triggered a panic, which uses about 12K in dump variables. After rebooting I had: remaining_size = 39879 So the trigger for garbage collection on this system is somewhere between about 10K and 23K remaining out of the total of 64K. efivars absolutely must allow writing until the point at which garbage collection is triggered. Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp
Attachment:
signature.asc
Description: This is a digitally signed message part