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: NetworkSeverity: Major
Priority: 6Item Group: None
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: OpenRelease: 
Release: Git masterReproducibility: 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
  • -unavailable- added by phcoder (Updated the item)
  • -unavailable- added by arvidjaar (Posted a comment)
  • -unavailable- added by chrysn (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 11 Oct 2016 12:35:32 PM UTCphcoderPriority5 - Normal=>6
    Wed 02 Mar 2016 02:47:46 PM UTCphcoderPlanned ReleaseNone=>2.02

    Back to the top


    Powered by Savane 3.1-cleanup1