From: Anton Blanchard <anton@samba.org>
To: netdev@oss.sgi.com
Cc: cramerj@intel.com, john.ronciak@intel.com,
ganesh.venkatesan@intel.com, jonmason@us.ibm.com,
jkenisto@us.ibm.com
Subject: Network device driver probe issues
Date: Thu, 15 Jul 2004 23:52:44 +1000 [thread overview]
Message-ID: <20040715135244.GD27715@krispykreme> (raw)
Hi,
With the advent of hotplug and udev we see network device driver opens
called as soon as possible, ie after register_netdev. In a lot of cases
drivers currently call register_netdev too early, before they are ready
to handle an open. I think the e1000 had this problem (which has since
been fixed), and the s2io appears to have this same issue.
Once the register_netdev call is delayed until late in probe (it really
should be the last thing the probe call does) we have an issue with
device printks. One of the reasons register_netdev is often early in the
probe routine of network drivers is that it provides a device name to
append to printks.
The e1000 gets around this by replicating register_netdev:
rtnl_lock();
/* we need to set the name early since the DPRINTK macro needs it set */
if (dev_alloc_name(netdev, netdev->name) < 0)
goto err_free_unlock;
...
/* since we are holding the rtnl lock already, call the no-lock version */
if((err = register_netdevice(netdev)))
goto err_register;
cards_found++;
rtnl_unlock();
The problem I have with this method has to do with how failures appear
to the user. If you have two network cards and the first one fails
during probe you will see:
eth0: Intel(R) PRO/1000 Network Connection
eth0: The EEPROM Checksum Is Not Valid
eth0: Intel(R) PRO/1000 Network Connection
This makes debugging the issue difficult. Where is the card that failed?
We have machines with 100s of interfaces and there it becomes a real
pain.
We should instead use something stable to attach to printks during
probe. pci_name() is the obvious choice, perhaps using dev_printk().
The failure then becomes:
0000:01:01.0 Intel(R) PRO/1000 Network Connection
0000:01:01.0 The EEPROM Checksum Is Not Valid
0000:02:01.0 Intel(R) PRO/1000 Network Connection
Also it would be useful if somewhere during probe the network driver
associated the network name with the pci id, eg:
0000:02:01.0 Intel(R) PRO/1000 Network Connection (eth0)
I know we can get at it via other means but it would be nice to be able
to look through the dmesg and work out what names were given to the
cards.
Anton
next reply other threads:[~2004-07-15 13:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-15 13:52 Anton Blanchard [this message]
2004-07-15 23:34 ` Network device driver probe issues Jeff Garzik
2004-07-16 1:04 ` Jim Keniston
2004-07-16 4:49 ` David Dillow
2004-07-16 18:26 ` Jim Keniston
-- strict thread matches above, loose matches on Subject: below --
2004-07-16 19:15 Venkatesan, Ganesh
2004-07-16 19:52 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040715135244.GD27715@krispykreme \
--to=anton@samba.org \
--cc=cramerj@intel.com \
--cc=ganesh.venkatesan@intel.com \
--cc=jkenisto@us.ibm.com \
--cc=john.ronciak@intel.com \
--cc=jonmason@us.ibm.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).