[tulip] Tulip Driver, or is it the PCI subsystem ?

David Flynn Dave@keston.u-net.com
Fri, 3 Aug 2001 01:53:46 +0100


Hi guys,
            Once apon a time, there was and still is a number of computers
with deranged bioses that insist on probing devices on the other side of a
PCI bridge in the wrong order, this was not a problem on the whole, as many
cards dont have PCI bridges on them, however a few people had a bad
experience with certain multi port NICs that used DEC tulip chips.

The problem was that for some reason which is not important, there was only
one EEPROM on the board, and was attatched to the first device and it was up
to the driver to work something out.  there was a provision for this, and
the majority of multiport NICs went on content with their lives, however a
few were burdoned with the unfortunate co incidence of trying to run the NIC
in one of these aforementioned computers with deranged bioses.

What would happen, is that the ("officially") last network port would be
detected first, and upon discovering there was no EEPROM, the driver would
either squeal or make something up, the last port to be detected should have
been the first and the EEPROM was detected and made of use, so one ended up
with a single working port.

Eventually due to advances in the driver, a reverse probe option was added,
which was brilliant, the board was probed in reverse, and everything was
tickety boo, as Donald continued his driver development, the reverse probe
option was eventually removed, as his new fangled scanning thing did it
automatically (or something like that).

Now, it came to pass that the 2.4 kernel came into existance, and lo and
behold, contained within a "new" tulip driver, one that wouldnt be coujouled
into doing a reverse probe or what ever, so the multiport card is rendered
75% uselsess

Donald has this very nice development driver, which is even worse, under
either 2.2.19 or 2.4.x the driver doesnt work, in that i cant get it to
configure all the ports correctly.

now, all that i want to know, is What on earth has been changed to
COMPLETELY retard what i saw as a usefull card and driver, for my (and other
people), the card is useless, and even worse, so is the damn server its
connected to.

i would be very happy to help in any way i can, let people do what they like
to the driver and test it on this box, because its doing absolutly nothing
at the moment, i would even go as far as to play with the driver my self,
but happen to know sod all about the linux kernel, so i think you will back
me up in thinking that its unwise.

Here is the transcript of an e-mail i sent to Donald Becker on the subject,
and to this date, he has never replyed to it ***, i know he is very busy,
and
seems to not like the 2.4 kernels, so i am not too bothered that my
questions have gone un answered


*** NOTE: this may be due to a missconfiguration in the local mail server,
ignore that paragraph if it is

Thanks guys,
Regards,
Dave

btw, the 2.4 driver works "perfectly" with a non retarded BIOS

----- Original Message -----
From: "David Flynn" <Dave@keston.u-net.com>
To: "Donald Becker" <becker@scyld.com>
Cc: <tulip@scyld.com>
Sent: Wednesday, July 25, 2001 12:31 PM
Subject: Re: [tulip] many tulip problems with a cogent 4port nic


> BlankSorry guys if this is a repeat, it seems that the mail server may
have
> skrewed something up ...
>
> ----- Original Message -----
> From: "Donald Becker" <becker@scyld.com>
> To: <Dave@keston.u-net.com>
> Cc: <tulip@scyld.com>
> Sent: Tuesday, July 17, 2001 1:14 PM
> Subject: Re: [tulip] many tulip problems with a cogent 4port nic
>
> Sorry its been a while, ive been on holiday for a week ...
>
> Ok, i managed to (eventually) compile your pci-scan and tulip drivers on
> kernel 2.4.5 without getting unresolved symbols using the following
command
> :
>
>
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fom
>
it-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -ma
> rch=i586 -DMODULE -DMODVERSIONS -include
> /usr/src/linux/include/linux/modversions.h -c tulip.c
>
>
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fom
>
it-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -ma
> rch=i586 -DMODULE -DMODVERSIONS -include
> /usr/src/linux/include/linux/modversions.h -c pci-scan.c
>
>
> > On Sat, 14 Jul 2001 Dave@keston.u-net.com wrote:
> >
> > >      i seem to be in the unfortunate position of owning a motherboard
> > > with an AMI bios, and a 4 port NIC.  The NIC is a cogent 4port thingy,
> > > with four DEC 21040 chips and the 21050 ( i think) pci-pci bridge. (i
> > > am sorry i cannot be more specific but i cant gain access to the card,
> > > and am working from memory on what it is)
> >
> > There are several Cogent (now Adaptec) 4 port cards.
> > 4*21040
> ^^^^ its this one
>
> > 4*21140
> > 4*21143 w/ SYM
> > 4*21143 w/ MII
> >
> > > Firstly, i am running linux kernel 2.4.5, and using the tulip driver
> > > built with the kernel sources.
> > > It would seem that i have a problem with the probing of the card, ie,
> > > the card has one (S?)ROM and the probing is being done in the wrong
> > > order (apparently a bios problem, yes ?)
> >
> > I haven't checked the 2.4 scan code -- the scan order could be a Linux
> > issue.
>
> ok, done some playing with this, using the 'old' 2.2.19 tulip driver it
only
> detects correctly with reverse_probe=1
> and the card seems to work fine, (ive tested it with eth0 and eth3 both
> running simultaniously, and it doesnt crash)
>
> using the new tulip test driver under 2.2.19, the probing is done in the
> wrong order, and the following is outputted :
>
> tulip.c:v0.92w 7/9/2001 Written by Donald Becker <becker@scyld.com>
>   http://...yadda
> eth0: Digital DC21040 Tulip rev 36 at 0xc281bc00, EEPROM not present,
> 00:4C:69:6E:75:79 IRQ 11
> eth1: Digital DC21040 Tulip rev 36 at 0xc281d800, EEPROM not present,
> 00:4C:69:6E:75:79 IRQ 11
> eth2: Digital DC21040 Tulip rev 36 at 0xc281f400, EEPROM not present,
> 00:4C:69:6E:75:79 IRQ 11
> eth3: Digital DC21040 Tulip rev 36 at 0xc2821000, 00:00:92:92:39:58 IRQ 3
>
> if i try and bring up any interface the system hangs.
>
> likewise for 2.4.5, the driver does exactly the same, however, under 2.4.5
> if you try to remove the module the following error occurs:
>
>
> Trying to free nonexistent resource <c2821000-c282107f>
> Trying to free nonexistent resource <c281f400-c281f47f>
> Trying to free nonexistent resource <c281d800-c281d87f>
> Trying to free nonexistent resource <c281bc00-c281bc7f>
>
> this does not happen under 2.2.19
>
> >
> > > here is the output from dmesg with respect to the tulip driver:
> > > Linux Tulip driver version 0.9.15-pre2 (May 16, 2001)
> > > eth0: Digital DC21040 Tulip rev 36 at 0xfc80, EEPROM not present,
> 00:4C:69:6E:75:79, IRQ 11.
> > ...
> > > eth3: Digital DC21040 Tulip rev 36 at 0xf800, 00:00:92:92:39:58, IRQ
3.
> >
> > > the first three eth ports have incorrect MAC addresses, bassed on
> > > \0LINUX (this is why i am guessing the probing is in the wrong order),
> > > and am i also correct in thinking the IRQ's are wrong ?
> >
> > A common x86 BIOS bug is failing to correctly assign the IRQs to the
> > devices on the other side of a PCI bus bridge.  Few cards use bus
> > bridges, so this problem was around for years.
> >
> > I worked around the IRQ problem in my drivers by copying the IRQ setting
> > from the first device.
> >
> > > here is an output from # ./lspci -vv
> > > 00:0d.0 Class 0604: 1011:0001 (rev 02)
> > >         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> > >         I/O behind bridge: 0000f000-0000ffff
> > >         Memory behind bridge: ff900000-ff9fffff
> > > 01:04.0 Class 0200: 1011:0002 (rev 24)
> > >         Interrupt: pin A routed to IRQ 3
> > >         Region 0: I/O ports at f800 [size=128]
> > >         Region 1: Memory at ff9ff000 (32-bit, non-prefetchable)
> [size=128]
> > >
> > > 01:05.0 Class 0200: 1011:0002 (rev 24)
> > >         Interrupt: pin A routed to IRQ 9
> > >         Region 0: I/O ports at f880 [size=128]
> > >         Region 1: Memory at ff9ff400 (32-bit, non-prefetchable)
> [size=128]
> > >
> > > 01:06.0 Class 0200: 1011:0002 (rev 24)
> > >         Interrupt: pin A routed to IRQ 10
> > >         Region 0: I/O ports at fc00 [size=128]
> > >         Region 1: Memory at ff9ff800 (32-bit, non-prefetchable)
> [size=128]
> > >
> > > 01:07.0 Class 0200: 1011:0002 (rev 24)
> > >         Interrupt: pin A routed to IRQ 11
> > >         Region 0: I/O ports at fc80 [size=128]
> > >         Region 1: Memory at ff9ffc00 (32-bit, non-prefetchable)
> [size=128]
> >
> >
> > > i was under the impression that the drivers now didnt have a problem
> > > with reverse probing, the options in your latest sources apear to be
> > > depreciated, and dont exist anywhere else.
> >
> > My driver has explicit code to back-copy the media information to
> > previously discovered chips.
>
> which isnt working in this case, as it hasnt detected any media
information
> yet (reverse_probe needed in older drivers)
>
> > > however, i am under the impression that your drivers are incompatable
> > > with the 2.4.x kernels (i cant get them to compile, and you say
> > > something about it on your site)
> >
> > The versions in the 'test' directly mostly work with 2.4, however I do
> > not test with the 2.4 kernel.
>
> see above
>
> >
> > > i have tried the de4x5 driver (in the kernel tree) and it doesnt seem
> > > to want to play ball either, however, it does seemingly get the IRQ's
> > > right.
> >
> > > the final thing, which may be related is the fact with either driver,
> > > tulip or de4x5 in the kernel tree, i can bring up any of the four
> > > interfaces, onely one of which works, however, if i try to bring up
> > > two interfaces the whole system locksup with out any messages of any
> > > sort.
> >
> > Uhmmm, what makes you believe that the de4x5 driver has the interrupt
> > assignment "right"?
>
> on this issue i am only speculating, but you can probabally answer this
> better:
>
> under 2.2.19 (and 2.4)
>
> a cat of /proc/pci reveals :
>
> Bus  1, device   7, function  0:
>     Ethernet controller: DEC DC21040 (rev 36).
>       Medium devsel.  Fast back-to-back capable.  IRQ 11.  Master Capable.
> Latency=66.
>       I/O at 0xfc80 [0xfc81].
>       Non-prefetchable 32 bit memory at 0xff9ffc00 [0xff9ffc00].
>   Bus  1, device   6, function  0:
>     Ethernet controller: DEC DC21040 (rev 36).
>       Medium devsel.  Fast back-to-back capable.  IRQ 10.  Master Capable.
> Latency=66.
>       I/O at 0xfc00 [0xfc01].
>       Non-prefetchable 32 bit memory at 0xff9ff800 [0xff9ff800].
>   Bus  1, device   5, function  0:
>     Ethernet controller: DEC DC21040 (rev 36).
>       Medium devsel.  Fast back-to-back capable.  IRQ 9.  Master Capable.
> Latency=66.
>       I/O at 0xf880 [0xf881].
>       Non-prefetchable 32 bit memory at 0xff9ff400 [0xff9ff400].
>   Bus  1, device   4, function  0:
>     Ethernet controller: DEC DC21040 (rev 36).
>       Medium devsel.  Fast back-to-back capable.  IRQ 3.  Master Capable.
> Latency=66.
>       I/O at 0xf800 [0xf801].
>       Non-prefetchable 32 bit memory at 0xff9ff000 [0xff9ff000].
>
> note the IRQs, now your driver sets them all to IRQ3, the de4x5 sets them
to
> the above values ....
> which is correct ? (note that it is only in the old tulip driver that i
can
> get more than 2 interfaces up at any one time)
>
>
> >
> > Please try my driver with 2.2 and 2.4, and send a report.
> >
>
> that is my report, basically under either kernel, the test version of the
> tulip driver (0.92w) does not work, and crashes when you try to bring up
an
> interface.
>
> if there is anything anyone can sugest ? (any horrid kludges to force the
> reverse probe ?, simmilar to the old tulip driver ?)
>
> if there is any further details people want, please ask, and ill get them
> for you.
>
> donald, what are the major changes to the tulip driver thats in the 2.2.19
> kernel and the test one ? and would it be worth trying to port the 2.2.19
> driver to 2.4, as it seems to work under 2.2.19, where as nothing else
does
> (as a tempory solution)?, or is it worth  finding out and fixing the
actual
> problem ?
>
> Thanks,
>
> Dave
> >
> > Donald Becker becker@scyld.com
>
>
>


and the original mail i sent him



----- Original Message -----
From: <Dave@keston.u-net.com>
To: <tulip@scyld.com>
Sent: Saturday, July 14, 2001 12:35 AM
Subject: [tulip] many tulip problems with a cogent 4port nic


> Dear Donald,
>      i seem to be in the unfortunate position of owning a motherboard with
an AMI bios, and a 4 port NIC.  The NIC is a cogent 4port thingy, with four
DEC 21040 chips and the 21050 ( i think) pci-pci bridge. (i am sorry i
cannot be more specific but i cant gain access to the card, and am working
from memory on what it is)
>
>       Firstly, i am running linux kernel 2.4.5, and using the tulip driver
built with the kernel sources.
>       It would seem that i have a problem with the probing of the card,
ie, the card has one (S?)ROM and the probing is being done in the wrong
order (apparently a bios problem, yes ?)
>
> here is the output from dmesg with respect to the tulip driver:
> Linux Tulip driver version 0.9.15-pre2 (May 16, 2001)
> eth0: Digital DC21040 Tulip rev 36 at 0xfc80, EEPROM not present,
00:4C:69:6E:75:79, IRQ 11.
> eth1: Digital DC21040 Tulip rev 36 at 0xfc00, EEPROM not present,
00:4C:69:6E:75:7A, IRQ 11.
> eth2: Digital DC21040 Tulip rev 36 at 0xf880, EEPROM not present,
00:4C:69:6E:75:7B, IRQ 11.
> eth3: Digital DC21040 Tulip rev 36 at 0xf800, 00:00:92:92:39:58, IRQ 3.
>
> the first three eth ports have incorrect MAC addresses, bassed on \0LINUX
(this is why i am guessing the probing is in the wrong order), and am i also
correct in thinking the IRQ's are wrong ?
>
> here is an output from # ./lspci -vv
> 00:0d.0 Class 0604: 1011:0001 (rev 02)
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64, cache line size 08
>         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>         I/O behind bridge: 0000f000-0000ffff
>         Memory behind bridge: ff900000-ff9fffff
>         Prefetchable memory behind bridge: ff800000-ff8fffff
>         BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
>
> 01:04.0 Class 0200: 1011:0002 (rev 24)
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
>         Latency: 66
>         Interrupt: pin A routed to IRQ 3
>         Region 0: I/O ports at f800 [size=128]
>         Region 1: Memory at ff9ff000 (32-bit, non-prefetchable) [size=128]
>
> 01:05.0 Class 0200: 1011:0002 (rev 24)
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
>         Latency: 66
>         Interrupt: pin A routed to IRQ 9
>         Region 0: I/O ports at f880 [size=128]
>         Region 1: Memory at ff9ff400 (32-bit, non-prefetchable) [size=128]
>
> 01:06.0 Class 0200: 1011:0002 (rev 24)
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
>         Latency: 66
>         Interrupt: pin A routed to IRQ 10
>         Region 0: I/O ports at fc00 [size=128]
>         Region 1: Memory at ff9ff800 (32-bit, non-prefetchable) [size=128]
>
> 01:07.0 Class 0200: 1011:0002 (rev 24)
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
>         Latency: 66
>         Interrupt: pin A routed to IRQ 11
>         Region 0: I/O ports at fc80 [size=128]
>         Region 1: Memory at ff9ffc00 (32-bit, non-prefetchable) [size=128]
>
> which corresponds to  cat /proc/pci
>
> Bus  0, device  13, function  0:
>     PCI bridge: Digital Equipment Corporation DECchip 21050 (rev 2).
>       Master Capable.  Latency=64.  Min Gnt=3.
>   Bus  1, device   7, function  0:
>     Ethernet controller: Digital Equipment Corporation DECchip 21040
[Tulip] (#4) (rev 36).
>       IRQ 11.
>       Master Capable.  Latency=66.
>       I/O at 0xfc80 [0xfcff].
>       Non-prefetchable 32 bit memory at 0xff9ffc00 [0xff9ffc7f].
>   Bus  1, device   6, function  0:
>     Ethernet controller: Digital Equipment Corporation DECchip 21040
[Tulip] (#3) (rev 36).
>       IRQ 10.
>       Master Capable.  Latency=66.
>       I/O at 0xfc00 [0xfc7f].
>       Non-prefetchable 32 bit memory at 0xff9ff800 [0xff9ff87f].
>   Bus  1, device   5, function  0:
>     Ethernet controller: Digital Equipment Corporation DECchip 21040
[Tulip] (#2) (rev 36).
>       IRQ 9.
>       Master Capable.  Latency=66.
>       I/O at 0xf880 [0xf8ff].
>       Non-prefetchable 32 bit memory at 0xff9ff400 [0xff9ff47f].
>   Bus  1, device   4, function  0:
>     Ethernet controller: Digital Equipment Corporation DECchip 21040
[Tulip] (rev 36).
>       IRQ 3.
>       Master Capable.  Latency=66.
>       I/O at 0xf800 [0xf87f].
>       Non-prefetchable 32 bit memory at 0xff9ff000 [0xff9ff07f].
>
>
> the things that stikes me there are the 'correct' (?) IRQ's and the
difference in the revision.
>
> oh, and for completeness :
>
> root:~/tulip# ./tulip-diag -ee
> tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a Digital DC21040 Tulip adapter at 0xfc80.
>  Port selection is half-duplex.
>  Transmit stopped, Receive stopped, half-duplex.
>   The Rx process state is 'Stopped'.
>   The Tx process state is 'Stopped'.
>   The transmit unit is set to store-and-forward.
> EEPROM contents (64 words):
> 0x00:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x08:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x10:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x18:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x20:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x28:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x30:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x38:  0000 0000 0000 0000 0000 0000 0000 0000
>  ID block CRC 0xe3 (vs. 00).
>   Full contents CRC 0x6523 (read as 0x0000).
> Index #2: Found a Digital DC21040 Tulip adapter at 0xfc00.
>  Port selection is half-duplex.
>  Transmit stopped, Receive stopped, half-duplex.
>   The Rx process state is 'Stopped'.
>   The Tx process state is 'Stopped'.
>   The transmit unit is set to store-and-forward.
> EEPROM contents (64 words):
> 0x00:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x08:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x10:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x18:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x20:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x28:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x30:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x38:  0000 0000 0000 0000 0000 0000 0000 0000
>  ID block CRC 0xe3 (vs. 00).
>   Full contents CRC 0x6523 (read as 0x0000).
> Index #3: Found a Digital DC21040 Tulip adapter at 0xf880.
>  Port selection is half-duplex.
>  Transmit stopped, Receive stopped, half-duplex.
>   The Rx process state is 'Stopped'.
>   The Tx process state is 'Stopped'.
>   The transmit unit is set to store-and-forward.
> EEPROM contents (64 words):
> 0x00:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x08:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x10:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x18:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x20:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x28:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x30:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x38:  0000 0000 0000 0000 0000 0000 0000 0000
>  ID block CRC 0xe3 (vs. 00).
>   Full contents CRC 0x6523 (read as 0x0000).
> Index #4: Found a Digital DC21040 Tulip adapter at 0xf800.
>  Port selection is half-duplex.
>  Transmit started, Receive started, half-duplex.
>   The Rx process state is 'Waiting for packets'.
>   The Tx process state is 'Idle'.
>   The transmit unit is set to store-and-forward.
> EEPROM contents (64 words):
> 0x00:  0000 9292 5839 7d5e 5e7d 3958 9292 0000
> 0x08:  0000 9292 5839 7d5e 00ff aa55 00ff aa55
> 0x10:  0010 ffff ffff ffff 0000 9292 5939 7e5e
> 0x18:  5e7e 3959 9292 0000 0000 9292 5939 7e5e
> 0x20:  00ff aa55 00ff aa55 0010 ffff ffff ffff
> 0x28:  0000 9292 5a39 7f5e 5e7f 395a 9292 0000
> 0x30:  0000 9292 5a39 7f5e 00ff aa55 00ff aa55
> 0x38:  0010 ffff ffff ffff 0000 9292 5b39 805e
>  ID block CRC 0x17 (vs. 00).
>   Full contents CRC 0xb3ec (read as 0x805e).
>
> i was under the impression that the drivers now didnt have a problem with
reverse probing, the options in your latest sources apear to be depreciated,
and dont exist anywhere else.
>
> however, i am under the impression that your drivers are incompatable with
the 2.4.x kernels (i cant get them to compile, and you say something about
it on your site)
>
> i have tried the de4x5 driver (in the kernel tree) and it doesnt seem to
want to play ball either, however, it does seemingly get the IRQ's right.
>
>
> the final thing, which may be related is the fact with either driver,
tulip or de4x5 in the kernel tree, i can bring up any of the four
interfaces, onely one of which works, however, if i try to bring up two
interfaces the whole system locksup with out any messages of any sort.
>
> i am just pulling a copy of the latest 2.2 kernel to play with that,
although i really could do with the filtering in 2.4
>
> if you have anyadvice on how to rectify the situation, or require more
information, please dont hesitate to comment / ask.
>
> Thankyou very much
>
> Best regards,
>
> Dave
>


---------------------------------------
The information in this e-mail and any files sent with it is confidential to
the ordinary user of the e-mail address to which it was addressed and may
also be legally privileged. It is not to be relied upon by any person other
than the addressee except with the sender's prior written approval. If no
such approval is given, the sender will not accept liability (in negligence
or otherwise) arising from any third party acting, or refraining from
acting, on such information. If you are not the intended recipient of this
e-mail you may not copy, forward, disclose or otherwise use it or any part
of it in any form whatsoever. If you have received this e-mail in error
please notify the sender immediately, destroy any copies and delete it from
your computer system. Have a nice Day !
---------------------------------------------