tulip driver: errors instead TX packets?

tulip driver: errors instead TX packets?

[Piotr Kaczuba]

I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip driver  
on 2.6.1. I wonder if anyone has noticed that ifconfig shows the  
packets sent in the errors field instead of the TX packets field. At  
least, this is what I assume because it shows 0 TX packets and 11756  
errors.

Here's the ifconfig output for eth0, which is used for PPPoE:

eth0      Link encap:Ethernet  HWaddr 00:04:75:B1:E0:77
          inet6 addr: fe80::204:75ff:feb1:e077/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9130 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:11756 dropped:0 overruns:0 carrier:23473
          collisions:0 txqueuelen:1000
          RX bytes:1723335 (1.6 MiB)  TX bytes:0 (0.0 b)
          Interrupt:10 Base address:0x5000

I had the same behaviour with 2.4 and the tulip driver from scyld.

This is what tulip-diag reports:

tulip-diag.c:v2.18 11/12/2003 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3Com 3cSOHO100B-TX (ADMtek Centaur) adapter at  
0xd000.
 Comet duplex is reported in the MII status registers.
 Transmit started, Receive started.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Idle'.
  The transmit threshold is 128.
  Comet MAC address registers b1750400 ffff77e0
  Comet multicast filter 8000000040001000.
 Use '-a' or '-aa' to show device registers,
     '-e' to show EEPROM contents, -ee for parsed contents,
  or '-m' or '-mm' to show MII management registers.

Is it okay for the TX process to be in idle state although there  
definitly is outgoing traffic?

Please CC any replies to me as I'am not subscribed.

Piotr Kaczuba

Re: tulip driver: errors instead TX packets?

[Jeff Garzik]

Piotr Kaczuba wrote:
> I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip driver  
> on 2.6.1. I wonder if anyone has noticed that ifconfig shows the  
> packets sent in the errors field instead of the TX packets field. At  
> least, this is what I assume because it shows 0 TX packets and 11756  
> errors.


This is an old error, but since packets show up, nobody bothers with the 
incorrect statistics...

	Jeff

Re: tulip driver: errors instead TX packets?

[Piotr Kaczuba]

Jeff Garzik wrote:
> Piotr Kaczuba wrote:
> 
>> I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip 
>> driver  on 2.6.1. I wonder if anyone has noticed that ifconfig shows 
>> the  packets sent in the errors field instead of the TX packets field. 
>> At  least, this is what I assume because it shows 0 TX packets and 
>> 11756  errors.
> 
> This is an old error, but since packets show up, nobody bothers with the 
> incorrect statistics...

It seems that the error lies in the following piece of code from 
drivers/net/tulip/interrupt.c, function tulip_interrupt. I've inserted 
an additional printk after the "if (status & 0x8000)" and it looks like 
normal operation of the nic is considered as an major error by the 
driver because my printk appeared in dmesg output right after bringing 
the interface up. I assume that the else branch is never executed 
although I didn't test what happens if an transmit error really happens. 
I wonder if a fix for this problem consists of just changing the value 
of the AND mask but I have no idea what the right value would be.


   if (status & 0x8000) {
           /* There was an major error, log it. */
#ifndef final_version
           if (tulip_debug > 1)
              printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
                        dev->name, status);
#endif
           tp->stats.tx_errors++;
           if (status & 0x4104) tp->stats.tx_aborted_errors++;
           if (status & 0x0C00) tp->stats.tx_carrier_errors++;
           if (status & 0x0200) tp->stats.tx_window_errors++;
           if (status & 0x0002) tp->stats.tx_fifo_errors++;
           if ((status & 0x0080) && tp->full_duplex == 0)
                   tp->stats.tx_heartbeat_errors++;
   } else {
           tp->stats.tx_bytes +=
                   tp->tx_buffers[entry].skb->len;
           tp->stats.collisions += (status >> 3) & 15;
           tp->stats.tx_packets++;
   }


Piotr Kaczuba

Re: tulip driver: errors instead TX packets?

[Adam Kropelin]

On Sat, Jan 10, 2004 at 09:28:45PM +0100, Piotr Kaczuba wrote:
> Jeff Garzik wrote:
> > Piotr Kaczuba wrote:
> > 
> >> I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip 
> >> driver  on 2.6.1. I wonder if anyone has noticed that ifconfig shows 
> >> the  packets sent in the errors field instead of the TX packets field. 
> >> At  least, this is what I assume because it shows 0 TX packets and 
> >> 11756  errors.
> > 
> > This is an old error, but since packets show up, nobody bothers with the 
> > incorrect statistics...
> 
> It seems that the error lies in the following piece of code from 
> drivers/net/tulip/interrupt.c, function tulip_interrupt. I've inserted 
> an additional printk after the "if (status & 0x8000)" and it looks like 
> normal operation of the nic is considered as an major error by the 
> driver because my printk appeared in dmesg output right after bringing 
> the interface up. I assume that the else branch is never executed 
> although I didn't test what happens if an transmit error really happens. 
> I wonder if a fix for this problem consists of just changing the value 
> of the AND mask but I have no idea what the right value would be.
> 
> 
>    if (status & 0x8000) {

According to my PNIC docs (don't have true Tulip docs handy), this bit
is the logical OR of all the Tx error bits, so it appears a true tx
error has ocurred.

>            /* There was an major error, log it. */
> #ifndef final_version
>            if (tulip_debug > 1)
>               printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
>                         dev->name, status);
> #endif

Enabling this printk and setting tulip_debug appropriately would tell us
what tx error you're experiencing.

>            tp->stats.tx_errors++;
>            if (status & 0x4104) tp->stats.tx_aborted_errors++;
>            if (status & 0x0C00) tp->stats.tx_carrier_errors++;
>            if (status & 0x0200) tp->stats.tx_window_errors++;
>            if (status & 0x0002) tp->stats.tx_fifo_errors++;
>            if ((status & 0x0080) && tp->full_duplex == 0)
>                    tp->stats.tx_heartbeat_errors++;

And this code bumps error counters based on the specific error that
ocurred.  It all seems perfectly sane to me. The actual problem lies
elsewhere, I think.

--Adam

Re: tulip driver: errors instead TX packets?

[Piotr Kaczuba]

Adam Kropelin wrote:
> On Sat, Jan 10, 2004 at 09:28:45PM +0100, Piotr Kaczuba wrote:
> 
>>Jeff Garzik wrote:
>>
>>>Piotr Kaczuba wrote:
>>>
>>>
>>>>I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip 
>>>>driver  on 2.6.1. I wonder if anyone has noticed that ifconfig shows 
>>>>the  packets sent in the errors field instead of the TX packets field. 
>>>>At  least, this is what I assume because it shows 0 TX packets and 
>>>>11756  errors.
>>>
>>>This is an old error, but since packets show up, nobody bothers with the 
>>>incorrect statistics...
>>
>>It seems that the error lies in the following piece of code from 
>>drivers/net/tulip/interrupt.c, function tulip_interrupt. I've inserted 
>>an additional printk after the "if (status & 0x8000)" and it looks like 
>>normal operation of the nic is considered as an major error by the 
>>driver because my printk appeared in dmesg output right after bringing 
>>the interface up. I assume that the else branch is never executed 
>>although I didn't test what happens if an transmit error really happens. 
>>I wonder if a fix for this problem consists of just changing the value 
>>of the AND mask but I have no idea what the right value would be.
>>
>>
>>   if (status & 0x8000) {
> 
> 
> According to my PNIC docs (don't have true Tulip docs handy), this bit
> is the logical OR of all the Tx error bits, so it appears a true tx
> error has ocurred.
> 
> 
>>           /* There was an major error, log it. */
>>#ifndef final_version
>>           if (tulip_debug > 1)
>>              printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
>>                        dev->name, status);
>>#endif
> 
> 
> Enabling this printk and setting tulip_debug appropriately would tell us
> what tx error you're experiencing.
> 
> 
>>           tp->stats.tx_errors++;
>>           if (status & 0x4104) tp->stats.tx_aborted_errors++;
>>           if (status & 0x0C00) tp->stats.tx_carrier_errors++;
>>           if (status & 0x0200) tp->stats.tx_window_errors++;
>>           if (status & 0x0002) tp->stats.tx_fifo_errors++;
>>           if ((status & 0x0080) && tp->full_duplex == 0)
>>                   tp->stats.tx_heartbeat_errors++;
> 
> 
> And this code bumps error counters based on the specific error that
> ocurred.  It all seems perfectly sane to me. The actual problem lies
> elsewhere, I think.

Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting 
pppd (eth0 is used by PPPoE). I agree that the code looks okay but 
somehow every packet sent is considered to be an error although I don't 
experience any problems in everday network traffic.

Linux Tulip driver version 1.1.13 (May 11, 2002)
eth0: ADMtek Comet rev 49 at 0xe1fc5000, 00:04:75:B1:E0:77, IRQ 10.
eth0: tulip_up(), irq==10.
eth0: Done tulip_up(), CSR0 fff98000, CSR5 fc664010 CSR6 ff972113.
eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
eth0: Added filter for 33:33:ff:b1:e0:77  35362b05 bit 44.
eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
eth0: Added filter for 33:33:ff:b1:e0:77  35362b05 bit 44.
eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: no IPv6 routers present
eth0: Added filter for 33:33:ff:b1:e0:77  35362b05 bit 44.
eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.

(output truncated)


Piotr Kaczuba

Re: tulip driver: errors instead TX packets?

[Adam Kropelin]

On Sun, Jan 11, 2004 at 01:16:03PM +0100, Piotr Kaczuba wrote:
>
> Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting 
> pppd (eth0 is used by PPPoE). I agree that the code looks okay but 

<snip>

> eth0: Transmit error, Tx status 1a078c80.

That would be heartbeat failure, no carrier, and loss of carrier. It's
interesting that you seem to be able to get valid packets on the wire
because the latter two errors are usually quite fatal. I suspect either
the Comet is just buggy and those error bits aren't to be trusted or
there is something wrong with the PHY config. I don't have docs on the
Comet PHY so there's not much I can do.

On whim, does the patch below change anything for you?

--Adam


--- linux-2.6.1/drivers/net/tulip/tulip_core.c.orig	Sun Jan 11 12:06:34 2004
+++ linux-2.6.1/drivers/net/tulip/tulip_core.c	Sun Jan 11 12:09:13 2004
@@ -438,7 +438,7 @@
 		/* Enable automatic Tx underrun recovery. */
 		outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
 		dev->if_port = tp->mii_cnt ? 11 : 0;
-		tp->csr6 = 0x00040000;
+		tp->csr6 = 0x000C0000;
 	} else if (tp->chip_id == AX88140) {
 		tp->csr6 = tp->mii_cnt ? 0x00040100 : 0x00000100;
 	} else

Re: tulip driver: errors instead TX packets?

[Piotr Kaczuba]

Adam Kropelin wrote:
> On Sun, Jan 11, 2004 at 01:16:03PM +0100, Piotr Kaczuba wrote:
> 
>>Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting 
>>pppd (eth0 is used by PPPoE). I agree that the code looks okay but 
> 
> 
> <snip>
> 
>>eth0: Transmit error, Tx status 1a078c80.
> 
> 
> That would be heartbeat failure, no carrier, and loss of carrier. It's
> interesting that you seem to be able to get valid packets on the wire
> because the latter two errors are usually quite fatal. I suspect either
> the Comet is just buggy and those error bits aren't to be trusted or
> there is something wrong with the PHY config. I don't have docs on the
> Comet PHY so there's not much I can do.
> 
> On whim, does the patch below change anything for you?
> 
> --Adam
> 
> 
> --- linux-2.6.1/drivers/net/tulip/tulip_core.c.orig	Sun Jan 11 12:06:34 2004
> +++ linux-2.6.1/drivers/net/tulip/tulip_core.c	Sun Jan 11 12:09:13 2004
> @@ -438,7 +438,7 @@
>  		/* Enable automatic Tx underrun recovery. */
>  		outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
>  		dev->if_port = tp->mii_cnt ? 11 : 0;
> -		tp->csr6 = 0x00040000;
> +		tp->csr6 = 0x000C0000;
>  	} else if (tp->chip_id == AX88140) {
>  		tp->csr6 = tp->mii_cnt ? 0x00040100 : 0x00000100;
>  	} else
> 

Unfortunately, not. The errors are still there, but the status code has 
changed. Below is an excerpt from kern.log after applying the patch.

> Jan 12 21:34:57 orbiter kernel: Linux Tulip driver version 1.1.13 (May 11, 2002)
> Jan 12 21:34:57 orbiter kernel: eth0: ADMtek Comet rev 49 at 0xe1fea000, 00:04:75:B1:E0:77, IRQ 10.
> Jan 12 21:35:09 orbiter kernel: eth0: tulip_up(), irq==10.
> Jan 12 21:35:09 orbiter kernel: eth0: Done tulip_up(), CSR0 fff98000, CSR5 fc664010 CSR6 ff9f2113.
> Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
> Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:ff:b1:e0:77  35362b05 bit 44.
> Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
> Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:ff:b1:e0:77  35362b05 bit 44.
> Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
> Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:10 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:10 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:12 orbiter kernel: eth0: Comet link status 0000 partner capability 0000.
> Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 2a0b8c00.
> Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 2a0b8c00.
> Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 2a0b8c00.
> Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:14 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:15 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:18 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:18 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:18 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:19 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:19 orbiter kernel: eth0: no IPv6 routers present
> Jan 12 21:35:20 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:20 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:21 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
> Jan 12 21:35:32 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.


Piotr Kaczuba

Re: tulip driver: errors instead TX packets?

[Adam Kropelin]

On Mon, Jan 12, 2004 at 11:10:04PM +0100, Piotr Kaczuba wrote:
> Adam Kropelin wrote:
> > On Sun, Jan 11, 2004 at 01:16:03PM +0100, Piotr Kaczuba wrote:
> > 
> >>Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting 
> >>pppd (eth0 is used by PPPoE). I agree that the code looks okay but 
> > 
> > <snip>
> > 
> >>eth0: Transmit error, Tx status 1a078c80.
> > 
> > 
> > That would be heartbeat failure, no carrier, and loss of carrier. It's
> > interesting that you seem to be able to get valid packets on the wire
> > because the latter two errors are usually quite fatal. I suspect either
> > the Comet is just buggy and those error bits aren't to be trusted or
> > there is something wrong with the PHY config. I don't have docs on the
> > Comet PHY so there's not much I can do.
> > 
> > On whim, does the patch below change anything for you?

<snip patch that disables SQE test>

> Unfortunately, not. The errors are still there, but the status code has 
> changed. Below is an excerpt from kern.log after applying the patch.

<snip>

> Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.

Yep...we told it to disable the SQE test so the heartbeat error no
longer appears. The carrier errors are still present, though. This
definitely smells like a configuration problem, but without docs and a
card to test with there's not much else I can do. I'll poke thru the
code and see if anything else leaps out at me.  If anybody out there
has Comet docs or a NIC that exhibits this problem they'd be willing to
loan I'll take a deeper look.

--Adam

Re: tulip driver: errors instead TX packets?

[Piotr Kaczuba]

Dnia 2004-01-13 06:09:55, Adam Kropelin napisał(a):
> I'll poke thru the
> code and see if anything else leaps out at me.  If anybody out there
> has Comet docs or a NIC that exhibits this problem they'd be willing
> to
> loan I'll take a deeper look.

If you come up with any patches, I'd love to test them, so feel free to  
send me any diffs.

Piotr Kaczuba