I'm seeing problems running a 2.6.7-mm1 kernel with Fedora Core 2
running in a VMWare Workstation 4.5.2 VM. The kernel hangs trying to
bring up the (dhcp-enabled) eth0 interface.
I dug through the -mm1 patch, and the problem seems to be the changes at
the end of the pcnet32_interrupt() function (in drivers/net/pcnet32.c).
The relevant patch fragment is:
- /* Clear any other interrupt, and set interrupt enable. */
- lp->a.write_csr (ioaddr, 0, 0x7940);
+ /* Set interrupt enable. */
+ lp->a.write_csr (ioaddr, 0, 0x0040);
Reverting this one section of the patch makes eth0 happy again.
I poked around with the values written to the csr register, and it
appears the virtual PCNet-II adapter needs bit 0x0100 (initialzation
done) set. So, writing 0x0140 instead of 0x0040 seems to work well.
I have no idea how accurate VMWare's emulation of this adapter is, or if
this change may cause problems with other (physical) adapters.
KM
Aren't bits 31-16 of CSR0 reserved on PCnet-II (79c970A) ?
>From 79c970A Datasheet page 108:
CSR0:
[SNIP] The register is designed so that these indicator bits are cleared
by writing ONESs to those bit locations. This means that the software
can read CSR0 and write back the value just read to clear the interrupt
condition. [SNIP]
bits 31-16 Rserved. Written as ZEROs and read as undefined.
[SNIP]
bit 6 is IENA Interrupt Enable.
Thanks.
On Wed, 2004-06-23 at 11:23, Keith Moore wrote:
> I'm seeing problems running a 2.6.7-mm1 kernel with Fedora Core 2
> running in a VMWare Workstation 4.5.2 VM. The kernel hangs trying to
> bring up the (dhcp-enabled) eth0 interface.
>
> I dug through the -mm1 patch, and the problem seems to be the changes at
> the end of the pcnet32_interrupt() function (in drivers/net/pcnet32.c).
> The relevant patch fragment is:
>
> - /* Clear any other interrupt, and set interrupt enable. */
> - lp->a.write_csr (ioaddr, 0, 0x7940);
> + /* Set interrupt enable. */
> + lp->a.write_csr (ioaddr, 0, 0x0040);
>
> Reverting this one section of the patch makes eth0 happy again.
>
> I poked around with the values written to the csr register, and it
> appears the virtual PCNet-II adapter needs bit 0x0100 (initialzation
> done) set. So, writing 0x0140 instead of 0x0040 seems to work well.
>
> I have no idea how accurate VMWare's emulation of this adapter is, or if
> this change may cause problems with other (physical) adapters.
>
>
> KM
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 23 Jun 04 at 11:23, Keith Moore wrote:
> - /* Clear any other interrupt, and set interrupt enable. */
> - lp->a.write_csr (ioaddr, 0, 0x7940);
> + /* Set interrupt enable. */
> + lp->a.write_csr (ioaddr, 0, 0x0040);
>
> Reverting this one section of the patch makes eth0 happy again.
>
> I poked around with the values written to the csr register, and it
> appears the virtual PCNet-II adapter needs bit 0x0100 (initialzation
> done) set. So, writing 0x0140 instead of 0x0040 seems to work well.
>
> I have no idea how accurate VMWare's emulation of this adapter is, or if
> this change may cause problems with other (physical) adapters.
I believe that it is not emulation bug. What happens is that you do not
confirm INIT DONE irq, causing endless stream of interrupts from card to
the CPU. This happens because CSR3 default value is 0 (enable all
interrupts), and driver does not modify it in any way (f.e. for
preventing INIT from causing interrupt). So when init is done, IDON
irq fires. In old driver it was acked by 0x7940 (or by 0x0140 in your
modified driver), but in new driver it is not acked in any way,
triggering this very same IRQ over and over.
pcnet32_interrupt should loop while csr0 contains some pending
interrupts (current mask 0x8600 should be changed to 0xDE00 to be 100%
sure that all interrupts we handle in loop are catched), and then
clear all other interrupts sources (0x2140) out of the loop.
Other possibility is masking these unused sources in CSR3...
But I believe that driver from -mm1 will hang even on real Am79C970A
hardware.
Best regards,
Petr Vandrovec