Bug 707583

adding biosdevname=0 to kernel parameters resolved the issue as well as uninstalling biosdevname package.

can you run it by hand with debug enabled?

# cd /sys/class/net
# for i in *; do time biosdevname  -d -i $i;done

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

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.

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

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

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

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.

(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

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

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.

Created attachment 503568 [details]
dmidecode on affected EeePC 701

Sure, here you go.

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)

Created attachment 503570 [details]
acpidump on affected EeePC 701

Created attachment 503571 [details]
/proc/interrupts on affected EeePC 701

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.

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.

Created attachment 503582 [details]
Upstream patch for this issue

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.

*** Bug 715204 has been marked as a duplicate of this bug. ***

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.

Getting something very similar on EeePC 1000HD. Let me know if further info is necessary; otherwise please fix ASAP :)

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

Created attachment 519108 [details]
dmesg

Created attachment 519109 [details]
dmidecode

Disabling the embedded Ethernet device (atl1 driver) seems to mitigate the problem.
Obviously this is not a solution.

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

*** Bug 731819 has been marked as a duplicate of this bug. ***

*** Bug 733197 has been marked as a duplicate of this bug. ***

*** Bug 729858 has been marked as a duplicate of this bug. ***

*** Bug 708524 has been marked as a duplicate of this bug. ***

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.

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.

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.

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.

Could you please attach the 'biosdecode' output ?

Do you mean dmidecode?  If so, it's here (for my EeePC 901):
https://bugzilla.redhat.com/show_bug.cgi?id=707583#c17

Created attachment 523013 [details]
biosdecode for EeePC 901

Sorry, you _did_ mean 'biosdecode'.  Here you go.

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

> 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

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.

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

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.

Can you attach an output of lspci -vvvxxxx on your system?

Created attachment 523621 [details]
lspci -vvvxxxx on EeePC 901

FYI, I'm getting this same issue with my EeePC 900, BIOS Revision 1006.

Created attachment 524069 [details]
dmesg from EeePC 900

Created attachment 524070 [details]
lspci -vvvxxxx from EeePC 900

Hi, could you please test biosdevname 0.3.11 and let us know.
http://linux.dell.com/biosdevname/biosdevname-0.3.11/

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.

biosdevname 0.3.11 fixed the problem for me.

Created attachment 524656 [details]
dmesg from EeePC 900 with biosdevname 0.3.11

Created attachment 524657 [details]
lspci -vvvxxxx from EeePC 900 with biosdevname 0.3.11

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

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

Is there a way to test it on Fedora 15?

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

biosdevname-0.3.11-1.fc15 is working on my ASUS EEEPC900. Thank you!

The latest version fixed the problem on my Asus F3E. Thank you very much!

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.

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.

*** Bug 729554 has been marked as a duplicate of this bug. ***

*** Bug 747600 has been marked as a duplicate of this bug. ***