LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Multiple ip= boot arguments?
@ 2007-01-29 18:36 Kevin Nicoll
  2007-01-29 20:48 ` Jan Engelhardt
  0 siblings, 1 reply; 6+ messages in thread
From: Kevin Nicoll @ 2007-01-29 18:36 UTC (permalink / raw)
  To: linux-kernel

Hello,

I am using kernel 2.6.18, and have been trying without success to set
up multiple network interfaces using kernel boot arguments.  It makes
sense to be able to specify multiple interface configurations on the
command line, but it has occurred to me that I may not be correctly
understanding the purpose of the "ip=" parameter.  My question is if
it is intended to be able to use more than one "ip=" parameter in the
kernel command line, or if I'm supposed to use a startup script
instead.

I have been testing this using a variety of different boot command
lines, and it appears to me that the only network interface that ever
gets brought up by the kernel is the one defined in the last "ip="
parameter.  Here is some example output with debugging messages
enabled (lines beginning with "IP-Config(me):" are lines I added to
help with my understanding):

LINUX started...
 UART clock set to 50000000
 Linux version 2.6.18-pmc (nicollke@mozart) (gcc version 3.4.5) #46
PREEMPT Fri Jan 26 14:36:58 CST 2007
…
(snip)
…
 Kernel command line: console=ttyS0,57600
ip=192.168.183.77:::::eth1:none:100fs
ip=192.168.183.76::::pmcgw:eth0:none:an
 IP-Config(me): Parsing 192.168.183.77:::::eth1:none:100fs
 IP-Config: Parameter #0: `192.168.183.77'
 IP-Config: Parameter #5: `eth1'
 IP-Config: Parameter #6: `none'
 IP-Config: Parameter #7: `100fs'
 IP-Config(me): Parsing 192.168.183.76::::pmcgw:eth0:none:an
 IP-Config: Parameter #0: `192.168.183.76'
 IP-Config: Parameter #4: `pmcgw'
 IP-Config: Parameter #5: `eth0'
 IP-Config: Parameter #6: `none'
 IP-Config: Parameter #7: `an'
…
(snip)
…
IP-Config: Entered.
IP-Config(me): Trying to bring up eth0
IP-Config(me): Got inside!
MSPETH (init_cmdline) eth0: boot = console=ttyS0,57600
ip=192.168.183.77:::::eth1, option = 00
MSPETH (init_cmdline) eth0: boot = console=ttyS0,57600
ip=192.168.183.77:::::eth1, option = 00
MSPETH (init_phyaddr): hwunit = 0, phystr prom = "0:5"
MSPETH (queue_init) eth0:FD_base = a11a6000
arc 0x4: 000700e0
arc 0x8: 04000007
MSPETH eth0: Auto Negotiation... done.
MSPETH eth0: Waiting for carrier ... carrier detected.
MSPETH eth0: Autoneg, Link up, linkspeed 100Mbps, Full Duplex
IP-Config: eth0 UP (able=1, xid=4d9cf06a)
IP-Config(me): Trying to bring up eth1
IP-Config(me): Trying to bring up lo
IP-Config(me): Trying to bring up dummy0
IP-Config: Guessing netmask 255.255.255.0
arc 0xc: 01005e00
arc 0x10: 0001e307
IP-Config: Complete:
      device=eth0, addr=192.168.183.76, mask=255.255.255.0, gw=255.255.255.255,
     host=pmcgw, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 156k freed

The problem seems to be in the ic_open_devs() function in ipconfig.c,
which is the function responsible for actually starting up the network
interfaces.  I have copied function out below for your convenience:

static int __init ic_open_devs(void)
{
	struct ic_device *d, **last;
	struct net_device *dev;
	unsigned short oflags;

	last = &ic_first_dev;
	rtnl_lock();

	/* bring loopback device up first */
	if (dev_change_flags(&loopback_dev, loopback_dev.flags | IFF_UP) < 0)
		printk(KERN_ERR "IP-Config: Failed to open %s\n", loopback_dev.name);

	for (dev = dev_base; dev; dev = dev->next) {
		printk(KERN_WARNING "IP-Config(me): Trying to bring up %s\n", dev->name);
		if (dev == &loopback_dev)
			continue;
		if (user_dev_name[0] ? !strcmp(dev->name, user_dev_name) :
		    (!(dev->flags & IFF_LOOPBACK) &&
		     (dev->flags & (IFF_POINTOPOINT|IFF_BROADCAST)) &&
		     strncmp(dev->name, "dummy", 5))) {
			printk(KERN_WARNING "IP-Config(me): Got inside!\n");
			int able = 0;
			if (dev->mtu >= 364)
				able |= IC_BOOTP;
			else
				printk(KERN_WARNING "DHCP/BOOTP: Ignoring device %s, MTU %d too
small", dev->name, dev->mtu);
			if (!(dev->flags & IFF_NOARP))
				able |= IC_RARP;
			able &= ic_proto_enabled;
			if (ic_proto_enabled && !able)
				continue;
			oflags = dev->flags;
			if (dev_change_flags(dev, oflags | IFF_UP) < 0) {
				printk(KERN_ERR "IP-Config: Failed to open %s\n", dev->name);
				continue;
			}
			if (!(d = kmalloc(sizeof(struct ic_device), GFP_KERNEL))) {
				rtnl_unlock();
				return -1;
			}
			d->dev = dev;
			*last = d;
			last = &d->next;
			d->flags = oflags;
			d->able = able;
			if (able & IC_BOOTP)
				get_random_bytes(&d->xid, sizeof(u32));
			else
				d->xid = 0;
			ic_proto_have_if |= able;
			DBG(("IP-Config: %s UP (able=%d, xid=%08x)\n",
				dev->name, able, d->xid));
		}
	}
	rtnl_unlock();

	*last = NULL;

	if (!ic_first_dev) {
		if (user_dev_name[0])
			printk(KERN_ERR "IP-Config: Device `%s' not found.\n", user_dev_name);
		else
			printk(KERN_ERR "IP-Config: No network devices available.\n");
		return -1;
	}
	return 0;
}

Given the looping structure, I would like to assume that multiple
"ip=" parameters are intended to be supported.  However, for some
reason, eth1 fails the if condition inside the loop, resulting in it
not being initialized.  This happens for any number of "ip="
parameters that I define:  the first few defined "ip=" parameters do
not meet the condition and are not brought online, but the last "ip="
parameter meets the condition and is brought online.

Please CC comments and replies to me.  Any replies or feedback for
this issue is greatly appreciated.

Kevin

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple ip= boot arguments?
  2007-01-29 18:36 Multiple ip= boot arguments? Kevin Nicoll
@ 2007-01-29 20:48 ` Jan Engelhardt
  2007-01-30  0:00   ` H. Peter Anvin
       [not found]   ` <45BE73C8.5010005@celunite.com>
  0 siblings, 2 replies; 6+ messages in thread
From: Jan Engelhardt @ 2007-01-29 20:48 UTC (permalink / raw)
  To: Kevin Nicoll; +Cc: linux-kernel


On Jan 29 2007 12:36, Kevin Nicoll wrote:
>
> My question is if it is intended to be able to use more than one "ip="
> parameter in the kernel command line,

Possibly not ...

> or if I'm supposed to use a startup script instead.

This is the preffered way nowadays. One day, hopefully,
CONFIG_IP_PNP can go away.


	-`J'
-- 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple ip= boot arguments?
  2007-01-29 20:48 ` Jan Engelhardt
@ 2007-01-30  0:00   ` H. Peter Anvin
  2007-01-30  0:24     ` Chris Friesen
       [not found]   ` <45BE73C8.5010005@celunite.com>
  1 sibling, 1 reply; 6+ messages in thread
From: H. Peter Anvin @ 2007-01-30  0:00 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Kevin Nicoll, linux-kernel

Jan Engelhardt wrote:
> 
>> or if I'm supposed to use a startup script instead.
> 
> This is the preffered way nowadays. One day, hopefully,
> CONFIG_IP_PNP can go away.
> 

It could be done reasonably easy, you know... :-/

	-hpa

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple ip= boot arguments?
  2007-01-30  0:00   ` H. Peter Anvin
@ 2007-01-30  0:24     ` Chris Friesen
  2007-01-30  0:27       ` H. Peter Anvin
  0 siblings, 1 reply; 6+ messages in thread
From: Chris Friesen @ 2007-01-30  0:24 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Jan Engelhardt, Kevin Nicoll, linux-kernel

H. Peter Anvin wrote:
> Jan Engelhardt wrote:
>>
>>> or if I'm supposed to use a startup script instead.
>>
>> This is the preffered way nowadays. One day, hopefully,
>> CONFIG_IP_PNP can go away.
>>
> It could be done reasonably easy, you know... :-/

If CONFIG_IP_PNP is going to go away, what is the proposed mechanism for 
netboot devices to determine the proper source address to use when 
searching for a rootfs to use?


Chris

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple ip= boot arguments?
  2007-01-30  0:24     ` Chris Friesen
@ 2007-01-30  0:27       ` H. Peter Anvin
  0 siblings, 0 replies; 6+ messages in thread
From: H. Peter Anvin @ 2007-01-30  0:27 UTC (permalink / raw)
  To: Chris Friesen; +Cc: Jan Engelhardt, Kevin Nicoll, linux-kernel

Chris Friesen wrote:
> H. Peter Anvin wrote:
>> Jan Engelhardt wrote:
>>>
>>>> or if I'm supposed to use a startup script instead.
>>>
>>> This is the preffered way nowadays. One day, hopefully,
>>> CONFIG_IP_PNP can go away.
>>>
>> It could be done reasonably easy, you know... :-/
> 
> If CONFIG_IP_PNP is going to go away, what is the proposed mechanism for 
> netboot devices to determine the proper source address to use when 
> searching for a rootfs to use?

My quip was mostly that it could replaced with the existing klibc 
implementation, which runs in userspace.

The other option, of course, is the distribution-specific initramfs route.

	-hpa

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Multiple ip= boot arguments?
       [not found]   ` <45BE73C8.5010005@celunite.com>
@ 2007-01-30  9:07     ` Jan Engelhardt
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Engelhardt @ 2007-01-30  9:07 UTC (permalink / raw)
  To: pradeep; +Cc: Linux Kernel Mailing List


On Jan 30 2007 03:53, pradeep wrote:
> Jan Engelhardt wrote:
>> On Jan 29 2007 12:36, Kevin Nicoll wrote:
>> 
>> > or if I'm supposed to use a startup script instead.
>> 
>> This is the preffered way nowadays. One day, hopefully,
>> CONFIG_IP_PNP can go away.
>> 
> CONFIG_IP_PNP is required while mounting rootfs on NFS.

It is definitely not.


	-`J'
-- 

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-01-30  9:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-29 18:36 Multiple ip= boot arguments? Kevin Nicoll
2007-01-29 20:48 ` Jan Engelhardt
2007-01-30  0:00   ` H. Peter Anvin
2007-01-30  0:24     ` Chris Friesen
2007-01-30  0:27       ` H. Peter Anvin
     [not found]   ` <45BE73C8.5010005@celunite.com>
2007-01-30  9:07     ` Jan Engelhardt

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).