Bug 731819 - biosdevname block boot sequence and initiates CPU lockup
Summary: biosdevname block boot sequence and initiates CPU lockup
Keywords:
Status: CLOSED DUPLICATE of bug 707583
Alias: None
Product: Fedora
Classification: Fedora
Component: biosdevname
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Praveen K Paladugu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-18 19:07 UTC by Dmitry S. Makovey
Modified: 2011-08-31 03:13 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-31 03:13:06 UTC


Attachments (Terms of Use)
Logs around CPU lockup messages (16.23 KB, text/plain)
2011-08-18 19:09 UTC, Dmitry S. Makovey
no flags Details

Description Dmitry S. Makovey 2011-08-18 19:07:28 UTC
Description of problem:

On EeePC 901 FC15 stalls during boot time. It seems to resolve to crash initiated by biosdevname:

Aug 17 11:31:14 deeemon kernel: [   36.236180] BUG: soft lockup - CPU#0 stuck for 22s! [biosdevname:536]


Version-Release number of selected component (if applicable):

Fedora 15 with latest updates

How reproducible:

every boot

Steps to Reproduce:
1. install FC15 on EeePC 901
2. boot

  
Actual results:

stall for a minute or two...

Expected results:

immediate boot

Additional info:

If needed - I can provide extra logs

Comment 1 Dmitry S. Makovey 2011-08-18 19:09:35 UTC
Created attachment 518925 [details]
Logs around CPU lockup messages

Comment 2 Harald Hoyer 2011-08-19 08:47:03 UTC
workaround: add "biosdevname=0" to the kernel command line

Comment 3 Dmitry S. Makovey 2011-08-30 22:23:27 UTC
Thanks, done that, but was hoping for a bit more elegant solution

Comment 4 Matt Domsch 2011-08-30 22:32:28 UTC
Dmitry, I'm afraid you'll have to take it up with EeePC.  biosdevname simply reads the PCI VPD data structure that their ethernet device exposes in sysfs like any other PCI device.  Why reading that structure causes a failure, I don't know, but it shouldn't.  We don't have another way to work around it.

Jordan might be willing to accept a patch to add a --novpd option (similar to --nopirq), which you could then use to avoid the problematic device behavior.  Relatively few devices expose useful information in VPD today (it's used on relatively new Dell servers today).  That would require you also patching the udev rules file that invokes biosdevname though, to add the option.

Comment 5 Dmitry S. Makovey 2011-08-30 22:58:36 UTC
Thanks, Matt. Doesn't make me happy but it does make me more educated :) I'll just keep it in my internal FAQ's. Maybe it's worth posting in http://fedoraproject.org/wiki/Eee_PC for people to be aware of the issue, however I don't know how widespread it is. Maybe it's just my machine, or maybe entire batch that day.

Comment 6 Chuck Ebbert 2011-08-31 03:13:06 UTC

*** This bug has been marked as a duplicate of bug 707583 ***


Note You need to log in before you can comment on or make changes to this bug.