https://bugzilla.novell.com/show_bug.cgi?id=849751 https://bugzilla.novell.com/show_bug.cgi?id=849751#c2 --- Comment #2 from andreas bittner 2013-11-11 18:32:21 UTC --- okay I am undecided yet, but I just took this system and installed (still pending) a win7 x64 to it, and on initial first boot this system also only sees the onboard realtek nic, as currently one of the additional dual-nic realtek pcie cards is plugged into one of the pcie 16x slots. so either this is some serious design flaw or firmware bug on asus side or something else is wrong with me here :( also, the colorful retail box of this mainboard as their website I think says, that for PCIe 3.0 functionality one of those new FM2+ APU (GPU/CPU) needs to be used, of course this FM2+ processor will only be released to retail public market in january or february next year. but then again I dont suppose that this mainboard or design does deactivate those PCIe 16x slots completely so that only that one tiny PCIe 1x slot would remain working, I suppose running current CPU/APU processors as I am doing would then fallback the PCIe standard of all or most ports to the previous PCIe 2.x or whatever the exact terminology and revisions were. I could probably plug in some additional GFX card into those PCIe 16x slots and see if those turn up in lspci or in this Win7x64 test run, I might try that just to make sure what the heck is wrong here I am also running the latest bios that was up one or two days ago at asus site, and now I am really wondering what on earth is wrong here. Any ideas on this? Thank you. -- 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=849751 https://bugzilla.novell.com/show_bug.cgi?id=849751#c4 --- Comment #4 from andreas bittner 2013-11-11 23:43:12 UTC --- I have also verified this with some 3.2.x and 3.10.x kernels (debian). none of these systems sees the PCIe 1x Realtek network card in the long PCIe 16x slots. Only in the tiny PCIe 1x slot. :( -- 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=849751 https://bugzilla.novell.com/show_bug.cgi?id=849751#c6 --- Comment #6 from andreas bittner 2013-11-15 14:44:14 UTC --- meanwhile in asusland: customer please trial and error all the PCIe slots with your network card, also are you using a PCIe GFX card and all. I gave them all the information that I had available and pointed them to this "bugreport". This is the way how they treat their customers and respect the information that is already given. Anyways, this is hopeless, so much for industry standards and compatibility testing and plug-fests and all that, or blame the firmware developers or whomever. By now I have gotton a slightly differently designed dual-gigabitethernet PCIe card, and all works fine with this different bridge chip they have designed onto their PCB of the NIC. lspci: 01:00.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 02:01.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 02:02.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 02:03.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 07:00.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 08:01.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 08:02.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 08:03.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) 09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 0b:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 0c:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c example: 01:00.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Subsystem: Realtek Semiconductor Co., Ltd. Device 0123 Kernel driver in use: r8169 Kernel modules: r8169 01:00.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 02:01.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 02:02.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 02:03.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 03:00.0 0200: 10ec:8168 (rev 06) Subsystem: 10ec:0123 Kernel driver in use: r8169 Kernel modules: r8169 05:00.0 0200: 10ec:8168 (rev 06) Subsystem: 10ec:0123 Kernel driver in use: r8169 Kernel modules: r8169 07:00.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 08:01.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 08:02.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 08:03.0 0604: 12d8:2404 (rev 05) Kernel driver in use: pcieport Kernel modules: shpchp 09:00.0 0200: 10ec:8168 (rev 06) Subsystem: 10ec:0123 Kernel driver in use: r8169 Kernel modules: r8169 0b:00.0 0200: 10ec:8168 (rev 06) Subsystem: 10ec:0123 Kernel driver in use: r8169 Kernel modules: r8169 0c:00.0 0200: 10ec:8168 (rev 0c) Subsystem: 1043:8554 Kernel driver in use: r8169 Kernel modules: r8169 Sample -vvv 01:00.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- TAbort- Capabilities: [230 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Kernel driver in use: pcieport Kernel modules: shpchp So now both dual-port gigabitethernet PCIe cards and the onboard gigabitethernet port work fine, giving me 5 ethernet ports. And these cards do work in any of these PCIe slots, no matter if 1x or 16x. Yay. :( Not even PCIe is compatible these days, I wonder what a customer or user can actually take for granted these days? :( -- 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=849751 https://bugzilla.novell.com/show_bug.cgi?id=849751#c8 --- Comment #8 from andreas bittner 2013-11-19 21:14:43 UTC --- Hello there bugticket, meanwhile I needed to downgrade this machine to OpenSuSE 12.3/x64 otherwise it wouldnt behave well (another bugreport), but I wanted to report back that this bugreport here isnt the end of the story. I also checked with the 13.1/RC2/x64 usb-key just to make sure that my text now also is valid for this bug: even these two different dual-ethernet PCIe cards with this different PCIe switch/bridge from Pericom Semiconductor now have a problem of actually getting hardly any bytes at all through the the card/port. Situation: Booting up both 12.3/x64 (latest patches, but also rescue from usb key, no-patches) and 13.1/rc2/x64 rescue from usb key are not really able to use these Realtek ports of these two dual-port PCIe cards plugged-in. I see arp packets all right, and ip neigh displays output, but there is never an ICMP ping going through or being answered from the other side. In dmesg and /var/log/messages I see the link of these ports suddenly going up and down on its own, although they are all the time connected to gigabitethernet switches, and then the kernel outputs a block of messages, about NETDEV watchdog... R8169 ethX or enpXsY transmit qeue timed out..... :(( Eventually I found some of these kind of reports on the web, and some redhat related and others were hinting, that they only had these troubles during a cold-boot of their machine (crazy) and others reported that ACPI=off as kernel boot parameter would make the ethernet (realtek) card work again. And I just tried, also for rescue bootup, ACPI=off does work magic. The whole system gets a bit more sluggish and stalling (gfx output), but the ethernet card is now happily answering and doing pings and actually transferring payload data, hooooray :( Sigh. Does this part of the bug now qualify for a different new bug, about Realtek gigabitethernet drivers in current (13.1 is seemingly also effected the same way, can later try with goldmaster iso image too). Do I need to report it to OpenSuSE or some kernel.org places or what now? I think this machine can live with 12.3 and ACPI=off for now, but I wonder when the next incident relating to this will occur. Maybe related and references: Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1023654 Linux Kernel mailing list from Jan/Feb 2013: http://linux-kernel.2935.n7.nabble.com/3-8-rc-regression-NETDEV-WATCHDOG-eth... http://marc.info/?t=135737660100003&r=1&w=4 Any information if this was ever fixed if this is even related to my latest bug in here? Thanks for helping. -- 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.

http://bugzilla.novell.com/show_bug.cgi?id=849751 Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED CC| |jslaby@suse.com Resolution|--- |NORESPONSE --- Comment #10 from Jiri Slaby --- Closed due to lack of response. -- You are receiving this mail because: You are on the CC list for the bug.