Bug#590582: abot vortex problem

2012-03-24 Thread Karol Szkudlarek

W dniu 19.03.2012 07:41, Jonathan Nieder pisze:

Hi Karol,

Karol Szkudlarek wrote:


No..., I'm not tried 3.x kernel from sid or experimental becuase
problem considers my home router/server which is need 24h/day...

But I could try for example backported patched a module driver 3c95x
for my 2.6.32 current debian squeeze version. For me it will be safe
solution which I can easily revert.


Ok, makes sense.

I've attached a patch to try, following instructions from [1].  The
result should be ABI-compatible with a squeeze kernel, so if all goes
well and you have kept a copy of the unpatched 3c95x driver, you can
unload the patched 3c95x driver and reload the standard one after
testing.  (Of course, it is always possible that testing could go
poorly and e.g. hang the system.)

Hope that helps,
Jonathan

[1] 
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
or the corresponding page in the debian-kernel-handbook package

Jonathan,

I've succesfully applied patch and reinstall module as you suggest me in 
previous e-mail (thanks for help in module reinstalling!)


{
   rmmod 3c59x; insmod 
/usr/src/linux-source-2.6.32/drivers/net/3c59x.ko; insmod 
/lib/modules/2.6.32-5-686/kernel/drivers/net/3c59x.ko

  ifdown eth0;ifup eth0;ifdown eth2;ifup eth2
} 

and I have to add ifdown/ifup for my network interfaces after it.

I've tested patched driver, but unfortunately it contains the same bug,
copying large file via eth0 stills breaks eth0 communication... :-(

Of course I've checked via lsmod different size of memory of patched
and original driver to be sure that I've loaded patched driver instead 
of original.


Regards,
Karol



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#590582: abot vortex problem

2012-03-19 Thread Jonathan Nieder
Hi Karol,

Karol Szkudlarek wrote:

 No..., I'm not tried 3.x kernel from sid or experimental becuase
 problem considers my home router/server which is need 24h/day...

 But I could try for example backported patched a module driver 3c95x
 for my 2.6.32 current debian squeeze version. For me it will be safe
 solution which I can easily revert.

Ok, makes sense.

I've attached a patch to try, following instructions from [1].  The
result should be ABI-compatible with a squeeze kernel, so if all goes
well and you have kept a copy of the unpatched 3c95x driver, you can
unload the patched 3c95x driver and reload the standard one after
testing.  (Of course, it is always possible that testing could go
poorly and e.g. hang the system.)

Hope that helps,
Jonathan

[1] 
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
or the corresponding page in the debian-kernel-handbook package
From: Jonathan Nieder jrnie...@gmail.com
Date: Mon, 19 Mar 2012 01:31:49 -0500
Subject: debugging patch for bug#590582

This patch basically updates the 3c59x driver in squeeze to the
version in the longterm 3.0.y tree.  Some commits making cosmetic
changes have been skipped to make the changes more minimal and
therefore easier to understand.
---
 drivers/net/3c59x.c |   84 +++
 1 file changed, 71 insertions(+), 13 deletions(-)

diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 447b04a43c89..534f287f7e7b 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -633,7 +633,11 @@ struct vortex_private {
open:1,
medialock:1,
must_free_region:1, /* Flag: if 
zero, Cardbus owns the I/O region */
-   large_frames:1; /* accept large frames */
+   large_frames:1, /* accept large frames */
+   handling_irq:1; /* private in_irq indicator */
+   /* {get|set}_wol operations are already serialized by rtnl.
+* no additional locking is required for the enable_wol and 
acpi_set_WOL()
+*/
int drv_flags;
u16 status_enable;
u16 intr_enable;
@@ -695,7 +699,8 @@ DEFINE_WINDOW_IO(32)
 #define DEVICE_PCI(dev) NULL
 #endif
 
-#define VORTEX_PCI(vp) (((vp)-gendev) ? DEVICE_PCI((vp)-gendev) : NULL)
+#define VORTEX_PCI(vp) \
+   ((struct pci_dev *) (((vp)-gendev) ? DEVICE_PCI((vp)-gendev) : NULL))
 
 #ifdef CONFIG_EISA
 #define DEVICE_EISA(dev) (((dev)-bus == eisa_bus_type) ? 
to_eisa_device((dev)) : NULL)
@@ -703,7 +708,8 @@ DEFINE_WINDOW_IO(32)
 #define DEVICE_EISA(dev) NULL
 #endif
 
-#define VORTEX_EISA(vp) (((vp)-gendev) ? DEVICE_EISA((vp)-gendev) : NULL)
+#define VORTEX_EISA(vp)
\
+   ((struct eisa_device *) (((vp)-gendev) ? DEVICE_EISA((vp)-gendev) : 
NULL))
 
 /* The action to take with a media selection timer tick.
Note that we deviate from the 3Com order by checking 10base2 before AUI.
@@ -1020,10 +1026,16 @@ static int __devinit vortex_init_one(struct pci_dev 
*pdev,
ioaddr = pci_iomap(pdev, pci_bar, 0);
if (!ioaddr) /* If mapping fails, fall-back to BAR 0... */
ioaddr = pci_iomap(pdev, 0, 0);
+   if (!ioaddr) {
+   pci_disable_device(pdev);
+   rc = -ENOMEM;
+   goto out;
+   }
 
rc = vortex_probe1(pdev-dev, ioaddr, pdev-irq,
   ent-driver_data, unit);
if (rc  0) {
+   pci_iounmap(pdev, ioaddr);
pci_disable_device(pdev);
goto out;
}
@@ -1830,7 +1842,7 @@ vortex_timer(unsigned long data)
ok = 1;
}
 
-   if (!netif_carrier_ok(dev))
+   if (dev-flags  IFF_SLAVE || !netif_carrier_ok(dev))
next_tick = 5*HZ;
 
if (vp-medialock)
@@ -1881,7 +1893,6 @@ leave_media_alone:
mod_timer(vp-timer, RUN_AT(next_tick));
if (vp-deferred)
iowrite16(FakeIntr, ioaddr + EL3_CMD);
-   return;
 }
 
 static void vortex_tx_timeout(struct net_device *dev)
@@ -1942,7 +1953,7 @@ static void vortex_tx_timeout(struct net_device *dev)
 
/* Issue Tx Enable */
iowrite16(TxEnable, ioaddr + EL3_CMD);
-   dev-trans_start = jiffies;
+   dev-trans_start = jiffies; /* prevent tx timeout */
 }
 
 /*
@@ -2087,7 +2098,6 @@ vortex_start_xmit(struct sk_buff *skb, struct net_device 
*dev)
}
}
 
-   dev-trans_start = jiffies;
 
/* Clear the Tx status stack. */
{
@@ -2128,6 +2138,15 @@ boomerang_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
   dev-name, vp-cur_tx);
}
 
+   /*
+* We can't allow a recursion from our interrupt handler back into the
+* tx routine, as they take the same spin lock, and that causes
+   

Bug#590582: abot vortex problem

2012-01-06 Thread Karol Szkudlarek

Hello,

No..., I'm not tried 3.x kernel from sid or experimental becuase problem 
considers my home router/server which is need 24h/day...


But I could try for example backported patched a module driver 3c95x for 
my 2.6.32 current debian squeeze version. For me it will be safe 
solution which I can easily revert.
As I wrote before problem is easy to reproduce if you try copying 
(through scp, wire connection or wireless connection where access point 
is connected to 3c95x port) a file from one PC to server which contains 
3c95x network card. After copying for example 200/600MB/1GB (its not a 
constant amount) copying stalled and network interface on destination 
doesn't responding (ping,telnet)


I hope it helps a little,
Regards,

--
Karol Szkudlarek



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org