bugGNU GRUB - Bugs: bug #47101, reopening of "simple...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #47101: reopening of "simple network" protocol in efinet causes thinkpad crash

Submitter:  chrysn <chrysn>
Submitted:  Tue 09 Feb 2016 04:45:05 PM UTC
   
 
Category:  Network Severity:  Major
Priority:  6 Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Release:  Git master
Release:  Reproducibility:  Every Time
Planned Release:  2.02

Tue 09 Feb 2016 07:11:16 PM UTC, comment #2: 

as there are no blacklists in grub currently, i'm hard pressed to find the starting points for implementing such a black list.

what are parameters i could query to get anything usable for such a blacklist, like bios vendor plus version number?

chrysn <chrysn>
Tue 09 Feb 2016 05:28:29 PM UTC, comment #1: 


> what are other options?


Implement MNP based network driver that makes this unnecessary.

The code was added to solve a real issues. I'm not entirely opposed to add blacklist as temporary measure as long as we can reliably identify affected platforms.

Andrei Borzenkov <arvidjaar>
Group Member
Tue 09 Feb 2016 04:45:05 PM UTC, original submission:  

when serving grub via pxe to thinkpad configuerd to uefi (x86_64-efi), in particular a thinkpad edge e135 with bios version HMET90WW (2.50) and machine type model 335963G), the system immediately reboots when it hits the grub_efi_open_protocol in drivers/efi/efinet.c's open_card function, right where it says "Try to reopen SNP exlusively to close any active MNP protocol instance that may compete for packet polling" in the comment.

replacing the line with `net = NULL;` in the current master (67dba97e4), things work fine -- the rest of the setup runs smoothly into boot just like it does when the same hardware is set to boot via bios.

now the exclusive protocol reopening looks basically justified in the sense that "just drop the mechanism" is probably not the right solution, but "if you encounter this behavior, try rebuilding grub with said line commented out" or "always use the latest bios version" is probably not either.

what are other options? can the reloading-feature be probed before running it and risking the reboot? can the uefi bios version be queried and the exclusive-reopen bypassed if the version is known to be bad?

chrysn <chrysn>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by phcoder (Updated the item)
  • -email is unavailable- added by arvidjaar (Posted a comment)
  • -email is unavailable- added by chrysn (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-11 phcoder Priority5 - Normal 6
    2016-03-02 phcoder Planned ReleaseNone 2.02

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code