Re: [uCsimm] CS8900 Chip Selection

From: D. Jeff Dionne (
Date: Mon Aug 28 2000 - 23:59:26 EDT

Steffen Plotner <> said:

> Hello,
> I have a simple question about the choice of the CS8900 LAN chip: the linux
> software driver has to process any and all incoming packets once it receives
> an interrupt. If you don't process all packets, you will not get
> interrupted again.

For all practical purposes, all ethernet devices have the same requirement.

> So in English that means, if someone does a ping -f (ping flood) the uClinux
> SIMM device will have no choice but to deal with the ping flood - it does
> remarkably well at that - except that NO other process can do anything
> because the flood has taken over the system. Try the following, connect

Yup. That's why you may need to use the RTLinux extensions. The Linux kernel
(and therefore the uClinux kernel) only gaurentees soft real time, and
reserves the right to block interrupts for arbitrary lengths of time. The
RTLinux layer for uClinux/m68k fixes that by running uClinux as the idle
loop of a hard real time scheduler (and virtualizing interrupts).

> using the serial port, and perform the ping flood against the device. While
> the ping flood occurs, attempt to do anything with the serial connection.

Or set the serial port to 115kbps and flood data at it. Your time critical
task will be preempted by the serial driver too.

> How exactly can CS8900 chip set be used in an embedded device, when it
> possible to perform such a simple DoS (Denial of Service) attach?

Any ethernet device suffers from the same problem. Code running under
uClinux+RTLinux 0.9j on a uCsimm shows better than plus or minus 5
microseconds of timing jitter while being hit with ping -f. Simply
because the ethernet driver is lower priority than the real time task(s).

> Here is the snippet of source code reference of the CS8900.c file which I
> found, proving my points above

Applies to _any_ linux (or other OS for that matter) device driver. It's
the responsibility of the OS' real time scheduler to make sure real time
tasks can preempt the device drivers. You get that with uClinux+RTlinux,
but not with straight linux OR uClinux. And it's _your_ responsibility as
the engineer to make sure the system is still schedulable. That is,
everything that needs to run gets it's required chunk of CPU time when you
design a system using a hard real time OS like uClinux+RTLinux. That
includes ethernet drivers...

> This message resent by the list server

D. Jeff Dionne                              
   -VP Research and Development, Office of the CTO

Lineo - Put Linux Anywhere

This message resent by the list server

This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:37 EST