hi
my smc epic100 card does not work with the device driver from
linux-2.4.3-ac7.
linux-2.2.19 works fine for me.
please take a look at my /var/log/messages ...
Apr 17 09:37:27 olibox kernel: epic100.c:v1.11 1/7/2001 Written by Donald Becker <[email protected]>
Apr 17 09:37:27 olibox kernel: http://www.scyld.com/network/epic100.html
Apr 17 09:37:27 olibox kernel: (unofficial 2.4.x kernel port, version 1.1.6, January 11, 2001)
Apr 17 09:37:27 olibox kernel: PCI: Found IRQ 10 for device 00:09.0
Apr 17 09:37:27 olibox kernel: epic100(00:09.0): MII transceiver #3 control 3000 status 7809.
Apr 17 09:37:27 olibox kernel: epic100(00:09.0): Autonegotiation advertising 01e1 link partner 0001.
Apr 17 09:37:27 olibox kernel: eth0: SMSC EPIC/100 83c170 at 0xe800, IRQ 10, 00:e0:29:09:c9:f0.
Apr 17 09:37:27 olibox kernel: eth0: Setting full-duplex based on MII #3 link partner capability of 45e1.
Apr 17 09:37:27 olibox kernel: eth0: Too much work at interrupt, IntrStatus=0x008d0004.
Apr 17 09:37:55 olibox kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 17 09:37:55 olibox kernel: eth0: Transmit timeout using MII device, Tx status 4003.
Apr 17 09:37:55 olibox kernel: eth0: Restarting the EPIC chip, Rx 1/1 Tx 2/12.
Apr 17 09:37:55 olibox kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 240000.
Apr 17 09:37:56 olibox kernel: eth0: Setting half-duplex based on MII #3 link partner capability of 0001.
...
Apr 17 09:38:15 olibox kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 17 09:38:15 olibox kernel: eth0: Transmit timeout using MII device, Tx status 000b.
Apr 17 09:38:15 olibox kernel: eth0: Restarting the EPIC chip, Rx 1/1 Tx 7/17.
Apr 17 09:38:15 olibox kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 240000.
Apr 17 09:38:19 olibox kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 17 09:38:19 olibox kernel: eth0: Transmit timeout using MII device, Tx status 000b.
Apr 17 09:38:19 olibox kernel: eth0: Restarting the EPIC chip, Rx 1/1 Tx 8/17.
Apr 17 09:38:19 olibox kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 240000.
Apr 17 09:38:23 olibox kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 17 09:38:23 olibox kernel: eth0: Transmit timeout using MII device, Tx status 000b.
Apr 17 09:38:23 olibox kernel: eth0: Restarting the EPIC chip, Rx 1/1 Tx 9/17.
Apr 17 09:38:23 olibox kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 240000.
Apr 17 09:38:27 olibox kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 17 09:38:27 olibox kernel: eth0: Transmit timeout using MII device, Tx status 000b.
Apr 17 09:38:27 olibox kernel: eth0: Restarting the EPIC chip, Rx 1/1 Tx 10/17.
Apr 17 09:38:27 olibox kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 240000.
Apr 17 09:38:27 olibox kernel: eth0: Too much work at interrupt, IntrStatus=0x008d0004.
Apr 17 09:38:31 olibox kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 17 09:38:31 olibox kernel: eth0: Transmit timeout using MII device, Tx status 000b.
Apr 17 09:38:31 olibox kernel: eth0: Restarting the EPIC chip, Rx 1/1 Tx 11/17.
Apr 17 09:38:31 olibox kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 240000.
...
olibox:/var/log # cat /proc/interrupts
CPU0
0: 2068590 XT-PIC timer
1: 51210 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 355790 XT-PIC es1371
8: 1 XT-PIC rtc
10: 95257 XT-PIC eth0
12: 625009 XT-PIC PS/2 Mouse
13: 1 XT-PIC fpu
14: 304339 XT-PIC ide0
15: 8 XT-PIC ide1
NMI: 0
olibox:/var/log # lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev 06)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 07)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050
00:09.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF (rev 06)
00:0b.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
01:00.0 VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 11)
00:09.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF (rev 06)
Subsystem: Standard Microsystems Corp [SMC] EtherPower II 10/100
Flags: bus master, fast devsel, latency 32, IRQ 10
I/O ports at e800
Memory at e1000000 (32-bit, non-prefetchable)
Expansion ROM at e0000000 [disabled]
yours, oliver teuber
On Tuesday 17 April 2001 18:45, Oliver Teuber wrote:
> my smc epic100 card does not work with the device driver from
> linux-2.4.3-ac7.
> linux-2.2.19 works fine for me.
Same behavior here. Just want to add that the 2.4.0 kernel (SuSE 7.1) also
works fine.
Stefan
On Wednesday 18 April 2001 20:40, Francois Romieu wrote:
> Hello,
>
> Oliver Teuber <[email protected]> ?crit :
> [...]
>
> > 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev
> > 06) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
> > 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev
> > 07) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
> > (rev 06) 00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050
> > 00:09.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF
> > (rev 06) 00:0b.0 Multimedia audio controller: Ensoniq ES1371
> > [AudioPCI-97] (rev 06) 01:00.0 VGA compatible controller: nVidia
> > Corporation Riva TnT2 [NV5] (rev 11)
>
> Could you:
> - send me the motherboard version+bios revision ?
> - see if there exists an updated bios ?
I don't believe the motherboard or the BIOS have anything to do with, simply because
I have been successfully using the SMC Etherpower with three different Motherboards
- ASUS TX97-XE, MSI K7 Pro, Gigagbyte GA-71XE4 -
and (at least) three different kernels: 2.0.x, 2.2.18, 2.4.0.
Something between 2.4.0 and 2.4.3 breaks the epic100 driver. That's it.
Cheers,
Stefan
--
Stefan R. Jaschke <[email protected]>
http://www.jaschke-net.de
Stefan Jaschke <[email protected]> ecrit :
[...]
> I don't believe the motherboard or the BIOS have anything to do with, simply
It may give a clue because the machine I wrote this mail from is a
2.4.3 + 2*EtherPower II it looks rather fine (old asus motherbord, BX,
backuped peaceful prod server):
I tried 2.4.3 on some bp6+epic100 (2.4.0/1/2/3 + misc ac). No problems either.
Around the 10 of february, Arnd Bergmandd <[email protected]> had
problems with the epic100. These appeared between two revisions of the
driver that differ only in the use of DMA mapping I made at the moment.
<digression>
Fwiw, it was essentially a matter of coding-style as on x86 the DMA mapping
actually called the former virt_to_phys and pci_dma_sync was rather empty.
It made no design change. It may be possible I assumed some data were in
memory as they are still in some cpu registers. I'll re-re-check that.
</digression>
Summary:
Arnd Bergmann:
orig epic100 "DMA mapped epic100 (any version)"
(<=2.4.0-ac9)
VT8363 ok fscked but ok after bios update
Daniel Nofftz:
2.4.2 2.4.3
VT82C595 ok fscked. (no mention of bios experience)
Oliver Teuber:
2.2.19 2.4.3-ac7
VT82C598 ok fscked
Romieu:
2.2.xx 2.4.[123]
82443BX ok ok
Now it's complicated by the fact that between 2.4.2 and 2.4.3, you
have DMA mapping + others changes in epic100 (they make sense imho).
What happen's if you compile 2.4.2 epic100 driver in a 2.4.3 tree (I) ?
[...]
> Something between 2.4.0 and 2.4.3 breaks the epic100 driver. That's it.
So far it's hard to say where it comes from.
I would really appreciate if you could give a look at (I).
If it doesn't change anything and you have spare time, some feedback
from bios experience will be welcome too.
--
Ueimor
Hi,
it seems the epic100 driver broke between 2.4.2 and 2.4.3.
I reloaded the epic100 module with the parameter "debug=6".
Unfortunately, I cannot make much out of the log:
Apr 20 12:47:01 antares kernel: epic100.c:v1.11 1/7/2001 Written by Donald Becker <[email protected]>
Apr 20 12:47:01 antares kernel: http://www.scyld.com/network/epic100.html
Apr 20 12:47:01 antares kernel: (unofficial 2.4.x kernel port, version 1.1.6, January 11, 2001)
Apr 20 12:47:01 antares kernel: epic100(00:08.0): EEPROM contents
Apr 20 12:47:01 antares kernel: e000 2829 ec39 aa00 001d 1c08 10b8 a011 0000 0000 0000 0000 0000 0000 0000 0000
Apr 20 12:47:01 antares kernel: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Apr 20 12:47:01 antares kernel: 0010 0000 1980 2100 0000 0000 0003 0000 0701 0000 0000 0000 4d53 3943 3334 5432
Apr 20 12:47:01 antares kernel: 2058 2020 0000 0000 0280 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Apr 20 12:47:01 antares kernel: epic100(00:08.0): MII transceiver #3 control 3000 status 7809.
Apr 20 12:47:01 antares kernel: epic100(00:08.0): Autonegotiation advertising 01e1 link partner 0001.
Apr 20 12:47:01 antares kernel: eth0: SMSC EPIC/100 83c170 at 0xd800, IRQ 9, 00:e0:29:28:39:ec.
Apr 20 12:48:07 antares kernel: eth0: Setting half-duplex based on MII xcvr 3 register read of 0001.
Apr 20 12:48:07 antares kernel: eth0: epic_open() ioaddr d800 IRQ 9 status 0512 half-duplex.
Apr 20 12:48:10 antares kernel: eth0: Media monitor tick, Tx status 0000000b.
Apr 20 12:48:10 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:10 antares kernel: eth0: Setting full-duplex based on MII #3 link partner capability of 41e1.
Apr 20 12:48:15 antares kernel: eth0: Media monitor tick, Tx status 0000000b.
Apr 20 12:48:15 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:20 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:20 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:25 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:25 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:30 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:30 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:35 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:35 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:40 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:40 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:45 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:45 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 240000 RxStatus 1090021.
Apr 20 12:48:45 antares kernel: eth0: Interrupt, status=0x00250001 new intstat=0x00240000.
Apr 20 12:48:45 antares kernel: In epic_rx(), entry 0 00601021.
Apr 20 12:48:45 antares kernel: epic_rx() status was 00601021.
Apr 20 12:48:45 antares kernel: eth0: Interrupt, status=0x00240000 new intstat=0x00240000.
Apr 20 12:48:45 antares kernel: eth0: exiting interrupt, intr_status=0x240000.
Apr 20 12:48:46 antares kernel: eth0: Interrupt, status=0x008d0004 new intstat=0x008c0000.
Apr 20 12:48:46 antares last message repeated 32 times
Apr 20 12:48:46 antares kernel: eth0: Too much work at interrupt, IntrStatus=0x008d0004.
Apr 20 12:48:46 antares kernel: eth0: exiting interrupt, intr_status=0x8d0004.
Apr 20 12:48:50 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:50 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 8c0000 RxStatus 6014a1.
Apr 20 12:48:55 antares kernel: eth0: Media monitor tick, Tx status 0000400b.
Apr 20 12:48:55 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 8c0000 RxStatus 6014a1.
I also noted that there are substantial differences between the original epic100.c at
http://www.scyld.com/network/epic100.html and the version included with 2.4.3.
Who did these changes?
Stefan J.
--
Stefan R. Jaschke <[email protected]>
http://www.jaschke-net.de
Stefan Jaschke wrote:
> I also noted that there are substantial differences between the original epic100.c at
> http://www.scyld.com/network/epic100.html and the version included with 2.4.3.
> Who did these changes?
Francois (PCI DMA) and me (everything else). The scyld version does not
support 2.4 kernels, so these changes were necessary.
Besides Francois changes, the biggest thing in 2.4.3 was a merge of
additional scyld.com code :)
I'm leaving on a trip so I won't be able to look at this until after
2.4.4 is released... Maybe one of you guys is willing to play patch
circus, and go through the changes to the epic driver one by one and see
which one caused the breakage. When I get back I'll take a look at
this.
Here's a suggestion to try: go through epic100.c and write 0x12
unconditionally to MIICfg register. Right now it is conditional: if
(dev->if_port...) out(0x12,ioaddr+MIICfg);
--
Jeff Garzik | The difference between America and England is that
Building 1024 | the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
| (random fortune)
On Friday 20 April 2001 12:25, Francois Romieu wrote:
> Summary:
> Arnd Bergmann:
> orig epic100 "DMA mapped epic100 (any version)"
> (<=2.4.0-ac9)
> VT8363 ok fscked but ok after bios update
>
> Daniel Nofftz:
> 2.4.2 2.4.3
> VT82C595 ok fscked. (no mention of bios experience)
>
> Oliver Teuber:
> 2.2.19 2.4.3-ac7
> VT82C598 ok fscked
>
> Romieu:
> 2.2.xx 2.4.[123]
> 82443BX ok ok
Stefan Jaschke:
2.2.xx 2.4.0 2.4.3 2.4.4-pre4
AMD 761 ok ok fails fails
# lspci
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01)
00:08.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF (rev 08)
> What happen's if you compile 2.4.2 epic100 driver in a 2.4.3 tree (I) ?
I'll try this asap.
Stefan
--
Stefan R. Jaschke <[email protected]>
http://www.jaschke-net.de
On Friday 20 April 2001 13:33, Jeff Garzik wrote:
> Here's a suggestion to try: go through epic100.c and write 0x12
> unconditionally to MIICfg register. Right now it is conditional: if
> (dev->if_port...) out(0x12,ioaddr+MIICfg);
I changed all three such lines. Same behavior as before.
<offtopic>
You also cc-d this to [email protected]. My message to this address
bounced. Is this a problem with my provider only?
'A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[email protected]:
unrouteable mail domain "skyld.com"'
</offtopic>
--
Stefan R. Jaschke <[email protected]>
http://www.jaschke-net.de
On Friday 20 April 2001 12:25, Francois Romieu wrote:
> What happen's if you compile 2.4.2 epic100 driver in a 2.4.3 tree (I) ?
> I would really appreciate if you could give a look at (I).
I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles and works without
problems.
This gives me a workable solution :-)
Cheers,
Stefan
Em Fri, Apr 20, 2001 at 02:07:11PM +0200, Stefan Jaschke escreveu:
> <offtopic>
> 'A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> [email protected]:
> unrouteable mail domain "skyld.com"'
> </offtopic>
s/skyld/scyld/g
- Arnaldo
Stefan Jaschke <[email protected]> ecrit :
[...]
> I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles and works without
> problems.
> This gives me a workable solution :-)
Thanks for the info.
Now, why do you get so much Receive Queue Empty indications...
--
Ueimor
On Friday 20 April 2001 16:33, Francois Romieu wrote:
> Stefan Jaschke <[email protected]> ecrit :
> > I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles
> > and works without problems.
> > This gives me a workable solution :-)
>
> Thanks for the info.
> Now, why do you get so much Receive Queue Empty indications...
Now, this is a question for more knowledgable persons than me :-)
Another question I have is about the different driver versions that
are around.
Till Harbaum <[email protected]> just sent
me a driver which is directly from SMC:
> As i already mentioned in a posting, that for some reason didn't show up in
> the list, i got a driver module source directly from SMC, that works fine
> with 2.4.3 and has the ability to use the optical interface.
> Till
It unpacks to
18458 Jul 14 1999 copying
1931 Mar 9 09:30 debug.h
10451 Mar 12 13:39 list.h
123761 Mar 13 16:05 lm.c
11547 Mar 12 13:37 lm.h
14872 Apr 5 11:35 lm.o
4761 Apr 13 2000 lm_cfg.h
29169 Mar 13 16:05 lm_epic.h
335 Apr 5 17:14 makefile
22096 Mar 13 16:06 mm.c
4754 Mar 17 2000 mm.h
3672 Apr 5 11:35 mm.o
676 Mar 26 09:51 readme.txt
21874 Apr 5 11:35 smcpwr2.o
24572 Mar 13 16:14 um.c
3550 Mar 13 16:08 um.h
5628 Apr 5 11:34 um.o
and "copying" is the GPL. It seems to be a not yet released extension of the driver
available from http://www.smc.de/sites/support/download/PCI/9432/LINUX/src9432lu.zip.
Some changelog reads " 03/13/2001 Ling Yue for linux kernel 2.4".
Is there communication between SMC and your group?
--
Stefan R. Jaschke <[email protected]>
http://www.jaschke-net.de
Stefan Jaschke <[email protected]> ?crit :
> On Friday 20 April 2001 16:33, Francois Romieu wrote:
> > Stefan Jaschke <[email protected]> ecrit :
> > > I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles
> > > and works without problems.
> > > This gives me a workable solution :-)
> >
> > Thanks for the info.
> > Now, why do you get so much Receive Queue Empty indications...
>
> Now, this is a question for more knowledgable persons than me :-)
I don't claim to be but it's quite amazing: in your logs,
the driver receives one packet and after that it go into a loop because
the adapter complains of the lack of available rx descriptors.
[Initialization of the card...32 rx descriptors are available for the card]
Apr 20 12:48:45 antares kernel: In epic_rx(), entry 0 00601021.
Apr 20 12:48:45 antares kernel: epic_rx() status was 00601021.
Apr 20 12:48:45 antares kernel: eth0: Interrupt, status=0x00240000 new
intstat=0x00240000.
Apr 20 12:48:45 antares kernel: eth0: exiting interrupt, intr_status=0x240000.
Incoming packet. 31 rx descriptors are available for the card.
Apr 20 12:48:46 antares kernel: eth0: Interrupt, status=0x008d0004 new
intstat=0x008c0000.
That shouldn't happen (RxFull in the code: the adapter sees a descriptor
owned by the CPU). The driver says to the card "Look again at the
descriptor" but alas it didn't do anything (coz this shouldn't happen here).
Apr 20 12:48:46 antares last message repeated 32 times
The adapter answer immediatly, kicks the same IRQ. The driver notices it
while it still is in epic_interrupt and after 32 try:
Apr 20 12:48:46 antares kernel: eth0: Too much work at interrupt,
IntrStatus=0x008d0004.
I assume nothing is overclocked or whatever
Could you try this patch (more output during the loop):
--- epic100.c.orig Fri Apr 20 11:54:57 2001
+++ epic100.c Fri Apr 20 17:55:25 2001
@@ -1083,8 +1083,19 @@
if (status & RxOverflow) { /* Missed a Rx frame. */
ep->stats.rx_errors++;
}
- if (status & (RxOverflow | RxFull))
+ if (status & RxOverflow)
outw(RxQueued, ioaddr + COMMAND);
+ if (status & RxFull) {
+ int i = 0;
+
+ for (i = 0; i < RX_RING_SIZE; i++) {
+ if((ep->rx_ring[i].rxstatus &
+ cpu_to_le32(DescOwn)) != 0) {
+ printk(KERN_INFO "%s: desc %2.2d owned by card\n", dev->name, i);
+ }
+ }
+ outw(RxQueued, ioaddr + COMMAND);
+ }
if (status & PCIBusErr170) {
printk(KERN_ERR "%s: PCI Bus Error! EPIC status %4.4x.\n",
dev->name, status);
> Another question I have is about the different driver versions that
> are around.
> Till Harbaum <[email protected]> just sent
> me a driver which is directly from SMC:
[...]
> and "copying" is the GPL. It seems to be a not yet released extension of the
> driver
> available from http://www.smc.de/sites/support/download/PCI/9432/LINUX/src9432lu.zip.
> Some changelog reads " 03/13/2001 Ling Yue for linux kernel 2.4".
>
> Is there communication between SMC and your group?
This is a question for more knowledgable persons than me (TM).
So far, the headers don't look terribly GPLish.
--
Ueimor
On Friday 20 April 2001 18:45, Francois Romieu wrote:
> I assume nothing is overclocked or whatever
Nothing is overclocked.
> Could you try this patch (more output during the loop):
Tried it. The (lengthy) log is attached.
The interrupt is triggered when the other side initiates a request.
eth0 is connected to one another computer by a cross-wired cable,
just in case this makes any difference.
Cheers,
Stefan
--
Stefan R. Jaschke <[email protected]>
http://www.jaschke-net.de