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

Submitted by:  chrysn <chrysn>
Submitted on:  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: 
Release:  Git master 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>
Project 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>


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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    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.7