sk0 driver problem and (with luck) approach to a fix

Chris Landauer cal at rush.aero.org
Sat Jan 8 23:46:00 PST 2005



hihi, all -

i have a specific problem with a network interface, and i'm wondering what is
the right venue for my question

i have recently bought two new intel pentium 4 pcs (with hyperthreading, so
that the SMP kernel works on them) and installed 5.3-RELEASE on them both, and
the gigabit ethernet interfaces that came with the machines do not work (fast
ethernet pci cards that i installed do work) - they both are:

	Marvell Yukon 88E8050 PCI Express Gigabit Ethernet Adapter
	(at least that is what i assume PCIe means)

relevant output from pciconf -l -v:

skc0 at pci3:0:0:  class=0x020000 card=0x3032107b chip=0x436111ab rev=0x17 hdr=0x00
    vendor   = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    class    = network
    subclass = ethernet

relevant output from dmesg:

skc0: <Marvell Gigabit Ethernet> port 0x2000-0x20ff mem 0xc8100000-0xc8103fff irq 17 at device 0.0 on pci3
skc0: unknown device!
device_attach: skc0 attach returned 6

i snooped through some mailing lists about drivers (much thanx to zabbadoz)
and read the code a few times and here is what i think is the problem:

	the chip ID (0x4361 above, the first half of "chip=") is not in the
	array sk_devs[] (though two other, presumably older, Marvell IDs are,
	and my two belkin gigabit ethernet pci cards, with the same sk driver,
	have codes that are in the array and do both work)

i tried just adding the appropriate entry to the array, but that didn't work
(i think i know why now - see below)

i was pleasantly surprised to see a timely message on freebsd-annnounce
(Subject "FreeBSD 5.3-RELEASE Errata Notice: FreeBSD-EN-05:02.sk") discussing
a number of changes that were needed in the sk driver to fix other known
problems, and eagerly looked at the new source code

but the new ID is still not there

i am in the process of upgrading from 5.3-RELEASE to 5.3-STABLE, which will
take some time (this is the first time i've tried to use a -STABLE branch,
though I've been using freebsd from CDs since 2.1.5-RELEASE), and then i will
make the same array addition and try that - what else should i be trying (to
make my results most useful to the community)?

i now see (in lines 1537-1554 of file if_sk.c v.1.83.2.2) that i missed one
other place to add the new id (which like many things is quite obvious in
retrospect): the switch in which the driver compares what it gets from the
device to the array entries (that is also where it prints the "unknown
device!" shown above, when it doesn't find the one it is looking for) - so i
will try that (an dlook for other instances of the #define'd ID codes) and see
if it works - if so, where should i distribute the results?

it seems that the switch could be changed into a loop through the defined
array entries, rendering its code independent of the specific array contents
(and making the array the ONLY place new IDs need to go, unless there is
changed functionality) - what considerations made that impractical (was it
just the amount of time a loop takes? or what else?)?

more soon,
cal

Dr. Christopher Landauer
Aerospace Integration Science Center
The Aerospace Corporation, Mail Stop M6/214
P.O.Box 92957
Los Angeles, California 90009-2957, USA
cal at aero.org
+1 (310) 336-1361



More information about the freebsd-questions mailing list