Bug 731819

Summary:

biosdevname block boot sequence and initiates CPU lockup

Product:

[Fedora] Fedora

Reporter:

Dmitry S. Makovey <dmitry>

Component:

biosdevname

Assignee:

Praveen K Paladugu <praveen_paladugu>

Status:

CLOSED DUPLICATE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

unspecified

Docs Contact:

Priority:

unspecified

Version:

CC:

harald, matt_domsch, mebrown, narendra_k, praveen_paladugu

Target Milestone:

---

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2011-08-31 03:13:06 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Logs around CPU lockup messages	none

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