Bug 707583 - biosdevname slows down boot dramatically on some devices
biosdevname slows down boot dramatically on some devices
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: biosdevname (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Praveen K Paladugu
Fedora Extras Quality Assurance
:
: 708524 715204 729554 729858 731819 733197 747600 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-25 08:54 EDT by arturj
Modified: 2012-03-19 16:01 EDT (History)
22 users (show)

See Also:
Fixed In Version: biosdevname-0.3.11-1.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 715204 (view as bug list)
Environment:
Last Closed: 2011-10-09 15:52:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
EEE 701: Smolt profile (2.60 KB, text/plain)
2011-05-30 05:07 EDT, Alan Jenkins
no flags Details
dmidecode on affected EeePC 701 (11.93 KB, text/plain)
2011-06-07 16:19 EDT, Alan Jenkins
no flags Details
Kernel log, clean (without the softlockup or other errors) on same EeePC 701 (49.97 KB, text/plain)
2011-06-07 16:22 EDT, Alan Jenkins
no flags Details
acpidump on affected EeePC 701 (114.12 KB, text/plain)
2011-06-07 16:22 EDT, Alan Jenkins
no flags Details
/proc/interrupts on affected EeePC 701 (1.16 KB, text/plain)
2011-06-07 16:23 EDT, Alan Jenkins
no flags Details
dmidcode on EeePC 901, which also appears to be affected (9.31 KB, text/plain)
2011-06-07 16:31 EDT, Alan Jenkins
no flags Details
Upstream patch for this issue (819 bytes, patch)
2011-06-07 18:35 EDT, Prarit Bhargava
no flags Details | Diff
dmesg (69.70 KB, application/octet-stream)
2011-08-19 18:22 EDT, Barbara
no flags Details
dmidecode (16.17 KB, application/octet-stream)
2011-08-19 18:23 EDT, Barbara
no flags Details
biosdecode for EeePC 901 (1.06 KB, text/plain)
2011-09-13 17:18 EDT, Alan Jenkins
no flags Details
Patch for odd & randomly changing slot numbers (1.66 KB, patch)
2011-09-14 08:38 EDT, Alan Jenkins
no flags Details | Diff
lspci -vvvxxxx on EeePC 901 (140.95 KB, text/plain)
2011-09-16 16:37 EDT, Alan Jenkins
no flags Details
dmesg from EeePC 900 (38.15 KB, text/plain)
2011-09-20 13:12 EDT, Gregory Lee Bartholomew
no flags Details
lspci -vvvxxxx from EeePC 900 (13.53 KB, text/plain)
2011-09-20 13:13 EDT, Gregory Lee Bartholomew
no flags Details
dmesg from EeePC 900 with biosdevname 0.3.11 (37.39 KB, text/plain)
2011-09-23 12:45 EDT, Gregory Lee Bartholomew
no flags Details
lspci -vvvxxxx from EeePC 900 with biosdevname 0.3.11 (13.53 KB, text/plain)
2011-09-23 12:46 EDT, Gregory Lee Bartholomew
no flags Details

  None (edit)
Description arturj 2011-05-25 08:54:19 EDT
Description of problem:
Boot delayed (hangs) by 40-60 seconds ons an EEE 901 Netbook

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


How reproducible:


Steps to Reproduce:
1. enable udev debugging
2. reboot
3. check /var/log/messages for udev logs and search for great timestamp delta
4. check if biosdevname is near that place
  
Actual results:


Expected results:


Additional info:
Comment 1 arturj 2011-05-25 08:55:57 EDT
adding biosdevname=0 to kernel parameters resolved the issue as well as uninstalling biosdevname package.
Comment 2 Harald Hoyer 2011-05-25 09:01:59 EDT
can you run it by hand with debug enabled?

# cd /sys/class/net
# for i in *; do time biosdevname  -d -i $i;done
Comment 3 arturj 2011-05-25 15:56:49 EDT
Here is the output:


[root@eee net]# time for i in *; do biosdevname -d -i $i; done
BIOS device: p33p1
Kernel name: eth0
Permanent MAC: 00:23:54:85:B8:E2
Assigned MAC : 00:23:54:85:B8:E2
Driver: ATL1E
Driver version: 1.0.0.7-NAPI
Firmware version: L1e
Bus Info: 0000:04:00.0
PCI name      : 0000:04:00.0
PCI Slot      : 33
Index in slot: 1

BIOS device: p35p1
Kernel name: wlan0
Permanent MAC: 00:22:43:57:E4:71
Assigned MAC : 00:22:43:57:E4:71
Driver: ath5k
Driver version: 2.6.38.6-27.fc15.i686
Firmware version: N/A
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 35
Index in slot: 1

BIOS device: p33p1
Kernel name: eth0
Permanent MAC: 00:23:54:85:B8:E2
Assigned MAC : 00:23:54:85:B8:E2
Driver: ATL1E
Driver version: 1.0.0.7-NAPI
Firmware version: L1e
Bus Info: 0000:04:00.0
PCI name      : 0000:04:00.0
PCI Slot      : 33
Index in slot: 1

BIOS device: p35p1
Kernel name: wlan0
Permanent MAC: 00:22:43:57:E4:71
Assigned MAC : 00:22:43:57:E4:71
Driver: ath5k
Driver version: 2.6.38.6-27.fc15.i686
Firmware version: N/A
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 35
Index in slot: 1

BIOS device: p33p1
Kernel name: eth0
Permanent MAC: 00:23:54:85:B8:E2
Assigned MAC : 00:23:54:85:B8:E2
Driver: ATL1E
Driver version: 1.0.0.7-NAPI
Firmware version: L1e
Bus Info: 0000:04:00.0
PCI name      : 0000:04:00.0
PCI Slot      : 33
Index in slot: 1

BIOS device: p35p1
Kernel name: wlan0
Permanent MAC: 00:22:43:57:E4:71
Assigned MAC : 00:22:43:57:E4:71
Driver: ath5k
Driver version: 2.6.38.6-27.fc15.i686
Firmware version: N/A
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 35
Index in slot: 1


real	2m23.317s
user	0m0.002s
sys	0m0.123s
Comment 4 arturj 2011-05-25 16:00:48 EDT
Also worth a note: when running this strange biosdevname, it eats all cpu for that time, even top won't display anything and my mouse pointer disappears.
Comment 5 arturj 2011-05-25 16:12:19 EDT
Sorry, here is the correct call and output:

[root@eee net]# for i in *; do time biosdevname  -d -i $i;done
BIOS device: p33p1
Kernel name: eth0
Permanent MAC: 00:23:54:85:B8:E2
Assigned MAC : 00:23:54:85:B8:E2
Driver: ATL1E
Driver version: 1.0.0.7-NAPI
Firmware version: L1e
Bus Info: 0000:04:00.0
PCI name      : 0000:04:00.0
PCI Slot      : 33
Index in slot: 1

BIOS device: p35p1
Kernel name: wlan0
Permanent MAC: 00:22:43:57:E4:71
Assigned MAC : 00:22:43:57:E4:71
Driver: ath5k
Driver version: 2.6.38.6-27.fc15.i686
Firmware version: N/A
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 35
Index in slot: 1


real	0m14.344s
user	0m0.000s
sys	0m0.036s
BIOS device: p33p1
Kernel name: eth0
Permanent MAC: 00:23:54:85:B8:E2
Assigned MAC : 00:23:54:85:B8:E2
Driver: ATL1E
Driver version: 1.0.0.7-NAPI
Firmware version: L1e
Bus Info: 0000:04:00.0
PCI name      : 0000:04:00.0
PCI Slot      : 33
Index in slot: 1

BIOS device: p35p1
Kernel name: wlan0
Permanent MAC: 00:22:43:57:E4:71
Assigned MAC : 00:22:43:57:E4:71
Driver: ath5k
Driver version: 2.6.38.6-27.fc15.i686
Firmware version: N/A
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 35
Index in slot: 1


real	0m48.736s
user	0m0.000s
sys	0m0.040s
BIOS device: p33p1
Kernel name: eth0
Permanent MAC: 00:23:54:85:B8:E2
Assigned MAC : 00:23:54:85:B8:E2
Driver: ATL1E
Driver version: 1.0.0.7-NAPI
Firmware version: L1e
Bus Info: 0000:04:00.0
PCI name      : 0000:04:00.0
PCI Slot      : 33
Index in slot: 1

BIOS device: p35p1
Kernel name: wlan0
Permanent MAC: 00:22:43:57:E4:71
Assigned MAC : 00:22:43:57:E4:71
Driver: ath5k
Driver version: 2.6.38.6-27.fc15.i686
Firmware version: N/A
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 35
Index in slot: 1


real	0m48.457s
user	0m0.000s
sys	0m0.037s
Comment 6 Narendra K 2011-05-26 09:53:45 EDT
Hi, 

1. could you please post how much time it takes to boot when biosdevname=0 is passed with udev debugging enabled and udev debugging disabled

2. how much time it takes to boot without biosdevname=0 passed with udev debugging enabled and udev debugging disabled

3. Also, please let me know if you have changed PROGRAM= line in  /lib/udev/rules.d/71-biosdevname.rules and added the '-d' flag to biosdevname.

4. Please post the output of 'time biosdevname -d'.
Comment 7 Alan Jenkins 2011-05-29 09:33:33 EDT
I have encountered this myself on a fresh EEE 701 install.  I believe this bug is the same as

"CPU#1 stuck for 61s! [biosdevname:703]"
https://bugzilla.redhat.com/show_bug.cgi?id=708524

On my system the delay is about 60 seconds.

strace reveals that on my system, the hang (which stops even the console cursor from blinking) occurs while reading the file

/sys/bus/pci/devices/0000:03:00.0/vpd

and indeed I can reproduce it by simply attempting to read that file using "od".  And I can avoid the boot hang if I do "chmod -x /sbin/biosdevname".

The PCI device in question is

03:00.0 0200: 1969:2048 (rev a0)
03:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet (rev a0)

Note: in order to see the softlockup message, I had to tweak the watchdog timeout.  (echo 10 > /proc/sys/kernel/watchdog_thresh).  

Actually, I first reproduced by installing an F13 kernel (which must have a shorter default softlockup timeout or something).  So note: this is not a kernel regression; it shows up on F13 and F14 kernels as well as the stock F15 one.

The resulting call trace, which seems to be missing in the other bug, is:

[ 1245.452789] BUG: soft lockup - CPU#0 stuck for 11s! [od:1454]
[ 1245.453770] Modules linked in: snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec ath5k snd_hwdep snd_seq snd_seq_device ath mac80211 snd_pcm microcode uvcvideo snd_timer cfg80211 snd eeepc_laptop videodev iTCO_wdt ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables i2c_i801 atl2 joydev iTCO_vendor_support soundcore snd_page_alloc sparse_keymap rfkill ipv6 usb_storage uas i915 drm_kms_helper drm i2c_algo_bit i2c_core video
[ 1245.453770] Modules linked in: snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec ath5k snd_hwdep snd_seq snd_seq_device ath mac80211 snd_pcm microcode uvcvideo snd_timer cfg80211 snd eeepc_laptop videodev iTCO_wdt ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables i2c_i801 atl2 joydev iTCO_vendor_support soundcore snd_page_alloc sparse_keymap rfkill ipv6 usb_storage uas i915 drm_kms_helper drm i2c_algo_bit i2c_core video
[ 1245.453770] 
[ 1245.453770] Pid: 1454, comm: od Not tainted 2.6.38.6-27.fc15.i686.PAE #1 ASUSTeK Computer INC. 701/701
[ 1245.453770] EIP: 0060:[<c05e8a63>] EFLAGS: 00000206 CPU: 0
[ 1245.453770] EIP is at __raw_spin_unlock_irq.constprop.4+0x10/0x16
[ 1245.453770] EAX: 00000000 EBX: ddd31800 ECX: c0bfd198 EDX: 00000097
[ 1245.453770] ESI: 0000006e EDI: c0a5c8ec EBP: dd679e40 ESP: dd679e40
[ 1245.453770]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 1245.453770] Process od (pid: 1454, ti=dd678000 task=db988c90 task.ti=dd678000)
[ 1245.453770] Stack:
[ 1245.453770]  dd679e68 c05e8b36 00000002 dd679e58 00000000 dd679e82 00008224 ddcc0c00
[ 1245.453770]  db988c90 ddd31800 dd679e90 c05e8b8f c05e8d5c 00000002 00000224 000e6c70
[ 1245.453770]  02240000 00000000 00000224 00000000 dd679ec4 c05e8e3a 00000000 ddcc0c0c
[ 1245.453770] Call Trace:
[ 1245.453770]  [<c05e8b36>] pci_user_read_config_word+0x63/0x77
[ 1245.453770]  [<c05e8b8f>] pci_vpd_pci22_wait+0x45/0xdb
[ 1245.453770]  [<c05e8d5c>] ? pci_user_write_config_word+0x5f/0x6a
[ 1245.453770]  [<c05e8e3a>] pci_vpd_pci22_read+0xd3/0x15e
[ 1245.453770]  [<c05e867d>] pci_read_vpd+0x41/0x49
[ 1245.453770]  [<c05ef36f>] read_vpd_attr+0x75/0x7d
[ 1245.453770]  [<c0537803>] read+0x135/0x1e9
[ 1245.453770]  [<c059a083>] ? security_file_permission+0x27/0x2b
[ 1245.453770]  [<c05ef2fa>] ? read_vpd_attr+0x0/0x7d
[ 1245.453770]  [<c04ede8f>] vfs_read+0x8d/0xd5
[ 1245.453770]  [<c05376ce>] ? read+0x0/0x1e9
[ 1245.453770]  [<c04edf19>] sys_read+0x42/0x63
[ 1245.453770]  [<c040969f>] sysenter_do_call+0x12/0x28
[ 1245.453770] Code: 01 88 8e cc 04 00 00 b8 d8 10 be c0 e8 9f 05 20 00 84 db 74 02 0f 0b 5b 5e 5d c3 55 89 e5 3e 8d 74 26 00 fe 05 d8 10 be c0 fb 90 <8d> 74 26 00 5d c3 55 89 e5 57 56 53 83 ec 14 3e 8d 74 26 00 89
Comment 8 Alan Jenkins 2011-05-29 11:02:25 EDT
Note: If you disable biosdevname temporarily, the problem will go away PERMANENTLY.

In order to reproduce the problem again, you will have to delete /etc/udev/rules.d/70-persistent-net.rules.
Comment 9 Harald Hoyer 2011-05-30 04:11:19 EDT
(In reply to comment #7)
> I have encountered this myself on a fresh EEE 701 install.  I believe this bug
> is the same as
> 
> "CPU#1 stuck for 61s! [biosdevname:703]"
> https://bugzilla.redhat.com/show_bug.cgi?id=708524
> 
> On my system the delay is about 60 seconds.
> 
> strace reveals that on my system, the hang (which stops even the console cursor
> from blinking) occurs while reading the file
> 
> /sys/bus/pci/devices/0000:03:00.0/vpd
> 
> and indeed I can reproduce it by simply attempting to read that file using
> "od".  And I can avoid the boot hang if I do "chmod -x /sbin/biosdevname".
> 
> The PCI device in question is
> 
> 03:00.0 0200: 1969:2048 (rev a0)
> 03:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet (rev a0)
> 
> Note: in order to see the softlockup message, I had to tweak the watchdog
> timeout.  (echo 10 > /proc/sys/kernel/watchdog_thresh).  
> 
> Actually, I first reproduced by installing an F13 kernel (which must have a
> shorter default softlockup timeout or something).  So note: this is not a
> kernel regression; it shows up on F13 and F14 kernels as well as the stock F15
> one.
> 
> The resulting call trace, which seems to be missing in the other bug, is:
> 
> [ 1245.452789] BUG: soft lockup - CPU#0 stuck for 11s! [od:1454]
> [ 1245.453770] Modules linked in: snd_hda_codec_realtek snd_hda_intel arc4
> snd_hda_codec ath5k snd_hwdep snd_seq snd_seq_device ath mac80211 snd_pcm
> microcode uvcvideo snd_timer cfg80211 snd eeepc_laptop videodev iTCO_wdt
> ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
> i2c_i801 atl2 joydev iTCO_vendor_support soundcore snd_page_alloc sparse_keymap
> rfkill ipv6 usb_storage uas i915 drm_kms_helper drm i2c_algo_bit i2c_core video
> [ 1245.453770] Modules linked in: snd_hda_codec_realtek snd_hda_intel arc4
> snd_hda_codec ath5k snd_hwdep snd_seq snd_seq_device ath mac80211 snd_pcm
> microcode uvcvideo snd_timer cfg80211 snd eeepc_laptop videodev iTCO_wdt
> ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
> i2c_i801 atl2 joydev iTCO_vendor_support soundcore snd_page_alloc sparse_keymap
> rfkill ipv6 usb_storage uas i915 drm_kms_helper drm i2c_algo_bit i2c_core video
> [ 1245.453770] 
> [ 1245.453770] Pid: 1454, comm: od Not tainted 2.6.38.6-27.fc15.i686.PAE #1
> ASUSTeK Computer INC. 701/701
> [ 1245.453770] EIP: 0060:[<c05e8a63>] EFLAGS: 00000206 CPU: 0
> [ 1245.453770] EIP is at __raw_spin_unlock_irq.constprop.4+0x10/0x16
> [ 1245.453770] EAX: 00000000 EBX: ddd31800 ECX: c0bfd198 EDX: 00000097
> [ 1245.453770] ESI: 0000006e EDI: c0a5c8ec EBP: dd679e40 ESP: dd679e40
> [ 1245.453770]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 1245.453770] Process od (pid: 1454, ti=dd678000 task=db988c90
> task.ti=dd678000)
> [ 1245.453770] Stack:
> [ 1245.453770]  dd679e68 c05e8b36 00000002 dd679e58 00000000 dd679e82 00008224
> ddcc0c00
> [ 1245.453770]  db988c90 ddd31800 dd679e90 c05e8b8f c05e8d5c 00000002 00000224
> 000e6c70
> [ 1245.453770]  02240000 00000000 00000224 00000000 dd679ec4 c05e8e3a 00000000
> ddcc0c0c
> [ 1245.453770] Call Trace:
> [ 1245.453770]  [<c05e8b36>] pci_user_read_config_word+0x63/0x77
> [ 1245.453770]  [<c05e8b8f>] pci_vpd_pci22_wait+0x45/0xdb
> [ 1245.453770]  [<c05e8d5c>] ? pci_user_write_config_word+0x5f/0x6a
> [ 1245.453770]  [<c05e8e3a>] pci_vpd_pci22_read+0xd3/0x15e
> [ 1245.453770]  [<c05e867d>] pci_read_vpd+0x41/0x49
> [ 1245.453770]  [<c05ef36f>] read_vpd_attr+0x75/0x7d
> [ 1245.453770]  [<c0537803>] read+0x135/0x1e9
> [ 1245.453770]  [<c059a083>] ? security_file_permission+0x27/0x2b
> [ 1245.453770]  [<c05ef2fa>] ? read_vpd_attr+0x0/0x7d
> [ 1245.453770]  [<c04ede8f>] vfs_read+0x8d/0xd5
> [ 1245.453770]  [<c05376ce>] ? read+0x0/0x1e9
> [ 1245.453770]  [<c04edf19>] sys_read+0x42/0x63
> [ 1245.453770]  [<c040969f>] sysenter_do_call+0x12/0x28
> [ 1245.453770] Code: 01 88 8e cc 04 00 00 b8 d8 10 be c0 e8 9f 05 20 00 84 db
> 74 02 0f 0b 5b 5e 5d c3 55 89 e5 3e 8d 74 26 00 fe 05 d8 10 be c0 fb 90 <8d> 74
> 26 00 5d c3 55 89 e5 57 56 53 83 ec 14 3e 8d 74 26 00 89

Nevertheless, this could qualify as a kernel bugzilla
Comment 10 Alan Jenkins 2011-05-30 05:07:27 EDT
Created attachment 501748 [details]
EEE 701: Smolt profile

Harald: agreed.  I'm happy to be CC'd or addressed directly on kernel bugz or mail.

I forgot earlier - here's a Smolt profile for my system (EEE 701).
Comment 11 Prarit Bhargava 2011-06-07 15:56:38 EDT
The issue here appears to be the PCI IRQ table listing slot 33 as the ethernet slot.  This is a BIOS/FW issue, and not a software issue.

We *might* (there is absolutely NO guarantee that we will do this) consider creating a BIOS name blacklist of some sort -- similar to that of the SMBIOS blacklists in the kernel.

Alan Jenkins -- can you run "dmidecode" on your system and send it to us?  I'd like to take a look ...

P.
Comment 12 Alan Jenkins 2011-06-07 16:19:19 EDT
Created attachment 503568 [details]
dmidecode on affected EeePC 701

Sure, here you go.
Comment 13 Alan Jenkins 2011-06-07 16:22:01 EDT
Created attachment 503569 [details]
Kernel log, clean (without the softlockup or other errors) on same EeePC 701

Boot log (this is with the workaround, so no softlockup message)
Comment 14 Alan Jenkins 2011-06-07 16:22:52 EDT
Created attachment 503570 [details]
acpidump on affected EeePC 701
Comment 15 Alan Jenkins 2011-06-07 16:23:45 EDT
Created attachment 503571 [details]
/proc/interrupts on affected EeePC 701
Comment 16 Prarit Bhargava 2011-06-07 16:26:15 EDT
So after some further investigation about the name "p33p1" ... it turns out that this may be an ascii/u8 issue.

I'll propose a patch shortly.

P.
Comment 17 Alan Jenkins 2011-06-07 16:31:00 EDT
Created attachment 503572 [details]
dmidcode on EeePC 901, which also appears to be affected

And here's why I've been oddly specific.  I also have a EeePC 901, running Ubuntu.  I just downloaded the biosdevname source code from the Dell site, and a cursory test suggests it also locks up on this system.

You only asked for dmidecode, so here's the 901 dmidecode.  I hope you realise I'm assuming you've got mind-reading powers, since I've no idea where you got IRQ 33 from :-).  But seriously, if you want anything more, just ask.
Comment 18 Prarit Bhargava 2011-06-07 18:35:49 EDT
Created attachment 503582 [details]
Upstream patch for this issue
Comment 19 Alan Jenkins 2011-06-08 05:14:21 EDT
Tried the patch on 901, still hangs.

I'm not sure why you thought that might be causing the hang, but it doesn't fix it.  Biosdevname still reads the same VPD file in sysfs, and reading that VPD file still locks up the entire system, as described above.

Unfortunately saying the slot might be in ASCII doesn't explain the offset either :-(.  '0' is _hex_ 30, not _decimal_ 30.
Comment 20 Enrico 2011-07-07 10:44:03 EDT
*** Bug 715204 has been marked as a duplicate of this bug. ***
Comment 21 Enrico 2011-07-12 18:21:20 EDT
I have an Asus F3E laptop and I have this problem too. Disabling biosdevname saved me one minute at boot time.
If you require me to do some tests, I'll be happy to help.
Comment 22 Konstantin Svist 2011-08-16 21:57:31 EDT
Getting something very similar on EeePC 1000HD. Let me know if further info is necessary; otherwise please fix ASAP :)
Comment 23 Barbara 2011-08-19 18:21:57 EDT
I don't have an EeePC, but I'm experiencing a similar problem:
[   48.110832] BUG: soft lockup - CPU#1 stuck for 22s! [biosdevname:723]
I'm trying to attach dmesg and dmidecode
Comment 24 Barbara 2011-08-19 18:22:40 EDT
Created attachment 519108 [details]
dmesg
Comment 25 Barbara 2011-08-19 18:23:05 EDT
Created attachment 519109 [details]
dmidecode
Comment 26 Barbara 2011-08-23 16:33:28 EDT
Disabling the embedded Ethernet device (atl1 driver) seems to mitigate the problem.
Obviously this is not a solution.
Comment 27 Alan Jenkins 2011-08-23 17:24:47 EDT
Barbara: in the meantime, if you could use a better workaround, you should try what I did.

You can disable biosdevname for a single boot, e.g. by adding the kernel option "biosdevname=0" at the grub boot prompt.  What I discovered was that that seemed to fix the problem _permanently_.  (Hopefully this is still the case).


What happened was that without biosdevname, the device stays as eth0.  The old "persistent" device naming will kick in, and create an entry for the device in "/etc/udev/rules.d/70-persistent-net.rules".  The biosdevname rule defers to this persistent name, so on future boots, biosdevname doesn't get run at all for that device.

Magic :).  (I think it's great as a workaround.  It's just a bit worrying that people may try "biosdevname=0" as a debugging tool, have the problem disappear for no apparent reason, and then not know how to report the problem).
Comment 28 Chuck Ebbert 2011-08-30 23:13:07 EDT
*** Bug 731819 has been marked as a duplicate of this bug. ***
Comment 29 Chuck Ebbert 2011-08-30 23:13:54 EDT
*** Bug 733197 has been marked as a duplicate of this bug. ***
Comment 30 Chuck Ebbert 2011-08-30 23:14:10 EDT
*** Bug 729858 has been marked as a duplicate of this bug. ***
Comment 31 Chuck Ebbert 2011-08-30 23:14:30 EDT
*** Bug 708524 has been marked as a duplicate of this bug. ***
Comment 32 Narendra K 2011-09-13 12:22:53 EDT
Hi, could you please try the latest biosdevname version 0.3.10 which has a VPD related fix to see if that addresses this issue. Biosdevname 0.3.8  opens the sysfs vpd file and seeks till the end of the file to find out the number of bytes to read. This is fixed in 0.3.10 which determines the actual number of bytes implemented and reads only so many bytes.

Please delete 70-persistent-net.rules file before you reboot the system as that will prevent biosdevname from being run.
Comment 33 Alan Jenkins 2011-09-13 12:51:27 EDT
EeePC 901 (as affected above), not fedora, biosdevname from dell.com.

The hang is fixed.  Thanks!  The result looks slightly odd.

$ sudo ./biosdevname -i eth0
p4098p1

The old biosdevname, 0.3.8, hangs for X seconds - but after the hang, it identified my eth0 as "p33p1".  Which was interesting in itself (I have 33 PCI somethings?).  But it at least didn't look out place relative to wlan0, which is in both versions identified as p35p1.

PCI Slot      : 4096

4096 pci slots, haha... wait

BIOS device: p4096p1


That's right.  biosdevname -i eth0 says "p4098p1".  biosdevname -d says that eth0 is "p4096p1".  So I think there's still a little bug there.
Comment 34 Matt Domsch 2011-09-13 13:14:57 EDT
the "slot 33" problem is because fields in the PIRQ table are using ascii integer values "1" = 0x33, when other BIOS uses 0x01 in the same field.  Fixable I'd think.
Comment 35 Alan Jenkins 2011-09-13 13:31:12 EDT
That's what Prarit suggested.  I don't quite see it - isn't biosdevname telling me the PCI slot number is _decimal_ 33 / 35?  (For eth0 / wlan0 respectively)?

Anyway, my real question is over the value of 4096 / 4098 for eth0, which the new version of biosdevname shows.
Comment 36 Narendra K 2011-09-13 14:20:29 EDT
Could you please attach the 'biosdecode' output ?
Comment 37 Alan Jenkins 2011-09-13 17:16:05 EDT
Do you mean dmidecode?  If so, it's here (for my EeePC 901):
https://bugzilla.redhat.com/show_bug.cgi?id=707583#c17
Comment 38 Alan Jenkins 2011-09-13 17:18:59 EDT
Created attachment 523013 [details]
biosdecode for EeePC 901

Sorry, you _did_ mean 'biosdecode'.  Here you go.
Comment 39 Narendra K 2011-09-14 04:17:08 EDT
> Created attachment 523013 [details]
> biosdecode for EeePC 901
> 
> Sorry, you _did_ mean 'biosdecode'.  Here you go.

From the attached output, PIRQ table seems to suggest that the device with PCI address 04:00 is on slot 33. So i expect the name to be pci33p1. It is strange that the name is "p4096p1".

Slot Entry 11: ID 04:00, slot number 33

I guess running 'biosdevname -i eth0 --nopirq' does not suggest any name in this system. Could you please post 'biosdevname -d' output and 'lspci -tv' output ?
Comment 40 Alan Jenkins 2011-09-14 04:34:11 EDT
> It is strange that the name is "p4096p1"

It's strange that it is both "p4096p1" and "p4098p1".

# pwd
/home/alan/pkg/biosdevname-0.3.10/src


"p4098p1":

# ./biosdevname -i eth0
p4098p1

# ./biosdevname -i eth0 --nopirq
p4098p1


"p4096p1":

# ./biosdevname -d
BIOS device: p35p1
Kernel name: wlan0
Permanent MAC: 00:15:AF:E5:80:1D
Assigned MAC : 00:15:AF:E5:80:1D
Driver: rt2800pci
Driver version: 2.6.38-11-generic
Firmware version: 0.11
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 35
Index in slot: 1

BIOS device: p4096p1
Kernel name: eth0
Permanent MAC: 00:22:15:60:85:04
Assigned MAC : 00:22:15:60:85:04
Driver: ATL1E
Driver version: 1.0.0.7-NAPI
Firmware version: L1e
Bus Info: 0000:04:00.0
PCI name      : 0000:04:00.0
PCI Slot      : 4096
Index in slot: 1


And as requested,

# lspci -tv
-[0000:00]-+-00.0  Intel Corporation Mobile 945GME Express Memory Controller Hub
           +-02.0  Intel Corporation Mobile 945GME Express Integrated Graphics Controller
           +-02.1  Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller
           +-1b.0  Intel Corporation N10/ICH 7 Family High Definition Audio Controller
           +-1c.0-[05]--
           +-1c.1-[04]----00.0  Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet
           +-1c.2-[03]--
           +-1c.3-[01-02]----00.0  Ralink corp. RT2860
           +-1d.0  Intel Corporation N10/ICH 7 Family USB UHCI Controller #1
           +-1d.1  Intel Corporation N10/ICH 7 Family USB UHCI Controller #2
           +-1d.2  Intel Corporation N10/ICH 7 Family USB UHCI Controller #3
           +-1d.3  Intel Corporation N10/ICH 7 Family USB UHCI Controller #4
           +-1d.7  Intel Corporation N10/ICH 7 Family USB2 EHCI Controller
           +-1e.0-[06]--
           +-1f.0  Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge
           +-1f.2  Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller
           \-1f.3  Intel Corporation N10/ICH 7 Family SMBus Controller
Comment 41 Alan Jenkins 2011-09-14 05:08:17 EDT
This might be relevant: lspci tries to parse the VPD, but fails.  (For comparison, it doesn't find a VPD for any other device).

# lspci --version
lspci version 3.1.7

# lspci -vvv
...
04:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)
...
        Capabilities: [6c] Vital Product Data
                Unknown small resource type 0b, will not decode more.
Comment 42 Alan Jenkins 2011-09-14 05:50:18 EDT
Ok, I can tell you why this happens.  If you haven't just now figured it out by elimination.

gdb says "4096" is coming from the newly added pcie_get_slot().  Which does this...

slot = (pci_read_long(p->pci_dev, pos + PCI_EXP_SLTCAP) >> 19);

and so 4096 is probably supposed to be "-1" / INT_MAX / PHYSICAL_SLOT_UNKNOWN.

(gdb) p /x ((unsigned) 4096) << 19
$22 = 0x80000000
Comment 43 Alan Jenkins 2011-09-14 08:38:20 EDT
Created attachment 523141 [details]
Patch for odd & randomly changing slot numbers

Ah, the confusion between 4096 & 4098 doesn't seem to be biosdevname's fault.  It doesn't actually depend on what options are used; it's just that pci_read_long() is randomly returning a different value.

Here's my test patch, and the resulting behaviour of biosdevname for EeePC 901 and 701.
Comment 44 jordan hargrave 2011-09-16 16:33:04 EDT
Can you attach an output of lspci -vvvxxxx on your system?
Comment 45 Alan Jenkins 2011-09-16 16:37:01 EDT
Created attachment 523621 [details]
lspci -vvvxxxx on EeePC 901
Comment 46 Gregory Lee Bartholomew 2011-09-20 13:11:40 EDT
FYI, I'm getting this same issue with my EeePC 900, BIOS Revision 1006.
Comment 47 Gregory Lee Bartholomew 2011-09-20 13:12:28 EDT
Created attachment 524069 [details]
dmesg from EeePC 900
Comment 48 Gregory Lee Bartholomew 2011-09-20 13:13:07 EDT
Created attachment 524070 [details]
lspci -vvvxxxx from EeePC 900
Comment 49 Narendra K 2011-09-22 11:00:14 EDT
Hi, could you please test biosdevname 0.3.11 and let us know.
http://linux.dell.com/biosdevname/biosdevname-0.3.11/
Comment 50 Alan Jenkins 2011-09-22 15:56:29 EDT
I guess you mean me?  Since we already know 0.3.10 avoids the hang bug.

0.3.11 gives me eth0 as p33p1 (on EeePC 901), instead of p4096p1 / p4098p1.

Reviewing the changes, it's great to see you found out what was really causing that problem.

I have one comment on the other change between the two versions.  (OK, a rant).

As mentioned earlier, testing decimal 33 against '0'...'9' didn't help, since '0' is 0x30 = 48 decimal.  And 33 < 48.  You _could_ test against 30...39 if you wanted to - it's even a distinct range.

But you shouldn't.  The obvious hypothesis is that no-one at Asus tested this.   For all you know, the next system will use the numbers 1, 31, and 0x31, and your clever code would try to collapse everything to p1p1.  Remove that code and let the number 33 pass through unchanged.

If I haven't mentioned it already, the biosdevname feature is irrelevant for this specific system.  All that's required is that it not break anything.  It's a netbook; it has a wireless device and an ethernet device; you can't confuse the two.  It might just be possible to mod it with an additional wireless card - big deal, Marty the Modder has to remember that 33 is the original one.

I don't trust the information anyway, because a) we know it's dodgy; b) it says eth0 is occupying a numbered PCI slot.  That seems unlikely in any consumer PC, let alone a netbook.  http://images.bit-tech.net/content_images/2008/06/inside-the-eeepc-901-investigating-atom/pcb2.jpg - see top right, labelled "LAN COM"; somehow I doubt that's a user-replacable PCI slot.
Comment 51 Gregory Lee Bartholomew 2011-09-23 12:44:14 EDT
biosdevname 0.3.11 fixed the problem for me.
Comment 52 Gregory Lee Bartholomew 2011-09-23 12:45:30 EDT
Created attachment 524656 [details]
dmesg from EeePC 900 with biosdevname 0.3.11
Comment 53 Gregory Lee Bartholomew 2011-09-23 12:46:36 EDT
Created attachment 524657 [details]
lspci -vvvxxxx from EeePC 900 with biosdevname 0.3.11
Comment 54 Fedora Update System 2011-10-04 16:13:00 EDT
biosdevname-0.3.11-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/biosdevname-0.3.11-5.fc16
Comment 55 Fedora Update System 2011-10-05 13:15:43 EDT
Package biosdevname-0.3.11-5.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing biosdevname-0.3.11-5.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/biosdevname-0.3.11-5.fc16
then log in and leave karma (feedback).
Comment 56 Steve 2011-10-06 04:05:30 EDT
Is there a way to test it on Fedora 15?
Comment 57 Fedora Update System 2011-10-06 17:27:03 EDT
biosdevname-0.3.11-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/biosdevname-0.3.11-1.fc15
Comment 58 Steve 2011-10-07 02:55:46 EDT
biosdevname-0.3.11-1.fc15 is working on my ASUS EEEPC900. Thank you!
Comment 59 Enrico 2011-10-07 03:52:23 EDT
The latest version fixed the problem on my Asus F3E. Thank you very much!
Comment 60 Fedora Update System 2011-10-09 15:52:56 EDT
biosdevname-0.3.11-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 61 Fedora Update System 2011-10-11 04:25:23 EDT
biosdevname-0.3.11-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 62 Josh Boyer 2011-10-11 09:20:06 EDT
*** Bug 729554 has been marked as a duplicate of this bug. ***
Comment 63 Josh Boyer 2011-11-29 15:03:09 EST
*** Bug 747600 has been marked as a duplicate of this bug. ***

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