On 12/13/06, Chris Buechler <[EMAIL PROTECTED]> wrote:
Jack Vogel wrote:
> I need the PCI ID of that NIC, just to be sure that I can't reproduce
> this, but
> I doubt it, pciconf -l
Here's the pciconf -l from 6.2-RC1, custom kernel (copy of GENERIC,
minus 'device em')
[EMAIL PROTECTED]:0:0: class=0x060000 card=0x00000000 chip=0x700c1022 rev=0x20
hdr=0x00
[EMAIL PROTECTED]:1:0: class=0x060400 card=0x00000000 chip=0x700d1022 rev=0x00
hdr=0x01
[EMAIL PROTECTED]:7:0: class=0x060100 card=0x00000000 chip=0x74401022 rev=0x05
hdr=0x00
[EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022
rev=0x04 hdr=0x00
[EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03
hdr=0x00
[EMAIL PROTECTED]:8:0: class=0x030000 card=0x00000000 chip=0x47581002 rev=0x01
hdr=0x00
[EMAIL PROTECTED]:9:0: class=0x020000 card=0x002e8086 chip=0x100e8086 rev=0x02
hdr=0x00
[EMAIL PROTECTED]:10:0: class=0x0e0001 card=0xc0661044 chip=0xa5011044 rev=0x01
hdr=0x00
[EMAIL PROTECTED]:10:1: class=0x060400 card=0x00000068 chip=0xa5001044
rev=0x01 hdr=0x01
[EMAIL PROTECTED]:16:0: class=0x060400 card=0x00000000 chip=0x74481022
rev=0x05 hdr=0x01
[EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x00000000 chip=0x74491022 rev=0x07
hdr=0x00
[EMAIL PROTECTED]:8:0: class=0x020000 card=0x246610f1 chip=0x920010b7 rev=0x78
hdr=0x00
> interesting question is what will happen when you load
> the em driver afterwords :)
Indeed, I was expecting Bad Things to happen. But no, after the
kldload, the interface was detected, I put an IP on it and it's working
fine. I bound an iperf server to that interface and ran an iperf client
from a slower box with a gig card and got ~520 Mbps out of it (probably
limited by the slower client box). So it seems to be working fine as
long as it's not compiled into the kernel. Granted I haven't done any
really extensive testing or use of it.
Here's the pciconf -l after loading the em driver.
[EMAIL PROTECTED]:0:0: class=0x060000 card=0x00000000 chip=0x700c1022 rev=0x20
hdr=0x00
[EMAIL PROTECTED]:1:0: class=0x060400 card=0x00000000 chip=0x700d1022 rev=0x00
hdr=0x01
[EMAIL PROTECTED]:7:0: class=0x060100 card=0x00000000 chip=0x74401022 rev=0x05
hdr=0x00
[EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022
rev=0x04 hdr=0x00
[EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03
hdr=0x00
[EMAIL PROTECTED]:8:0: class=0x030000 card=0x00000000 chip=0x47581002 rev=0x01
hdr=0x00
[EMAIL PROTECTED]:9:0: class=0x020000 card=0x002e8086 chip=0x100e8086 rev=0x02
hdr=0x00
[EMAIL PROTECTED]:10:0: class=0x0e0001 card=0xc0661044 chip=0xa5011044 rev=0x01
hdr=0x00
[EMAIL PROTECTED]:10:1: class=0x060400 card=0x00000068 chip=0xa5001044
rev=0x01 hdr=0x01
[EMAIL PROTECTED]:16:0: class=0x060400 card=0x00000000 chip=0x74481022
rev=0x05 hdr=0x01
[EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x00000000 chip=0x74491022 rev=0x07
hdr=0x00
[EMAIL PROTECTED]:8:0: class=0x020000 card=0x246610f1 chip=0x920010b7 rev=0x78
hdr=0x00
This is quite odd, and as a matter of fact, because our test group is always
testing drivers that are made here at Intel, I believe most often they have the
driver as a module and not static... hmmm, so let me see if I have any luck
reproducing it.
Since its often the case that a kernel you rebuild is NOT the same as the
one install ends you with it might be a good test to go ahead, redefine em
back into the kernel and see if THAT new kernel hangs. Just be SURE and
keep this other kernel available to boot up again :)
I"ll look into this, but not right away, I have a high priority chunk
of code I'm
working on and that needs to get done in the next couple days, and then
I'm having a couple long-needed weeks of vacation :)
Happy Holidays,
Jack
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
