Bug 53096 - dhcpcd stalls boot when no cable present.
Summary: dhcpcd stalls boot when no cable present.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-09-03 14:58 UTC by David Woodhouse
Modified: 2014-03-17 02:23 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-17 03:58:26 UTC
Embargoed:


Attachments (Terms of Use)

Description David Woodhouse 2001-09-03 14:58:07 UTC
Since updating to Roswell2, booting the machine with no cable connected to
the Ethernet interface prevents it from booting. dhcpcd seems to have an
insanely long timeout. 

Roswell1 would notice that there was no link and behave correctly.

I'm told that this was changed because some network drivers were broken and
were not reporting a link when in fact there was one. Wouldn't it be
possible  to use ethtool or mii-tool on interfaces which support it to
determine whether there's a link or not?

Comment 1 Bill Nottingham 2001-09-04 00:29:30 UTC
Not really, as it isn't really reliable enough (if you use the version of
mii-tool that uses the wrong ioctl, you can't trust it; if you use the version
of mii-tool that uses the *right* ioctl, it doesn't always work right.)

Comment 2 David Woodhouse 2001-09-04 05:24:28 UTC
The right ioctl just got fixed so the kernel actually bothers to copy the
results back to userspace, which it wasn't doing before. #53050 should be
closed, but I think it's waiting for an 'official' build of the fixed kernel
package.

With that fixed, are there any drivers that support the MII ioctls but return
crap? If so, they should probably just have their support for those ioctls removed. 

Otherwise, is it at least possible to lower the timeout on dhcpcd to a more
useful value? I'm not sure what it is at the moment - but it far exceeds the
level of my patience. After leaving the laptop for a few minutes, I hit SysRq-K,
logged in and removed eth0 from modules.conf, and rebooted it.


Comment 3 Bill Nottingham 2004-10-17 03:58:26 UTC
This is fixed, has been for a while.


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