I've added support for generic MII and ethtool to a driver that has
been working reliably for a year. If I allow ethtool_ops to be set
when the driver initializes, the kernel will fault at an apparently
random location just after IP autoconfiguration. The fault is
generally a variation on
IP-Config: Complete:
device=eth0, addr=192.168.8.203, mask=255.255.255.0, gw=255.255.255.255,
host=192.168.8.203, domain=, nis-domain=(none),
bootserver=192.168.8.1, rootserver=192.168.8.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.8.1
Looking up port of RPC 100005/1 on 192.168.8.1
Unable to handle kernel NULL pointer dereference at virtual address 00000434
pgd = c0004000
[00000434] *pgd=00000000
which I interpret as a random memory stomp.
By inserting debug print statements into the ethtool entry points as
well as the mdio_read and mdio_write calls, it looks as if the only
new code being called while ethtool_ops are defined is a couple of
mdio reads. Protecting these routines and their associated data with
spin_lock_irqsave() doesn't fix it, nor does adding SA_INTERRUPT to
the softirq handlers. Moreover, the random-ness of the fault suggests
something more serious as these calls shouldn't need synchronization.
So, the question is this: where ought I look in the net code for the
code-path differences when ethtool_ops is defined?
Cheers.
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
