Questions about ARP

Questions about ARP

[Steven Scholz]

Hi there,

Microsoft uses "Automatic Private IP Addressing" to grab an IP address
if a DHCP request fails.

In the section "Resolving IP Conflicts" in
http://www.winnetmag.com/Articles/Index.cfm?ArticleID=7464
it says

How does the client know the IP address it's using isn't in use by
another machine? It uses a gratuitous Address Resolution Protocol
(ARP) to resolve potential conflicts. Let’s say the first client that
boots up wants to assign itself an IP address of 169.254.10.20. It
sends out a gratuitous ARP, but no one answers, so it keeps the
address ... Next, a third client boots up and picks 169.254.10.20, the
same address the first client chose. The first client tells the third
client that it's already using that IP address, so the third client
tries a different IP address and keeps it if there's no conflict.

I can see this behaviour if I connect an embedded DOS TCP/IP device to
a Windows XP computer (using a cross-linked twisted pair) and force
the IP of the DOS device to be the same as the one that the Windows XP
computer is going to claim. Fair enough.

But when I connect my MPC8xx board with Linux it seems that Linux is
not responding to the ARP requests done by the Windows machine.
Result: Both machine end up with the same IP address.

Did I miss something?
I did not find an kernel option saying something about ARP...

Any ideas?

Could someone maybe try this as well? Please?

Thanks a million,

Steven


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Questions about ARP

[Dan Malek]

Steven Scholz wrote:

> But when I connect my MPC8xx board with Linux it seems that Linux is
> not responding to the ARP requests done by the Windows machine.
> Result: Both machine end up with the same IP address.

Fortunately, Linux isn't Windows......you are going to find lots of
Windows "standard" protocols that aren't documented nor supported by
anyone else.

> Did I miss something?

Well, Microsoft did.....there is RFC2131 that describes how you are
supposed to use an ARP to respond to a duplicate IPv4 used on the
network.  It is commonly used to ensure you don't have systems
manually configured or not honoring leases when DHCP is handing out
dynamic IP addresses.  Everyone else seems to implement this properly.

> I did not find an kernel option saying something about ARP...

That's because it implements the standard protocols by default.

> Any ideas?

Run DHCP or properly manually configure your Linux system.  I don't
know how old your Linux kernel is for the 8xx, but this support for
RFC2131 has been in Linux for a very long time.


Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Questions about ARP

[Steven Scholz]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

Dan Malek wrote:

 > Steven Scholz wrote:
 >
 >> But when I connect my MPC8xx board with Linux it seems that Linux is
 >> not responding to the ARP requests done by the Windows machine.
 >> Result: Both machine end up with the same IP address.
 >
 >
 > Fortunately, Linux isn't Windows......you are going to find lots of
 > Windows "standard" protocols that aren't documented nor supported by
 > anyone else.
 >
 >> Did I miss something?
 >
 >
 > Well, Microsoft did.....there is RFC2131 that describes how you are
 > supposed to use an ARP to respond to a duplicate IPv4 used on the
 > network.  It is commonly used to ensure you don't have systems
 > manually configured or not honoring leases when DHCP is handing out
 > dynamic IP addresses.  Everyone else seems to implement this properly.

Finaly I found the point you're talking about.
Linux is answering the ARP packets with Source Address 0.0.0.0 (see net/ipv4/arp.c):

         /* Special case: IPv4 duplicate address detection packet (RFC2131) */
         if (sip == 0) {
                 if (arp->ar_op == htons(ARPOP_REQUEST) &&
                     inet_addr_type(tip) == RTN_LOCAL)
                         arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr);
                 goto out;
         }

Windows is checking for duplicate addresses using ARP packets with source _and_
destination address set to the address in question. So of course Linux won't answer it!

But I can't find a single word in the RFC2131 (http://www.faqs.org/rfcs/rfc2131.html)
saying that the Source Address _must_ set to 0.0.0.0!!!!

So the attached patch will make M$ Windows happy and APIPA working.

Thanks,

Steven

[-- Attachment #2: linux-2.4.20-APAPI.patch --]
[-- Type: text/plain, Size: 730 bytes --]

+ diff -u ./net/ipv4/arp.c.APAPI ./net/ipv4/arp.c
--- ./net/ipv4/arp.c.APAPI	Tue Aug 12 13:00:59 2003
+++ ./net/ipv4/arp.c	Tue Aug 12 14:32:40 2003
@@ -760,6 +760,18 @@
 		goto out;
 	}

+#define MAKE_MS_WINDOWS_HAPPY
+#ifdef MAKE_MS_WINDOWS_HAPPY
+	/* Special case: IPv4 duplicate address detection packet (MS Windows) */
+	if (inet_addr_type(sip) == RTN_LOCAL) {
+		printk("ARP: IPv4 duplicate address detection packet (MS Windows)\n");
+		if (arp->ar_op == htons(ARPOP_REQUEST) &&
+		    inet_addr_type(tip) == RTN_LOCAL)
+			arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr);
+		goto out;
+	}
+#endif
+
 	if (arp->ar_op == htons(ARPOP_REQUEST) &&
 	    ip_route_input(skb, tip, sip, 0, dev) == 0) {

Build issues with 2.6.0-test3

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

I'm trying to build 2.6.0-test3 for some embedded boards and, as
reported before, there are compile problems.  The attached patches
fix these, but also bring up some questions:

* How best to handle optional support?  One of the patches fixes
  a problem of a missing system call (sys_pciconfig_iobase).  In
  this case, the platform I was building for has no PCI, so it's
  not configured in.  The way I fixed it was to conditionalize
  the syscall table.  An alternate way would be to have a module
  which is compiled if CONFIG_PCI is *not* set (or alternately
  have arch/ppc/kernel/pci.c always be compiled and export the
  appropriate functions that just return -ENOSYS).  Comments?
* I have a number of boards/platforms that I support that have
  not been moved into 2.6.  Can I just send patches for those
  as well?
* Has anyone succeeded in building & running 2.6 (or late 2.5)
  on any embedded boards (8xx/8260/405)?

Thanks.

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates

[-- Attachment #2: diffs --]
[-- Type: text/x-patch, Size: 2274 bytes --]

Index: arch/ppc/8260_io/enet.c
===================================================================
RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/enet.c,v
retrieving revision 1.1
diff -u -5 -p -r1.1 enet.c
--- arch/ppc/8260_io/enet.c	12 Aug 2003 12:18:15 -0000	1.1
+++ arch/ppc/8260_io/enet.c	12 Aug 2003 13:32:35 -0000
@@ -611,10 +611,11 @@ static void set_multicast_list(struct ne
 static int __init scc_enet_init(void)
 {
 	struct net_device *dev;
 	struct scc_enet_private *cep;
 	int i, j;
+        int err;
 	unsigned char	*eap;
 	unsigned long	mem_addr;
 	bd_t		*bd;
 	volatile	cbd_t		*bdp;
 	volatile	cpm8260_t	*cp;
Index: arch/ppc/8260_io/uart.c
===================================================================
RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/uart.c,v
retrieving revision 1.1
diff -u -5 -p -r1.1 uart.c
--- arch/ppc/8260_io/uart.c	12 Aug 2003 12:18:15 -0000	1.1
+++ arch/ppc/8260_io/uart.c	12 Aug 2003 13:30:40 -0000
@@ -2389,11 +2389,11 @@ void kgdb_map_scc(void)
 	up->smc_mrblr = RX_BUF_SIZE;		/* receive buffer length */
 	up->smc_maxidl = RX_BUF_SIZE;
 }
 #endif

-static kdev_t serial_console_device(struct console *c)
+static struct tty_driver *serial_console_device(struct console *c, int *index)
 {
 	*index = c->index;
 	return serial_driver;
 }

Index: arch/ppc/kernel/misc.S
===================================================================
RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/kernel/misc.S,v
retrieving revision 1.1
diff -u -5 -p -r1.1 misc.S
--- arch/ppc/kernel/misc.S	12 Aug 2003 12:18:16 -0000	1.1
+++ arch/ppc/kernel/misc.S	12 Aug 2003 13:44:25 -0000
@@ -1326,13 +1326,19 @@ _GLOBAL(sys_call_table)
 	.long sys_truncate64
 	.long sys_ftruncate64
 	.long sys_stat64	/* 195 */
 	.long sys_lstat64
 	.long sys_fstat64
+#ifdef CONFIG_PCI
 	.long sys_pciconfig_read
 	.long sys_pciconfig_write
 	.long sys_pciconfig_iobase 	/* 200 */
+#else
+	.long sys_ni_syscall /* sys_pciconfig_read */
+	.long sys_ni_syscall /* sys_pciconfig_write */
+	.long sys_ni_syscall /* sys_pciconfig_iobase 	/* 200 */
+#endif
 	.long sys_ni_syscall		/* 201 - reserved - MacOnLinux - new */
 	.long sys_getdents64
 	.long sys_pivot_root
 	.long sys_fcntl64
 	.long sys_madvise	/* 205 */

Re: Build issues with 2.6.0-test3

[Tom Rini]

On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:

> * How best to handle optional support?  One of the patches fixes
>   a problem of a missing system call (sys_pciconfig_iobase).  In
>   this case, the platform I was building for has no PCI, so it's
>   not configured in.  The way I fixed it was to conditionalize
>   the syscall table.  An alternate way would be to have a module
>   which is compiled if CONFIG_PCI is *not* set (or alternately
>   have arch/ppc/kernel/pci.c always be compiled and export the
>   appropriate functions that just return -ENOSYS).  Comments?

'cond_syscall' is _supposed_ to work here.  But in this one case, it
does not.  I've tried tracking this down a little bit, and the 'weak'
asm bits make it as far as the pci.s file, but not the pci.o.  And to
make it all the more odd, if I threw the cond_syscall into a file in
kernel/ (just to try it out), it works.

> * I have a number of boards/platforms that I support that have
>   not been moved into 2.6.  Can I just send patches for those
>   as well?

In the same manner you did for 2.4, yes (logical patches, and preferably
against linux-2.5 (linux-2.6 now?) tree.  If something is missing there
(it shouldn't be, but it could be :)) that is in linuxppc-2.5, either
move it over in another changeset, or bug myself / paul / ben.

> * Has anyone succeeded in building & running 2.6 (or late 2.5)
>   on any embedded boards (8xx/8260/405)?

No / Yes / Yes.

BTW:
> Index: arch/ppc/8260_io/uart.c
> ===================================================================
> RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/uart.c,v
> retrieving revision 1.1
> diff -u -5 -p -r1.1 uart.c
> --- arch/ppc/8260_io/uart.c	12 Aug 2003 12:18:15 -0000	1.1
> +++ arch/ppc/8260_io/uart.c	12 Aug 2003 13:30:40 -0000
> @@ -2389,11 +2389,11 @@ void kgdb_map_scc(void)
>  	up->smc_mrblr = RX_BUF_SIZE;		/* receive buffer length */
>  	up->smc_maxidl = RX_BUF_SIZE;
>  }
>  #endif
>
> -static kdev_t serial_console_device(struct console *c)
> +static struct tty_driver *serial_console_device(struct console *c, int *index)
>  {
>  	*index = c->index;
>  	return serial_driver;
>  }

After looking at the similar code in drivers/serial, I don't think this
is sufficient.  But I didn't dig too far into seee what c->data was
there.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Build issues with 2.6.0-test3

[Matt Porter]

On Tue, Aug 12, 2003 at 08:25:03AM -0700, Tom Rini wrote:
>
> On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
> > * Has anyone succeeded in building & running 2.6 (or late 2.5)
> >   on any embedded boards (8xx/8260/405)?
>
> No / Yes / Yes.

I think only walnut (for 405) is verified working.  Both 44x's
too.  Other 40x need work.

Regards,
--
Matt Porter
mporter@kernel.crashing.org

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Build issues with 2.6.0-test3

[Gary Thomas]

On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
> On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
>
> > * How best to handle optional support?  One of the patches fixes
> >   a problem of a missing system call (sys_pciconfig_iobase).  In
> >   this case, the platform I was building for has no PCI, so it's
> >   not configured in.  The way I fixed it was to conditionalize
> >   the syscall table.  An alternate way would be to have a module
> >   which is compiled if CONFIG_PCI is *not* set (or alternately
> >   have arch/ppc/kernel/pci.c always be compiled and export the
> >   appropriate functions that just return -ENOSYS).  Comments?
>
> 'cond_syscall' is _supposed_ to work here.  But in this one case, it
> does not.  I've tried tracking this down a little bit, and the 'weak'
> asm bits make it as far as the pci.s file, but not the pci.o.  And to
> make it all the more odd, if I threw the cond_syscall into a file in
> kernel/ (just to try it out), it works.
>

Which "pci.c"?  The one in arch/ppc/kernel isn't even being compiled
in this case.  Are you saying that it should (and behave differently
when CONFIG_PCI isn't set)?

> > * I have a number of boards/platforms that I support that have
> >   not been moved into 2.6.  Can I just send patches for those
> >   as well?
>
> In the same manner you did for 2.4, yes (logical patches, and preferably
> against linux-2.5 (linux-2.6 now?) tree.  If something is missing there
> (it shouldn't be, but it could be :)) that is in linuxppc-2.5, either
> move it over in another changeset, or bug myself / paul / ben.
>

OK.

> > * Has anyone succeeded in building & running 2.6 (or late 2.5)
> >   on any embedded boards (8xx/8260/405)?
>
> No / Yes / Yes.
       ^^^ How?  These compile errors would prevent this.

>
> BTW:
> > Index: arch/ppc/8260_io/uart.c
> > ===================================================================
> > RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/uart.c,v
> > retrieving revision 1.1
> > diff -u -5 -p -r1.1 uart.c
> > --- arch/ppc/8260_io/uart.c	12 Aug 2003 12:18:15 -0000	1.1
> > +++ arch/ppc/8260_io/uart.c	12 Aug 2003 13:30:40 -0000
> > @@ -2389,11 +2389,11 @@ void kgdb_map_scc(void)
> >  	up->smc_mrblr = RX_BUF_SIZE;		/* receive buffer length */
> >  	up->smc_maxidl = RX_BUF_SIZE;
> >  }
> >  #endif
> >
> > -static kdev_t serial_console_device(struct console *c)
> > +static struct tty_driver *serial_console_device(struct console *c, int *index)
> >  {
> >  	*index = c->index;
> >  	return serial_driver;
> >  }
>
> After looking at the similar code in drivers/serial, I don't think this
> is sufficient.  But I didn't dig too far into seee what c->data was
> there.

It seems to be [virtually] the same as in
  arch/ppc/8xx_io/uart.c
  drivers/char/amiserial.c
  drivers/char/serial_tx3912.c
  drivers/char/sh-sci.c
  drivers/macintosh/macserial.c

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Build issues with 2.6.0-test3

[Tom Rini]

On Tue, Aug 12, 2003 at 09:40:20AM -0600, Gary Thomas wrote:
> On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
> > On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
> >
> > > * How best to handle optional support?  One of the patches fixes
> > >   a problem of a missing system call (sys_pciconfig_iobase).  In
> > >   this case, the platform I was building for has no PCI, so it's
> > >   not configured in.  The way I fixed it was to conditionalize
> > >   the syscall table.  An alternate way would be to have a module
> > >   which is compiled if CONFIG_PCI is *not* set (or alternately
> > >   have arch/ppc/kernel/pci.c always be compiled and export the
> > >   appropriate functions that just return -ENOSYS).  Comments?
> >
> > 'cond_syscall' is _supposed_ to work here.  But in this one case, it
> > does not.  I've tried tracking this down a little bit, and the 'weak'
> > asm bits make it as far as the pci.s file, but not the pci.o.  And to
> > make it all the more odd, if I threw the cond_syscall into a file in
> > kernel/ (just to try it out), it works.
>
> Which "pci.c"?  The one in arch/ppc/kernel isn't even being compiled
> in this case.  Are you saying that it should (and behave differently
> when CONFIG_PCI isn't set)?

Too early in the AM.  I meant arch/ppc/kernel/syscall.c (which is being
compiled) not arch/ppc/kernel/pci.c

> > > * Has anyone succeeded in building & running 2.6 (or late 2.5)
> > >   on any embedded boards (8xx/8260/405)?
> >
> > No / Yes / Yes.
>        ^^^ How?  These compile errors would prevent this.

'Late' 2.5.  Before DaveM broke 8260_io/enet.c, and before the serial
change.

> > > Index: arch/ppc/8260_io/uart.c
> > > ===================================================================
> > > RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/uart.c,v
> > > retrieving revision 1.1
> > > diff -u -5 -p -r1.1 uart.c
> > > --- arch/ppc/8260_io/uart.c	12 Aug 2003 12:18:15 -0000	1.1
> > > +++ arch/ppc/8260_io/uart.c	12 Aug 2003 13:30:40 -0000
> > > @@ -2389,11 +2389,11 @@ void kgdb_map_scc(void)
> > >  	up->smc_mrblr = RX_BUF_SIZE;		/* receive buffer length */
> > >  	up->smc_maxidl = RX_BUF_SIZE;
> > >  }
> > >  #endif
> > >
> > > -static kdev_t serial_console_device(struct console *c)
> > > +static struct tty_driver *serial_console_device(struct console *c, int *index)
> > >  {
> > >  	*index = c->index;
> > >  	return serial_driver;
> > >  }
> >
> > After looking at the similar code in drivers/serial, I don't think this
> > is sufficient.  But I didn't dig too far into seee what c->data was
> > there.
>
> It seems to be [virtually] the same as in
>   arch/ppc/8xx_io/uart.c
>   drivers/char/amiserial.c
>   drivers/char/serial_tx3912.c
>   drivers/char/sh-sci.c
>   drivers/macintosh/macserial.c

Those are all of the obsolete, and probably broken drivers.
drivers/serial is where all of the 'new' and working serial drivers are.
If you've got some time, the 8260 serial driver really should be
re-written as a driver inside of drivers/serial. :)

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Build issues with 2.6.0-test3

[Gary Thomas]

On Tue, 2003-08-12 at 09:46, Tom Rini wrote:
> On Tue, Aug 12, 2003 at 09:40:20AM -0600, Gary Thomas wrote:
> > On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
> > > On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
> > >
> > > > * How best to handle optional support?  One of the patches fixes
> > > >   a problem of a missing system call (sys_pciconfig_iobase).  In
> > > >   this case, the platform I was building for has no PCI, so it's
> > > >   not configured in.  The way I fixed it was to conditionalize
> > > >   the syscall table.  An alternate way would be to have a module
> > > >   which is compiled if CONFIG_PCI is *not* set (or alternately
> > > >   have arch/ppc/kernel/pci.c always be compiled and export the
> > > >   appropriate functions that just return -ENOSYS).  Comments?
> > >
> > > 'cond_syscall' is _supposed_ to work here.  But in this one case, it
> > > does not.  I've tried tracking this down a little bit, and the 'weak'
> > > asm bits make it as far as the pci.s file, but not the pci.o.  And to
> > > make it all the more odd, if I threw the cond_syscall into a file in
> > > kernel/ (just to try it out), it works.
> >
> > Which "pci.c"?  The one in arch/ppc/kernel isn't even being compiled
> > in this case.  Are you saying that it should (and behave differently
> > when CONFIG_PCI isn't set)?
>
> Too early in the AM.  I meant arch/ppc/kernel/syscall.c (which is being
> compiled) not arch/ppc/kernel/pci.c

I don't understand why either.  I did note that this construct is not
used in any other platform/architecture code.  For now, I'm using this
change (instead of the change to misc.S)

Index: arch/ppc/kernel/syscalls.c
===================================================================
RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/kernel/syscalls.c,v
retrieving revision 1.1
diff -u -5 -p -r1.1 syscalls.c
--- arch/ppc/kernel/syscalls.c	12 Aug 2003 12:18:16 -0000	1.1
+++ arch/ppc/kernel/syscalls.c	12 Aug 2003 19:07:58 -0000
@@ -37,10 +37,12 @@
 #include <linux/unistd.h>

 #include <asm/uaccess.h>
 #include <asm/ipc.h>
 #include <asm/semaphore.h>
+#undef cond_syscall
+#define cond_syscall(x) asmlinkage long x() __attribute__((weak)); asmlinkage long x() { return -ENOSYS; }

 void
 check_bugs(void)
 {
 }

> > > > Index: arch/ppc/8260_io/uart.c
> > > > ===================================================================
> > > > RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/uart.c,v
> > > > retrieving revision 1.1
> > > > diff -u -5 -p -r1.1 uart.c
> > > > --- arch/ppc/8260_io/uart.c	12 Aug 2003 12:18:15 -0000	1.1
> > > > +++ arch/ppc/8260_io/uart.c	12 Aug 2003 13:30:40 -0000
> > > > @@ -2389,11 +2389,11 @@ void kgdb_map_scc(void)
> > > >  	up->smc_mrblr = RX_BUF_SIZE;		/* receive buffer length */
> > > >  	up->smc_maxidl = RX_BUF_SIZE;
> > > >  }
> > > >  #endif
> > > >
> > > > -static kdev_t serial_console_device(struct console *c)
> > > > +static struct tty_driver *serial_console_device(struct console *c, int *index)
> > > >  {
> > > >  	*index = c->index;
> > > >  	return serial_driver;
> > > >  }
> > >
> > > After looking at the similar code in drivers/serial, I don't think this
> > > is sufficient.  But I didn't dig too far into seee what c->data was
> > > there.
> >
> > It seems to be [virtually] the same as in
> >   arch/ppc/8xx_io/uart.c
> >   drivers/char/amiserial.c
> >   drivers/char/serial_tx3912.c
> >   drivers/char/sh-sci.c
> >   drivers/macintosh/macserial.c
>
> Those are all of the obsolete, and probably broken drivers.
> drivers/serial is where all of the 'new' and working serial drivers are.
> If you've got some time, the 8260 serial driver really should be
> re-written as a driver inside of drivers/serial. :)

I'll look into this.  Can you suggest a good driver to use as guidance?

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Build issues with 2.6.0-test3

[Tom Rini]

On Tue, Aug 12, 2003 at 01:13:37PM -0600, Gary Thomas wrote:
> On Tue, 2003-08-12 at 09:46, Tom Rini wrote:
> > On Tue, Aug 12, 2003 at 09:40:20AM -0600, Gary Thomas wrote:
> > > On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
> > > > On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
> > > > > Index: arch/ppc/8260_io/uart.c
> > > > > ===================================================================
> > > > > RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/uart.c,v
> > > > > retrieving revision 1.1
> > > > > diff -u -5 -p -r1.1 uart.c
> > > > > --- arch/ppc/8260_io/uart.c	12 Aug 2003 12:18:15 -0000	1.1
> > > > > +++ arch/ppc/8260_io/uart.c	12 Aug 2003 13:30:40 -0000
> > > > > @@ -2389,11 +2389,11 @@ void kgdb_map_scc(void)
> > > > >  	up->smc_mrblr = RX_BUF_SIZE;		/* receive buffer length */
> > > > >  	up->smc_maxidl = RX_BUF_SIZE;
> > > > >  }
> > > > >  #endif
> > > > >
> > > > > -static kdev_t serial_console_device(struct console *c)
> > > > > +static struct tty_driver *serial_console_device(struct console *c, int *index)
> > > > >  {
> > > > >  	*index = c->index;
> > > > >  	return serial_driver;
> > > > >  }
> > > >
> > > > After looking at the similar code in drivers/serial, I don't think this
> > > > is sufficient.  But I didn't dig too far into seee what c->data was
> > > > there.
> > >
> > > It seems to be [virtually] the same as in
> > >   arch/ppc/8xx_io/uart.c
> > >   drivers/char/amiserial.c
> > >   drivers/char/serial_tx3912.c
> > >   drivers/char/sh-sci.c
> > >   drivers/macintosh/macserial.c
> >
> > Those are all of the obsolete, and probably broken drivers.
> > drivers/serial is where all of the 'new' and working serial drivers are.
> > If you've got some time, the 8260 serial driver really should be
> > re-written as a driver inside of drivers/serial. :)
>
> I'll look into this.  Can you suggest a good driver to use as guidance?

For the conversion? Not off-hand.  But there should be some docs on how
to write these drivers on the ARM pages (RMK wrote this driver /
abstraction set), or just skim a few of the non-'core' files under
drivers/serial to see what's needed on the driver-specific part.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Build issues with 2.6.0-test3

[Thomas Gleixner]

On Tuesday 12 August 2003 23:54, Tom Rini wrote:
> > > >
> > > > It seems to be [virtually] the same as in
> > > >   arch/ppc/8xx_io/uart.c
> > > >   drivers/char/amiserial.c
> > > >   drivers/char/serial_tx3912.c
> > > >   drivers/char/sh-sci.c
> > > >   drivers/macintosh/macserial.c
> > >
> > > Those are all of the obsolete, and probably broken drivers.
> > > drivers/serial is where all of the 'new' and working serial drivers
> > > are. If you've got some time, the 8260 serial driver really should be
> > > re-written as a driver inside of drivers/serial. :)
> >
> > I'll look into this.  Can you suggest a good driver to use as guidance?
>
> For the conversion? Not off-hand.  But there should be some docs on how
> to write these drivers on the ARM pages (RMK wrote this driver /
> abstraction set), or just skim a few of the non-'core' files under
> drivers/serial to see what's needed on the driver-specific part.

I have a nearly ready to use driver for MPC860, which uses driver/serial.c.
There is just an issue regarding startup, when the mmu is not up.

Maybe it can be helpful. It has support for configurable pins and flowcontrol.

If somebody is interrested, I can provide the code and some help to get it
running.

--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Build issues with 2.6.0-test3

[Tom Rini]

On Wed, Aug 13, 2003 at 01:09:05AM +0200, Thomas Gleixner wrote:
> On Tuesday 12 August 2003 23:54, Tom Rini wrote:
> > > > >
> > > > > It seems to be [virtually] the same as in
> > > > >   arch/ppc/8xx_io/uart.c
> > > > >   drivers/char/amiserial.c
> > > > >   drivers/char/serial_tx3912.c
> > > > >   drivers/char/sh-sci.c
> > > > >   drivers/macintosh/macserial.c
> > > >
> > > > Those are all of the obsolete, and probably broken drivers.
> > > > drivers/serial is where all of the 'new' and working serial drivers
> > > > are. If you've got some time, the 8260 serial driver really should be
> > > > re-written as a driver inside of drivers/serial. :)
> > >
> > > I'll look into this.  Can you suggest a good driver to use as guidance?
> >
> > For the conversion? Not off-hand.  But there should be some docs on how
> > to write these drivers on the ARM pages (RMK wrote this driver /
> > abstraction set), or just skim a few of the non-'core' files under
> > drivers/serial to see what's needed on the driver-specific part.
>
> I have a nearly ready to use driver for MPC860, which uses driver/serial.c.
> There is just an issue regarding startup, when the mmu is not up.
>
> Maybe it can be helpful. It has support for configurable pins and flowcontrol.
>
> If somebody is interrested, I can provide the code and some help to get it
> running.

I'd be interested in looking at it.  Do you have other patches to bring
MPC860 support for 2.6 up to date?  Or is this using the 2.4 version of
drivers/serial?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Questions about ARP

[Dan Malek]

Steven Scholz wrote:

> Windows is checking for duplicate addresses using ARP packets with
> source _and_
> destination address set to the address in question. So of course Linux
> won't answer it!
>
> But I can't find a single word in the RFC2131
> (http://www.faqs.org/rfcs/rfc2131.html)
> saying that the Source Address _must_ set to 0.0.0.0!!!!

I don't remember if it was in RFC2131 or RFC1541.  RFC2131 is an updated
version of RFC1541, so I thought the words would still be there.  In
any case it suggests as part of a DHCP the client tests to ensure the
address isn't already in use by sending a ARP using the sender hardware
address and setting the sender IP address to zero to avoid confusing
ARP caches in other hosts on the network.  I don't remember the exact
words, but RFCs tend to be terse and concise in the area where you
need to pay attention to detail :-)

I'd suggest using the linux kernel or some networking mailing lists
to discuss this.  I wouldn't apply this patch because it seems to be
wrong in the eyes of the RFCs, and I could never get it pushed into
the network portion of the source tree.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/