https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c1 --- Comment #1 from Stephan Lauffer 2011-03-11 13:19:13 UTC --- To be more detailed with my nic: Intel PWLA8391GTBLK PRO 1000GT. My board is a older one... with a Intel 440BX chipset. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c3 --- Comment #3 from Stephan Lauffer 2011-03-11 18:42:29 UTC --- ..same problems with booting "failsafe". Then I'd a look at http://download.opensuse.org/repositories/Kernel:/openSUSE-11.4/openSUSE_Fac... and tested 2.6.37.3 builds (default, vanilla, pae). All failed here. :-/ Strange... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c5 Stephan Lauffer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|lauffer@ph-freiburg.de | --- Comment #5 from Stephan Lauffer 2011-03-14 10:05:21 UTC --- Created an attachment (id=419096) --> (http://bugzilla.novell.com/attachment.cgi?id=419096) complete output of lspci -vvvxxnn -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c7 Stephan Lauffer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|lauffer@ph-freiburg.de | --- Comment #7 from Stephan Lauffer 2011-03-14 16:27:41 UTC --- There is no realtek NIC in this machine. Months ago, maybe a year there was such a 8139 in. How I can report this different PCI infos? As I read in the manpache lspci can... <<snip>> -H1 Use direct hardware access via Intel configuration mechanism 1. (This is a shorthand for -A intel-conf1.) <<snap>> So if I do a query with -H1 I get the real, truly data, the one about the plugged in Intel card. To get a network access with this card I loaded the e1000 by hand. Right now I put it into the initrd and set up the eth0 interface by hand (in some init script). No 8139 module is loaded but my e1000. In my words /sys/bus... has "garbage data": <<snip>> giant4:~ # grep -H . /sys/bus/pci/devices/0000\:00\:0a.0/* /sys/bus/pci/devices/0000:00:0a.0/broken_parity_status:0 /sys/bus/pci/devices/0000:00:0a.0/class:0x020000 Binary file /sys/bus/pci/devices/0000:00:0a.0/config matches /sys/bus/pci/devices/0000:00:0a.0/device:0x8139 /sys/bus/pci/devices/0000:00:0a.0/enable:1 /sys/bus/pci/devices/0000:00:0a.0/irq:12 /sys/bus/pci/devices/0000:00:0a.0/local_cpus:ffffffff /sys/bus/pci/devices/0000:00:0a.0/modalias:pci:v000010ECd00008139sv000010ECsd00008139bc02sc00i00 /sys/bus/pci/devices/0000:00:0a.0/resource:0x000000000000d000 0x000000000000d0ff 0x0000000000000101 /sys/bus/pci/devices/0000:00:0a.0/resource:0x00000000e3000000 0x00000000e30000ff 0x0000000000000200 /sys/bus/pci/devices/0000:00:0a.0/resource:0x0000000000000000 0x0000000000000000 0x0000000000000000 /sys/bus/pci/devices/0000:00:0a.0/resource:0x0000000000000000 0x0000000000000000 0x0000000000000000 /sys/bus/pci/devices/0000:00:0a.0/resource:0x0000000000000000 0x0000000000000000 0x0000000000000000 /sys/bus/pci/devices/0000:00:0a.0/resource:0x0000000000000000 0x0000000000000000 0x0000000000000000 /sys/bus/pci/devices/0000:00:0a.0/resource:0x0000000040000000 0x000000004000ffff 0x0000000000007200 /sys/bus/pci/devices/0000:00:0a.0/subsystem_device:0x8139 /sys/bus/pci/devices/0000:00:0a.0/subsystem_vendor:0x10ec /sys/bus/pci/devices/0000:00:0a.0/vendor:0x10ec <<snap>> See also this symlink: lrwxrwxrwx 1 root root 32 Mar 12 2008 /sys/devices/pci0000:00/0000:00:0a.0/driver -> ../../../bus/pci/drivers/8139too (there is no such nic in this machine, I could take a photo) Meanwhile I downloaded the 2.6.34.7 kernel source package from opensuse-11.3 and right now I wait until this kernel has compiled. I am completely confused about this behavoir. It is mysti to me. Is there something like a cache in the depth of "PCI" (udev or kernel) who could cause this problem? Like I said, in the past there was a 8139 plugged in (lot of reboots... shutdowns before)... Thanks for help by the way! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c9 --- Comment #9 from Stephan Lauffer 2011-03-14 16:52:24 UTC --- opensuse-11.4 with linux 2.6.34.7-0.7-desktop from opensuse-11.3 now has the same problem(!): giant4:~ # uname -a Linux giant4 2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 i686 i686 i386 GNU/Linux giant4:~ # lspci -n | grep 0a 00:0a.0 0200: 10ec:8139 (rev 10) This makes me wondering. So [x] old opensuse-11.3 installation was right [x] booting rescue system from opensuse-11.3 DVD was right [ ] opensuse-11.4 with differen kernels (the one from 11.3 and new factory builds are right. So this does not look like a kernel issue? So maybe pciutils-ids or pciutils is "broken"? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c11 --- Comment #11 from Jiri Slaby 2011-03-14 20:58:44 UTC --- (In reply to comment #10)

Anyway, is the problem that this driver is not properly controlling your network connection?

What I still don't understand is how can e1000 bind to anything in the system (see comment 0 for dmesg and comment 5 for the lspci output). Are you _sure_ that you didn't run the lspci and dmesg on 2 different systems? IOW after you modprobe e1000, could you attach output of: ls -1d /sys/bus/pci/drivers/*/*\:* and also explicitly of: ls -l /sys/bus/pci/drivers/e1000/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c13 --- Comment #13 from Stephan Lauffer 2011-03-14 21:38:35 UTC --- For comment #11, no, this informations are from one host, for #12, no, only one NIC is listed with lspci (just depending on -H1 if intel/realtek is shown). But oh well, looks like my mainboard gonna dies... what happened the last hours/minutes: After booting into 11.4 rescue system and again opening the pc tower, checking every IC, the board, added pci card (the vga adapter, the 3ware and the intel nic) was: It is a via based board, no 440BX, so other pci informations were wrong, too. lspci booting from DVD did _not_ show 440BX hw informations (good) and the intel nic was shown, too (very good). I rembered that I added some more, not used kernel modules into the initrd to become a desaster recovery image from this system booting on other hardware, too. So my next step then was: Removing everything else than 3w-xxxx from /etc/sysconfig/kernel INITRD_MODULES. Plus I removed the intel nic from the system. After a boot from HDD with this new initrd showed intel chipset pci ids, too. The next and last idea was: Loading bios setup defaults... I knew that I disabled some parts like parport, snd... and I added the snd-via82xx to the initrd (because I knew this module was right). So this was the last try. After loading the bios defaults the system did no longer work. I got no vga signal, the system does no longer boot. Jiri, if I may get this system working I will add the complete lspci requested from your comment #12. Now I guess my system (board) was going "mad" and this caused the trouble. But I never thougth that a diying system would end in wrong pci ids. I can not say if something loaded a new firmware for any of the devices. If I can bring the system back I will let you know. Bad end right of the story right now. :-/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=678808 https://bugzilla.novell.com/show_bug.cgi?id=678808#c15 Stephan Lauffer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #15 from Stephan Lauffer 2011-03-15 18:04:20 UTC --- First impression: New "old PC" with the same 3ware+HDD = old problem! (but now: solved) I found the reason, a hint is in #7, see the timestamp of /sys/devices/pci0000:00/0000:00:0a.0/driver from march 2008! Since this is an old machine I upgraded this host over and over. I now had an /sys in the real filesystem. I guess (maybe) in opensuse-11.3 the data there got overwritten by sysfs and now in 11.4 old data became in "foreground" of the sysfs. At this moment I cecked another old host here but this one did not have old data in /sys. Maybe somehow an upgrade failed? I guess you are not interested in my old /sys (I put it into a tar after booting from dvd). I don't have an idea when/how something failed here to leave a /sys/* in the filesystem. Maybe I created a sys during a data restore in 2008? This sounds most reasonable to me. Sorry, I don't know and sorry for alarming you. I just reopened this bug so that you can verify if there is some usefull information about my problem. But I guess not... nearly nobody would have a sys with lot of data in his fs. (: -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.