Description of problem: After upgrading from RHEL5.1 to RHEL5.2-Client-20080313.0 the system has a 90 second pause while booting. This happens when the service network is starting. 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02) Version-Release number of selected component (if applicable): 2.6.18-85.el5 How reproducible: Always Actual results: While booting the system appears to hang. Waiting for 1.5 min the system will then continue. I then see a bunch of new messages about netplug.d Mar 17 09:03:26 barron kernel: eth0: Tigon3 [partno(BCM95754) rev b002 PHY(5787)] (PCI Express) 10/100/1000Base-T Ethernet 00:13:72:32:7e:ba Mar 17 09:03:26 barron kernel: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1] Mar 17 09:03:26 barron kernel: eth0: dma_rwctrl[76180000] dma_mask[64-bit] Mar 17 09:03:26 barron kernel: ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 177 Mar 17 09:03:26 barron kernel: intel_rng: Firmware space is locked read-only. <4>intel_rng: If you can't or Mar 17 09:03:26 barron kernel: don't want to <4>intel_rng: disable this in firmware setup, and <4>intel_rng: if Mar 17 09:03:26 barron kernel: you are certain that your <4>intel_rng: system has a functional Mar 17 09:03:26 barron kernel: RNG, try<4>intel_rng: using the 'no_fwh_detect' option. Mar 17 09:03:26 barron pcscd: hotplug_libusb.c:402:HPEstablishUSBNotifications() Driver ifd-egate.bundle does not support IFD_GENERATE_HOTPLUG. Using active polling instead. Expected results: System should boot without long delays. Additional info: 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02) Subsystem: Dell Unknown device 01de Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 74 Region 0: Memory at ecef0000 (64-bit, non-prefetchable) [size=64K] Expansion ROM at <ignored> [disabled] Capabilities: [48] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [50] Vital Product Data Capabilities: [58] Vendor Specific Information Capabilities: [e8] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+ Address: 00000000fee01000 Data: 404a Capabilities: [d0] Express Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <4us, L1 unlimited Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0 Link: Latency L0s <4us, L1 <64us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number ba-7e-32-fe-ff-72-13-00 Capabilities: [16c] Power Budgeting
Are you pretty sure this card is causing the problem? Is this a system in rhts or your laptop or something? The tg3 driver hasn't been touched since 2.6.18-62.el5, so this would be surprising if it was a tg3 problem.
Andy, Just going by the bootup screen No I am not 100% positive but as the system boots. I see the following: Checking for Hardware Changes [OK] Bringing up looback interface [OK] Bringing up eth0 interface <-Pause for long time [OK]
Andy, Also this is my desktop system. Jeff
Jeff what model workstation is it? If it's an HP I can probably get my hands on it.
It is a Dell Precision 390
based on comment #2, seems pretty likely the tg3 card is the problem. :) Does it do this if you stop and start the network as well? If so could you try and capture the traffic wireshark so I can see what is happening?
Andy, It does have the same issue when doing a service network restart. I need to get some additional work down so I am not sure when I will be able to try and get a packet capture
No problem, Jeff. I'll see if I can track down a system with a 5754 in the meantime.
Jeff, is this still an issue?
Andy, I will have to double check. It is my desktop system that I was seeing the issue on. I don't reboot that often So I am not 100% sure at the moment. I will get back to you in a day or so. Thanks, Jeff
Andy, I was able update my ststem to the latest R5.2-Z stream kernel 2.6.18-92.1.13.el5. I no longer see the issue. During the init scripts it seems to be "normal" again. I don't see any long pauses. I think we can close this as NOTABUG or WORKSFORME. Thanks, Jeff
Thanks, Jeff!