|
Hello Jeremy,
> I just found if I turn off hardware checksums, ie:
> /sbin/modprobe e100 XsumRX=0,0
>
> LVS works with the latest intel e100 drivers.
>
> Now we just need to figure out why LVS doesn't work with Intel's hardware
> checksumming.
I have a hard time believing that LVS has anything to do with a NIC driver's
functionality. The LVS code is adjacent to the NIC driver. If you can disable
LVS and show that then the driver works, we certainly must fix LVS. But as
long as this is not the case, don't bring LVS in conjunction with non-working
NIC drivers.
> My director has 2 Intel eepro100 nic cards. I wasn't using the default
> ee100pro driver that came with kernel 2.4.7, instead I was using the latest
> (at the time I downloaded it) driver from intel for that NIC, e100-1.6.6 due
> to an earlier bug in the eepro100 driver causing unrelated NFS problems.
Take the newest 2.4.x kernel if possible. But actually the driver didn't
change there, so the problem must be somewhere else.
> After going back to the default eepro100 driver, my problem went away.
Aha, I suspect you have some IRQ routing problem, can you provide me with
more information about your board and CPU, please?
> I just tried upgrading to Intel's now latest e100 driver (e100-1.6.13) to no
> avail. Looks like I'm stuck using the default eepro100 driver suppied with
> the kernel to make LVS on 2.4.7 work.
Strange.
> This problem is for both LVS-0.8.1 and LVS-0.9.3.
No, unless you prove that without LVS code compiled and/or loaded into the
kernel the driver works flawlessly.
In the meantime check out the eepro100.c code:
MODULE_AUTHOR("Maintainer: Andrey V. Savochkin <saw@xxxxxxxxxxxxx>");
MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver");
MODULE_PARM(debug, "i");
MODULE_PARM(options, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(full_duplex, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(congenb, "i");
MODULE_PARM(txfifo, "i");
MODULE_PARM(rxfifo, "i");
MODULE_PARM(txdmacount, "i");
MODULE_PARM(rxdmacount, "i");
MODULE_PARM(rx_copybreak, "i");
MODULE_PARM(max_interrupt_work, "i");
MODULE_PARM(multicast_filter_limit, "i");
MODULE_PARM_DESC(debug, "eepro100 debug level (0-6)");
MODULE_PARM_DESC(options, "eepro100: Bits 0-3: tranceiver type, bit 4: full
duplex, bit 5: 100Mbps");
MODULE_PARM_DESC(full_duplex, "eepro100 full duplex setting(s) (1)");
MODULE_PARM_DESC(congenb, "eepro100 Enable congestion control (1)");
MODULE_PARM_DESC(txfifo, "eepro100 Tx FIFO threshold in 4 byte units, (0-15)");
MODULE_PARM_DESC(rxfifo, "eepro100 Rx FIFO threshold in 4 byte units, (0-15)");
MODULE_PARM_DESC(txdmaccount, "eepro100 Tx DMA burst length; 128 - disable
(0-128)");
MODULE_PARM_DESC(rxdmaccount, "eepro100 Rx DMA burst length; 128 - disable
(0-128)");
MODULE_PARM_DESC(rx_copybreak, "eepro100 copy breakpoint for
copy-only-tiny-frames");
MODULE_PARM_DESC(max_interrupt_work, "eepro100 maximum events handled per
interrupt");
MODULE_PARM_DESC(multicast_filter_limit, "eepro100 maximum number of filtered
multicast addresses");
Play with the txdmaccount, rxdmaccount and rx_copybreak values, enabled debug=6
watch for errors or interrupt related stuff. Check your /proc/interrups, disable
APIC if you enabled it and certainly disable PM.
Read [1], [2] and get the source from [3] and report, please.
[1]: http://www.scyld.com/network/eepro100.html
[2]: http://www.scyld.com/expert/irq-conflict.html
[3]: ftp://ftp.scyld.com/pub/network/eepro100.c
Best regards,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
