How to obtain place of low perfomance?

[Коньков Евгений]

Hi, Freebsd-net.

serv1# ifocnfig nfe0
nfe0: flags=8943 metric 0 mtu 
1500
options=10b
ether 00:13:d4:ce:82:16
inet 10.11.8.17 netmask 0xfc00 broadcast 10.11.11.255
inet 10.11.8.15 netmask 0xfc00 broadcast 10.11.11.255
media: Ethernet autoselect (1000baseTX )
status: active
serv1# ifconfig igb0
igb0: flags=8843 metric 0 mtu 1500
options=19b
ether 00:1b:21:45:da:b8
media: Ethernet autoselect (1000baseTX )
status: active
serv1# ifconfig vlan7
vlan7: flags=8843 metric 0 mtu 1500
options=3
ether 00:1b:21:45:da:b8
inet 10.11.15.15 netmask 0xff00 broadcast 10.11.15.255
inet 10.11.7.1 netmask 0xff00 broadcast 10.11.7.255
media: Ethernet autoselect (1000baseTX )
status: active
vlan: 7 parent interface: igb0

doing bw test with iperf it show low performance on nfe0.

# iperf -c 10.11.8.17

Client connecting to 10.11.8.17, TCP port 5001
TCP window size: 32.5 KByte (default)

[  3] local 10.11.8.16 port 63911 connected with 10.11.8.17 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.5 sec124 MBytes  98.8 Mbits/sec
# iperf -c 10.11.7.1

Client connecting to 10.11.7.1, TCP port 5001
TCP window size: 32.5 KByte (default)

[  3] local 10.11.7.2 port 61422 connected with 10.11.7.1 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.3 sec800 MBytes653 Mbits/sec

despite on it is integrated I expect about 300-400Mbit throughput
does nfe0 really so poor NIC?


state of nfe0 while 'iperf' testing
# netstat -w 1 -h -d -I nfe0
input (nfe0)   output
   packets  errs  bytespackets  errs  bytes colls drops
  1.6K 0   543K   2.4K 0   1.9M 0 0
  1.8K 0   613K   2.4K 0   1.9M 0 0
  1.7K 0   620K   2.5K 0   1.9M 0 0
  1.8K 0   627K   2.6K 0   2.0M 0 0
  2.1K 0   1.2M   2.8K 0   1.9M 0 0
   28K 040M20K 0   3.0M 0 0
   11K 014M   8.3K 0   2.3M 0 0
   12K 016M   9.0K 0   2.3M 0 0
  2.8K 0   2.0M   3.1K 0   2.0M 0 0
   11K 014M   8.5K 0   2.5M 0 0
  7.8K 0   9.6M   6.4K 0   2.2M 0 0
   12K 016M   9.1K 0   2.3M 0 0
  6.9K 0   8.4M   5.8K 0   2.1M 0 0
  3.0K 0   2.5M   3.3K 0   2.0M 0 0
   11K 014M   8.2K 0   2.3M 0 0
  1.7K 0   664K   2.6K 0   1.9M 0 0
  1.7K 0   588K   2.4K 0   1.9M 0 0
  1.6K 0   627K   2.3K 0   1.8M 0 0



-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re[2]: Polling slows down bandwidth

[Коньков Евгений]

Здравствуйте, Chuck.

Вы писали 28 октября 2010 г., 23:41:58:

CS> On Oct 28, 2010, at 1:21 PM, Коньков Евгений wrote:
>> [ ... ]

CS> What is "sysctl kern.clockrate", and have you increased kern.hz
CS> in /boot/loader.conf to at least 1000, if not 2000 or 4000?

# vmstat -i
interrupt  total   rate
irq14: ata0   193948  6
irq16: rl0  42829515   1464
irq23: nfe0 41224044   1409
cpu0: timer 58494158   1999
irq256: igb0  106911  3
irq257: igb0  254606  8
irq258: igb0   2  0
Total  143103184   4892

# sysctl kern.clockrate
kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 }

# sysctl kern.hz
kern.hz: 1000
but I have configured and installed kern with 2000HZ
"systat -v" shows that: 2002 cpu0: time


CS> Polling mode operation generally performs better when using older
CS> 100Mbs ethernet NICs which do not support interrupt mitigation and
CS> various capabilities like TSO4; gigabit ethernet NICs are smarter
CS> hardware and can generally outperform polling mode.
so using polling on gigabit NICs is a bottle neck? and is cause of low
performance, is not?





-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Hardlock with alc0 device

[Pyun YongHyeon]

On Fri, Oct 29, 2010 at 06:15:16AM -0400, Kris Moore wrote:
> 
> I'm running into a rather interesting problem here on HEAD with a newer Asus
> EEE PC and the "alc" network driver. The device works great when a
> cable is plugged in, no issues at all. However, if I unplug the ethernet
> and reboot then I get a hard-lock when it tries to bring up the device.
> 
> I disabled ifconfig_alc0="DHCP" in rc.conf, and now the system boots
> normally, but just for kicks I tried running "dhclient alc0" on it
> manually, and sure enough it resulted in another system lockup. (No kern dump,
> doesn't even get that far)
> 
> Here's some information about the system / device, let me know if there
> is any other data / commands I should run and send over. 
> 
> 
> FreeBSD mininova 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Sat Oct 23 13:11:00 PDT 
> 2010
> 
> a...@pci0:1:0:0:class=0x02 card=0x838a1043 chip=0x10621969 
> rev=0xc0 hdr=0x00
> vendor = 'Attansic (Now owned by Atheros)'
> device = 'Atheros AR8132 PCI-E Fast Ethernet Controller (AR8132)'
> class  = network
> subclass   = ethernet
> 
> 
> alc0: flags=8802 metric 0 mtu 1500
> 
> options=c3198
> ether 20:cf:30:1e:b2:38
> media: Ethernet autoselect
> 

I was not able to reproduce it with sample board so I'm not sure
what register access could trigger the stuck. Given that there are
some configuration changes in BIOS for better power saving(ASPM) it
could be related with accessing ALC_PM_CFG register.
I also remember some user reported controller couldn't establish
link when system booted without UTP cable plugged in. Not sure this
is also the same issue as sample board does not show the issue.

Anyway, would you try attached patch?
Index: sys/dev/alc/if_alc.c
===
--- sys/dev/alc/if_alc.c	(revision 214514)
+++ sys/dev/alc/if_alc.c	(working copy)
@@ -331,8 +331,8 @@
 		reg = CSR_READ_4(sc, ALC_MAC_CFG);
 		reg |= MAC_CFG_TX_ENB | MAC_CFG_RX_ENB;
 		CSR_WRITE_4(sc, ALC_MAC_CFG, reg);
+		alc_aspm(sc, IFM_SUBTYPE(mii->mii_media_active));
 	}
-	alc_aspm(sc, IFM_SUBTYPE(mii->mii_media_active));
 }
 
 static void
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Excessive Duplicate ACKs

[Tom Judge]

On 10/27/2010 01:27 PM, Sean Bruno wrote:
> We moved an application stack from BSD4(BOO!) to BSD7(YAY!) recently and
> got a great performance increase, so first:  GOOD JOB.
>
> Periodically, we are seeing strings of duplicate ACK being sent in
> <100uSec deltas.  I can't imagine that this should be happening, but
> there it is.  I've sanitized an example trace of a transaction,
> demonstrating an average case that had 8 dup ACKs, some less than 3
> microsends in delta!  sysctl -a also attached (and sanitized).
>

I saw something like this on FreeBSD 7.1 with an oldish slapd where the
daemon was sending very small frames very quickly and the receiver could
not keep up and was dropping the frames in the NIC firmware has the host
was not draining the receive buffer fast enough.

We used wireshark to analyze the flows and it was reporting lots of
duplicate ACKs in the capture.  Looking more closely at the ACK we saw
that all of the reported duplicates where actually SACK frames and
wireshark was not smart enough to look into the SACK option and was only
processing the ACK sequence number.  Later in the flow (microseconds
also) we where seeing a fast retransmission of the data between the
current ACK sequence number and the SACK start sequence.

Maybe you are seeing something similar?


Tom
 
> http://people.freebsd.org/~sbruno/dup_ack_collapsed.txt
>
> http://people.freebsd.org/~sbruno/sysctl_dup_acks.txt
>
>
> Sean
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


-- 
TJU13-ARIN

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Re[2]: Polling slows down bandwidth

[Chuck Swiger]

On Oct 28, 2010, at 11:39 PM, Коньков Евгений wrote:
> Здравствуйте, Chuck.

Um, greetings?  

> Вы писали 28 октября 2010 г., 23:41:58:
> 
> CS> On Oct 28, 2010, at 1:21 PM, Коньков Евгений wrote:
>>> [ ... ]
> 
> CS> What is "sysctl kern.clockrate", and have you increased kern.hz
> CS> in /boot/loader.conf to at least 1000, if not 2000 or 4000?
> 
> # vmstat -i
> interrupt  total   rate
> irq14: ata0   193948  6
> irq16: rl0  42829515   1464
> irq23: nfe0 41224044   1409
> cpu0: timer 58494158   1999
> irq256: igb0  106911  3
> irq257: igb0  254606  8
> irq258: igb0   2  0
> Total  143103184   4892
> 
> # sysctl kern.clockrate
> kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 }
> 
> # sysctl kern.hz
> kern.hz: 1000
> but I have configured and installed kern with 2000HZ
> "systat -v" shows that: 2002 cpu0: time

Actually, the interrupt rate is tracking profile hz, which is roughly double 
the actual kern.hz-- per sysctl, you should try to at least double kern.hz.

> 
> CS> Polling mode operation generally performs better when using older
> CS> 100Mbs ethernet NICs which do not support interrupt mitigation and
> CS> various capabilities like TSO4; gigabit ethernet NICs are smarter
> CS> hardware and can generally outperform polling mode.
> 
> so using polling on gigabit NICs is a bottle neck? and is cause of low 
> performance, is not?

Simple answer is yes.  It should be possible that you could tune polling to get 
similar performance, or at least better performance than you see now, but the 
additional hardware capabilities of gigabit NICs are likely to outperform 
polling mode, just as polling mode can generally outperform old 100MBs ethernet 
NICs.

Regards,
-- 
-Chuck

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re[4]: Polling slows down bandwidth

[Коньков Евгений]

Zdravstvuyte, Chuck. (How do you do, Chuck ;-)


Вы писали 29 октября 2010 г., 20:23:19:

CS> On Oct 28, 2010, at 11:39 PM, Коньков Евгений wrote:
>> Здравствуйте, Chuck.

CS> Um, greetings?
yes, it is

>> Вы писали 28 октября 2010 г., 23:41:58:
>> 
>> CS> On Oct 28, 2010, at 1:21 PM, Коньков Евгений wrote:
 [ ... ]
>> 
>> CS> What is "sysctl kern.clockrate", and have you increased kern.hz
>> CS> in /boot/loader.conf to at least 1000, if not 2000 or 4000?
>> 
>> # vmstat -i
>> interrupt  total   rate
>> irq14: ata0   193948  6
>> irq16: rl0  42829515   1464
>> irq23: nfe0 41224044   1409
>> cpu0: timer 58494158   1999
>> irq256: igb0  106911  3
>> irq257: igb0  254606  8
>> irq258: igb0   2  0
>> Total  143103184   4892
>> 
>> # sysctl kern.clockrate
>> kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 }
>> 
>> # sysctl kern.hz
>> kern.hz: 1000
>> but I have configured and installed kern with 2000HZ
>> "systat -v" shows that: 2002 cpu0: time

CS> Actually, the interrupt rate is tracking profile hz, which is
CS> roughly double the actual kern.hz-- per sysctl, you should try to at least 
double kern.hz.
ok, I will.

>> 
>> CS> Polling mode operation generally performs better when using older
>> CS> 100Mbs ethernet NICs which do not support interrupt mitigation and
>> CS> various capabilities like TSO4; gigabit ethernet NICs are smarter
>> CS> hardware and can generally outperform polling mode.
>> 
>> so using polling on gigabit NICs is a bottle neck? and is cause of low 
>> performance, is not?

CS> Simple answer is yes.  It should be possible that you could tune
CS> polling to get similar performance, or at least better performance
CS> than you see now, but the additional hardware capabilities of
CS> gigabit NICs are likely to outperform polling mode, just as
CS> polling mode can generally outperform old 100MBs ethernet NICs.

CS> Regards,



-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Polling slows down bandwidth

[Pyun YongHyeon]

On Thu, Oct 28, 2010 at 11:21:11PM +0300, ?? ?? wrote:
> Hello,
> w/0 polling:
> 
> 
> serv1# ifconfig nfe0
> nfe0: flags=8943 metric 0 mtu 
> 1500
> options=10b
> ether 00:13:d4:ce:82:16
> inet 10.11.8.17 netmask 0xfc00 broadcast 10.11.11.255
> inet 10.11.15.15 netmask 0xff00 broadcast 10.11.15.255
> inet 10.11.8.15 netmask 0xfc00 broadcast 10.11.11.255
> media: Ethernet autoselect (1000baseTX )
> status: active
> 
> serv2# ifconfig re0
> re0: flags=8843 metric 0 mtu 1500
> 
> options=389b
> ether 00:1c:c0:c8:5a:4e
> inet 192.168.255.254 netmask 0x broadcast 192.168.255.254
> media: Ethernet autoselect (1000baseTX )
> status: active
> 
> 
> serv1# systat -v
> 2 usersLoad  0.38  0.49  0.38  Oct 28 23:10
> 
> Mem:KBREALVIRTUAL   VN PAGER   SWAP PAGER
> Tot   Share  TotShareFree   in   out in   out
> Act  324452   20196   49040025112  938576  count
> All  346596   21060 1074286k28104  pages
> Proc:Interrupts
>   r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Fltcow   29953 total
>   1  47   71k   18 5022  27k 20291zfodatkbd0 1
>   ozfod 7 ata0 
> irq14
> 62.4%Sys  18.7%Intr  0.4%User  0.0%Nice 18.4%Idle%ozfod 27944 nfe0 
> irq23
> |||||||||||   daefr  2001 cpu0: 
> time
> ===++ prcfr   igb0 256
>  1 dtbuf6 totfr 1 igb0 257
> Namei Name-cache   Dir-cache10 desvn  react   igb0 258
>Callshits   %hits   % 84106 numvn  pdwak
>5   5 100 24824 frevn  pdpgs
>   intrn
> Disks   ad0373808 wire
> KB/t  16.00292088 act
> tps   7417568 inact
> MB/s   0.10   200 cache
> %busy 0938376 free
> 
> iperf result:
> [ ID] Interval   Transfer Bandwidth
> [  4]  0.0-10.3 sec450 MBytes368 Mbits/sec
> 
> 
> after enable POLLING:
> serv1# ifconfig nfe0 polling
> 2 usersLoad  0.32  0.39  0.35  Oct 28 23:13
> 
> Mem:KBREALVIRTUAL   VN PAGER   SWAP PAGER
> Tot   Share  TotShareFree   in   out in   out
> Act  324464   20196   49065625112  938428  count
> All  346624   21060 1074286k28104  pages
> Proc:Interrupts
>   r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Fltcow2006 total
>   1  47   28k   19 26916 20362zfodatkbd0 1
>   ozfod 4 ata0 
> irq14
> 24.7%Sys  18.6%Intr  0.7%User  0.0%Nice 55.9%Idle%ozfod   nfe0 
> irq23
> |||||||||||   daefr  2001 cpu0: 
> time
> ++prcfr   igb0 256
> 10 dtbuf2 totfr 1 igb0 257
> Namei Name-cache   Dir-cache10 desvn  react   igb0 258
>Callshits   %hits   % 84106 numvn  pdwak
>   20  20 100 24824 frevn  pdpgs
>   intrn
> Disks   ad0373944 wire
> KB/t  16.00292104 act
> tps   4417564 inact
> MB/s   0.07   200 cache
> %busy 0938228 free
> 
> I get bad results (((
> [ ID] Interval   Transfer Bandwidth
> [  4]  0.0-10.3 sec180 MBytes147 Mbits/sec
> 

nfe(4) controllers are one of rare gigabit controllers that lacks
efficient interrupt moderation mechanism. So it's normal to see
high number of interrupts under load.
hz controls how frequently checks controller's RX/TX queue so you
may have to increase hz to get reasonable performance under high
network load with polling(4). One of important performance factor
for NIC is how many frames should be processed for given network
load pattern. If you have to process more frames you have to
increase hz in polling(4).
I don't know what nfe(4) controller you have but it seems it's
somewhat low-end model because MSI/MSIX is not used at all.

Re: How to obtain place of low perfomance?

[Pyun YongHyeon]

On Fri, Oct 29, 2010 at 10:20:10AM +0300, ?? ?? wrote:
> Hi, Freebsd-net.
> 
> serv1# ifocnfig nfe0
> nfe0: flags=8943 metric 0 mtu 
> 1500
> options=10b
> ether 00:13:d4:ce:82:16
> inet 10.11.8.17 netmask 0xfc00 broadcast 10.11.11.255
> inet 10.11.8.15 netmask 0xfc00 broadcast 10.11.11.255
> media: Ethernet autoselect (1000baseTX )
> status: active
> serv1# ifconfig igb0
> igb0: flags=8843 metric 0 mtu 1500
> options=19b
> ether 00:1b:21:45:da:b8
> media: Ethernet autoselect (1000baseTX )
> status: active
> serv1# ifconfig vlan7
> vlan7: flags=8843 metric 0 mtu 1500
> options=3
> ether 00:1b:21:45:da:b8
> inet 10.11.15.15 netmask 0xff00 broadcast 10.11.15.255
> inet 10.11.7.1 netmask 0xff00 broadcast 10.11.7.255
> media: Ethernet autoselect (1000baseTX )
> status: active
> vlan: 7 parent interface: igb0
> 
> doing bw test with iperf it show low performance on nfe0.
> 
> # iperf -c 10.11.8.17
> 
> Client connecting to 10.11.8.17, TCP port 5001
> TCP window size: 32.5 KByte (default)
> 
> [  3] local 10.11.8.16 port 63911 connected with 10.11.8.17 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.5 sec124 MBytes  98.8 Mbits/sec
> # iperf -c 10.11.7.1
> 
> Client connecting to 10.11.7.1, TCP port 5001
> TCP window size: 32.5 KByte (default)
> 
> [  3] local 10.11.7.2 port 61422 connected with 10.11.7.1 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.3 sec800 MBytes653 Mbits/sec
> 
> despite on it is integrated I expect about 300-400Mbit throughput
> does nfe0 really so poor NIC?

nfe(4) controllers would not be one of best controllers targeted
for server environments but generally it's not poor for desktop
users. I mean you should be able to saturate link when you use bulk
TCP/UDP transfers.
Last time I tried iperf it was not reliable. Did you disable
threading of iperf? Also note, both sender/receiver of iperf should
be built with same configuration option.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

tftpd - timeouts and possible Denial-Of-Service

[Ronald F. Guilmette]

Although the tftp protocol has, apparently, been intended from the outset
to provide support for finite-time file transfers, I myself would like to
see if I can use it in the context of a (near-)continuous streaming data
collection application.

This raises a number of issues and questions, and I'm hoping that somebody
here might have some answers for me.

First, with regards to the FreeBSD tftpd daemon, I see that unlike its
client counterpart (tftp), this server daemon doesn't, apparently, have
any way of specifying any sorts of per-packet or per-transfer timeouts.
That naturally makes me wonder whether or not a determined and malicious
attacker could perhaps engineer an effective denial of service attack
against the tftp daemon, simply by continuously creating new file
transfer sessions and then never terminating any of those, thus causing
tftpd to use up all of its available file descriptors (and possibly all
available file descriptors, system-wide, e.g. if tftpd is running as
root).

Can anyone here speak to this?  Is this a plausible threat?

It seems to me that there are only two possibilities here, i.e. either
(1) tftpd indeed has no per-transfer timeouts, thus apparently enabling
a denial-of-service on the daemon (or the system) via exhaustion of file
descriptors or else (b) tftpd does in fact have a built-in per-transfer
timeout, but that is entirely undocumented in the man page.

Either way, it appears to me that _something_ may perhaps need to get fixed.

My second question only comes into play if there is (or will be, in future)
some sort of per-transfer timeout implemented within tftpd... and this
question may sound more than a bit odd, given that I have just expressed
a concern, above, regarding a possible DoS due to the lack of tftpd per-
transfer timesouts...

Basically, for my application, where I want to use tftpd (together with a
client that I myself will be coding from scratch) to do continuous or nearly-
continuous data logging, if there is in fact some per-transfer timeout
implemented within tftpd, then I would need to know how to defeat it, e.g.
so that I could keep a single "file transfer" session/transaction open for,
say, 24 hours, continuously.

I understand that some may perhaps take umbrage at my desire to make use
of the TFTP protocol for a application context that it was never really
designed for, but still, this protocol fits, or nearly fits most of my
needs, so I would still like to use it anyway, regardless of the history
or current common usage.  However if the sever side implements no timeouts,
I see that as opening up a possible DoS attack hole, whereas if there is,
or will be, per-transfer timeouts in tftpd, then for my specific application,
I will need to know how to engineer an effective "keep alive" for my
particular (long lived) tftp sessions.  (And I have some ideas of how
such "keep alive" functionality might be implemented in a way that would
not do too much violence to the existing protocol, but I'll wait and see
what the responses, if any, are to this message before I go off on _that_
tangent.)


Regards,
rfg


P.S.  If anyone wants to suggest to me some different sort of streaming
protocol for which (a) BSD/Linux servers & clients already exist and are
generally available, and which (b) uses UDP in preference to TCP, and
which (c) is generally reliable (e.g. retransmittingf dropped packets,
when necessary) and which (d) is suitable for low-volume data logging
where latency is not at all an issue, then by all means, please proceed
and _do_ suggest some alternatives.  Keep in mind however that the main
reason I am looking in particular at TFTP right now is that it should be
quite "trivial" for me to code up my own specialized (embedded?) client.
And that's an important consideration.  I really don't have the time to
code up from scratch any big and complex protocol.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Polling slows down bandwidth

[Larry Baird]

Also make sure kern.polling.idle_poll is enabled.  By default it is
disabled.  This makes a big difference in polling throughput.

Larry

-- 

Larry Baird| http://www.gta.com
Global Technology Associates, Inc. | Orlando, FL
Email: l...@gta.com | TEL 407-380-0220, FAX 407-380-6080
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

em driver problem on vmware

[Ricky Charlet]

Howdy,
I have freebsd80-release with an upgraded em0 driver from freebsd8.1 
(and an appropriate touch of if_var.h). I'm running an amd64 on a  vmware vm.  
And I see this in dmesg:

cut-
em0:  port 0x2000-203f mem 
0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2
em0: Memory Access and/or Bus Master bits were not set
em0: [FILTER]
em0: Ethernet address: 00:0c:29:57:d7:7f
paste

Now, I certainly may have done something wrong with my code switch 
(just copied over the sys/dev/e1000 directory from 8.1 and defined 
drbr_needs_enqueue in if_var.h). I'll start double checking.

But, on the other hand, has anyone seen the new em driver 
working/failing on a vmware vm?


Thanks


---
Ricky Charlet
Adara Networks
USA 408-433-4942

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Hardlock with alc0 device

[Kris Moore]

On Fri, Oct 29, 2010 at 09:55:31AM -0700, Pyun YongHyeon wrote:
> On Fri, Oct 29, 2010 at 06:15:16AM -0400, Kris Moore wrote:
> > 
> > I'm running into a rather interesting problem here on HEAD with a newer Asus
> > EEE PC and the "alc" network driver. The device works great when a
> > cable is plugged in, no issues at all. However, if I unplug the ethernet
> > and reboot then I get a hard-lock when it tries to bring up the device.
> > 
> > I disabled ifconfig_alc0="DHCP" in rc.conf, and now the system boots
> > normally, but just for kicks I tried running "dhclient alc0" on it
> > manually, and sure enough it resulted in another system lockup. (No kern 
> > dump,
> > doesn't even get that far)
> > 
> > Here's some information about the system / device, let me know if there
> > is any other data / commands I should run and send over. 
> > 
> > 
> > FreeBSD mininova 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Sat Oct 23 13:11:00 
> > PDT 2010
> > 
> > a...@pci0:1:0:0:class=0x02 card=0x838a1043 chip=0x10621969 
> > rev=0xc0 hdr=0x00
> > vendor = 'Attansic (Now owned by Atheros)'
> > device = 'Atheros AR8132 PCI-E Fast Ethernet Controller (AR8132)'
> > class  = network
> > subclass   = ethernet
> > 
> > 
> > alc0: flags=8802 metric 0 mtu 1500
> > 
> > options=c3198
> > ether 20:cf:30:1e:b2:38
> > media: Ethernet autoselect
> > 
> 
> I was not able to reproduce it with sample board so I'm not sure
> what register access could trigger the stuck. Given that there are
> some configuration changes in BIOS for better power saving(ASPM) it
> could be related with accessing ALC_PM_CFG register.
> I also remember some user reported controller couldn't establish
> link when system booted without UTP cable plugged in. Not sure this
> is also the same issue as sample board does not show the issue.
> 
> Anyway, would you try attached patch?

> Index: sys/dev/alc/if_alc.c
> ===
> --- sys/dev/alc/if_alc.c  (revision 214514)
> +++ sys/dev/alc/if_alc.c  (working copy)
> @@ -331,8 +331,8 @@
>   reg = CSR_READ_4(sc, ALC_MAC_CFG);
>   reg |= MAC_CFG_TX_ENB | MAC_CFG_RX_ENB;
>   CSR_WRITE_4(sc, ALC_MAC_CFG, reg);
> + alc_aspm(sc, IFM_SUBTYPE(mii->mii_media_active));
>   }
> - alc_aspm(sc, IFM_SUBTYPE(mii->mii_media_active));
>  }
>  
>  static void

Well, so far with the attached patch, after a couple reboots, and trying to use 
dhclient, it's still working fine.  Also after the initial dhclient times out I 
get a link status of "status: no carrier" now, which didn't show up
before, so thats good too.

Thanks for the quick fix, will you put this into HEAD soon?

-- 
Kris Moore
PC-BSD Software
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Hardlock with alc0 device

[Pyun YongHyeon]

On Fri, Oct 29, 2010 at 08:44:22PM -0400, Kris Moore wrote:
> On Fri, Oct 29, 2010 at 09:55:31AM -0700, Pyun YongHyeon wrote:
> > On Fri, Oct 29, 2010 at 06:15:16AM -0400, Kris Moore wrote:
> > > 
> > > I'm running into a rather interesting problem here on HEAD with a newer 
> > > Asus
> > > EEE PC and the "alc" network driver. The device works great when a
> > > cable is plugged in, no issues at all. However, if I unplug the ethernet
> > > and reboot then I get a hard-lock when it tries to bring up the device.
> > > 
> > > I disabled ifconfig_alc0="DHCP" in rc.conf, and now the system boots
> > > normally, but just for kicks I tried running "dhclient alc0" on it
> > > manually, and sure enough it resulted in another system lockup. (No kern 
> > > dump,
> > > doesn't even get that far)
> > > 
> > > Here's some information about the system / device, let me know if there
> > > is any other data / commands I should run and send over. 
> > > 
> > > 
> > > FreeBSD mininova 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Sat Oct 23 13:11:00 
> > > PDT 2010
> > > 
> > > a...@pci0:1:0:0:class=0x02 card=0x838a1043 chip=0x10621969 
> > > rev=0xc0 hdr=0x00
> > > vendor = 'Attansic (Now owned by Atheros)'
> > > device = 'Atheros AR8132 PCI-E Fast Ethernet Controller (AR8132)'
> > > class  = network
> > > subclass   = ethernet
> > > 
> > > 
> > > alc0: flags=8802 metric 0 mtu 1500
> > > 
> > > options=c3198
> > > ether 20:cf:30:1e:b2:38
> > > media: Ethernet autoselect
> > > 
> > 
> > I was not able to reproduce it with sample board so I'm not sure
> > what register access could trigger the stuck. Given that there are
> > some configuration changes in BIOS for better power saving(ASPM) it
> > could be related with accessing ALC_PM_CFG register.
> > I also remember some user reported controller couldn't establish
> > link when system booted without UTP cable plugged in. Not sure this
> > is also the same issue as sample board does not show the issue.
> > 
> > Anyway, would you try attached patch?
> 
> > Index: sys/dev/alc/if_alc.c
> > ===
> > --- sys/dev/alc/if_alc.c(revision 214514)
> > +++ sys/dev/alc/if_alc.c(working copy)
> > @@ -331,8 +331,8 @@
> > reg = CSR_READ_4(sc, ALC_MAC_CFG);
> > reg |= MAC_CFG_TX_ENB | MAC_CFG_RX_ENB;
> > CSR_WRITE_4(sc, ALC_MAC_CFG, reg);
> > +   alc_aspm(sc, IFM_SUBTYPE(mii->mii_media_active));
> > }
> > -   alc_aspm(sc, IFM_SUBTYPE(mii->mii_media_active));
> >  }
> >  
> >  static void
> 
> Well, so far with the attached patch, after a couple reboots, and trying to 
> use dhclient, it's still working fine.  Also after the initial dhclient times 
> out I get a link status of "status: no carrier" now, which didn't show up
> before, so thats good too.
> 

Thanks a lot for testing!

> Thanks for the quick fix, will you put this into HEAD soon?
> 

Patch committed(r214542).
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: em driver problem on vmware

[Ricky Charlet]

FYI,
That dmesg output I get from my franken-driver on vmware is exactly the same 
output I get from the *working* bsd80Release on vmware:

cut
[r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0
em0:  port 0x2000-0x203f mem 
0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on pci2
em0: Memory Access and/or Bus Master bits were not set!
em0: [FILTER]
em0: Ethernet address: 00:0c:29:57:d7:7f
---paste---


So I don't think the clue is hiding in dmesg.

---
Ricky Charlet
Adara Networks
USA 408-433-4942


-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On 
Behalf Of Ricky Charlet
Sent: Friday, October 29, 2010 5:07 PM
To: freebsd-net@freebsd.org
Subject: em driver problem on vmware

Howdy,
I have freebsd80-release with an upgraded em0 driver from freebsd8.1 
(and an appropriate touch of if_var.h). I'm running an amd64 on a  vmware vm.  
And I see this in dmesg:

cut-
em0:  port 0x2000-203f mem 
0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2
em0: Memory Access and/or Bus Master bits were not set
em0: [FILTER]
em0: Ethernet address: 00:0c:29:57:d7:7f
paste

Now, I certainly may have done something wrong with my code switch 
(just copied over the sys/dev/e1000 directory from 8.1 and defined 
drbr_needs_enqueue in if_var.h). I'll start double checking.

But, on the other hand, has anyone seen the new em driver 
working/failing on a vmware vm?


Thanks


---
Ricky Charlet
Adara Networks
USA 408-433-4942

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver problem on vmware

[Jack Vogel]

I remember seeing the same thing when running a FreeBSD guest on
Linux/KVM, its informational, the code will enable said bits right after
it says that.

So, the focus should be on the data, you are saying the delivered
driver in 8.0 out of the box works and which driver exactly are you
trying to use, my last checked in?

More on the failure,  does it ping, does its link partner see anything,
etc, etc..

Jack


On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet wrote:

> FYI,
> That dmesg output I get from my franken-driver on vmware is exactly the
> same output I get from the *working* bsd80Release on vmware:
>
> cut
> [r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0
> em0:  port 0x2000-0x203f mem
> 0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on pci2
> em0: Memory Access and/or Bus Master bits were not set!
> em0: [FILTER]
> em0: Ethernet address: 00:0c:29:57:d7:7f
> ---paste---
>
>
> So I don't think the clue is hiding in dmesg.
>
> ---
> Ricky Charlet
> Adara Networks
> USA 408-433-4942
>
>
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org]
> On Behalf Of Ricky Charlet
> Sent: Friday, October 29, 2010 5:07 PM
> To: freebsd-net@freebsd.org
> Subject: em driver problem on vmware
>
> Howdy,
>I have freebsd80-release with an upgraded em0 driver from freebsd8.1
> (and an appropriate touch of if_var.h). I'm running an amd64 on a  vmware
> vm.  And I see this in dmesg:
>
> cut-
> em0:  port 0x2000-203f mem
> 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2
> em0: Memory Access and/or Bus Master bits were not set
> em0: [FILTER]
> em0: Ethernet address: 00:0c:29:57:d7:7f
> paste
>
>Now, I certainly may have done something wrong with my code switch
> (just copied over the sys/dev/e1000 directory from 8.1 and defined
> drbr_needs_enqueue in if_var.h). I'll start double checking.
>
>But, on the other hand, has anyone seen the new em driver
> working/failing on a vmware vm?
>
>
> Thanks
>
>
> ---
> Ricky Charlet
> Adara Networks
> USA 408-433-4942
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver problem on vmware

[Juli Mallett]

On Fri, Oct 29, 2010 at 17:07, Ricky  Charlet  wrote:
> Howdy,
>        I have freebsd80-release with an upgraded em0 driver from freebsd8.1 
> (and an appropriate touch of if_var.h). I'm running an amd64 on a  vmware vm. 
>  And I see this in dmesg:
>
> cut-
> em0:  port 0x2000-203f mem 
> 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2
> em0: Memory Access and/or Bus Master bits were not set
> em0: [FILTER]
> em0: Ethernet address: 00:0c:29:57:d7:7f
> paste
>
>        But, on the other hand, has anyone seen the new em driver 
> working/failing on a vmware vm?

"Memory Access and/or Bus Master bits were not set" is not a fatal
error, it is correctable, indeed that is printed out when it is
corrected; that is not something to worry about in and of itself as
such, are you actually having a problem or just concerned because you
saw that in dmesg?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: em driver problem on vmware

[Ricky Charlet]

> -Original Message-
> From: j...@clockworksquid.com [mailto:j...@clockworksquid.com] On
> Behalf Of Juli Mallett
> Sent: Friday, October 29, 2010 6:55 PM
> To: Ricky Charlet
> Cc: freebsd-net@freebsd.org
> Subject: Re: em driver problem on vmware
>
> On Fri, Oct 29, 2010 at 17:07, Ricky  Charlet 
> wrote:
> > Howdy,
> >I have freebsd80-release with an upgraded em0 driver from
> freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64
> on a  vmware vm.  And I see this in dmesg:
> >
> > cut-
> > em0:  port 0x2000-203f
> mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0
> on pci2
> > em0: Memory Access and/or Bus Master bits were not set
> > em0: [FILTER]
> > em0: Ethernet address: 00:0c:29:57:d7:7f
> > paste
> >
> >But, on the other hand, has anyone seen the new em driver
> working/failing on a vmware vm?
>
> "Memory Access and/or Bus Master bits were not set" is not a fatal
> error, it is correctable, indeed that is printed out when it is
> corrected; that is not something to worry about in and of itself as
> such, are you actually having a problem or just concerned because you
> saw that in dmesg?


 It is truly not working. I agree those lines in dmesg are good and indicate 
em0 is ready. but `ifconfig` does not see em0.


---
Ricky Charlet
Adara Networks
USA 408-433-4942



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver problem on vmware

[Jack Vogel]

pciconf -l

If you got a printf from the driver its VERY odd that it says the interface
does not exist :)

Jack


On Fri, Oct 29, 2010 at 7:03 PM, Ricky Charlet wrote:

>
>
> > -Original Message-
> > From: j...@clockworksquid.com [mailto:j...@clockworksquid.com] On
> > Behalf Of Juli Mallett
> > Sent: Friday, October 29, 2010 6:55 PM
> > To: Ricky Charlet
> > Cc: freebsd-net@freebsd.org
> > Subject: Re: em driver problem on vmware
> >
> > On Fri, Oct 29, 2010 at 17:07, Ricky  Charlet 
> > wrote:
> > > Howdy,
> > >I have freebsd80-release with an upgraded em0 driver from
> > freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64
> > on a  vmware vm.  And I see this in dmesg:
> > >
> > > cut-
> > > em0:  port 0x2000-203f
> > mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0
> > on pci2
> > > em0: Memory Access and/or Bus Master bits were not set
> > > em0: [FILTER]
> > > em0: Ethernet address: 00:0c:29:57:d7:7f
> > > paste
> > >
> > >But, on the other hand, has anyone seen the new em driver
> > working/failing on a vmware vm?
> >
> > "Memory Access and/or Bus Master bits were not set" is not a fatal
> > error, it is correctable, indeed that is printed out when it is
> > corrected; that is not something to worry about in and of itself as
> > such, are you actually having a problem or just concerned because you
> > saw that in dmesg?
>
>
>  It is truly not working. I agree those lines in dmesg are good and
> indicate em0 is ready. but `ifconfig` does not see em0.
>
>
> ---
> Ricky Charlet
> Adara Networks
> USA 408-433-4942
>
>
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: em driver problem on vmware

[Kevin Lo]

Hi Rick,

The FreeBSD -current works fine for me with the newest em(4) 
under the VMware player.

Kevin

On Friday, 2010-10-29 at 19:22 -0700, Ricky Charlet wrote:
> Thanks Jack,
> 
> The failure is that ifconfig is unaware of em0.  My em0 is 
> not configured, so link partners are also unaware of it.
> ifconfig em0
> ifconfig: interface em0 does not exist
> 
> and you already have my dmes stuff on em0 (which I am now up to agreeing 
> looks positive and would not indicate a problem)
> 
> 
> My amalgamated file is a private combination of some 8.1, some 9.0, some 
> stuff a cohort did.  We have been motivated to 'upgrade' from e1000 in 8.0 to 
> a newer/modified e1000 because of our desire to incorporate the altq patches.
> 
> For the curious and the diligent, the e1000/if_em.c file I am 
> using is attached.
> 
> Ricky
> 
> 
> From: Jack Vogel [mailto:jfvo...@gmail.com]
> Sent: Friday, October 29, 2010 7:13 PM
> To: Ricky Charlet
> Cc: freebsd-net@freebsd.org
> Subject: Re: em driver problem on vmware
> 
> I remember seeing the same thing when running a FreeBSD guest on
> Linux/KVM, its informational, the code will enable said bits right after
> it says that.
> 
> So, the focus should be on the data, you are saying the delivered
> driver in 8.0 out of the box works and which driver exactly are you
> trying to use, my last checked in?
> 
> More on the failure,  does it ping, does its link partner see anything,
> etc, etc..
> 
> Jack
> 
> On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet 
> mailto:rchar...@adaranet.com>> wrote:
> FYI,
> That dmesg output I get from my franken-driver on vmware is exactly the same 
> output I get from the *working* bsd80Release on vmware:
> 
> cut
> [r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0
> em0:  port 0x2000-0x203f mem 
> 0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on pci2
> em0: Memory Access and/or Bus Master bits were not set!
> em0: [FILTER]
> em0: Ethernet address: 00:0c:29:57:d7:7f
> ---paste---
> 
> 
> So I don't think the clue is hiding in dmesg.
> 
> ---
> Ricky Charlet
> Adara Networks
> USA 408-433-4942
> 
> -Original Message-
> From: owner-freebsd-...@freebsd.org 
> [mailto:owner-freebsd-...@freebsd.org] 
> On Behalf Of Ricky Charlet
> Sent: Friday, October 29, 2010 5:07 PM
> To: freebsd-net@freebsd.org
> Subject: em driver problem on vmware
> 
> Howdy,
>I have freebsd80-release with an upgraded em0 driver from freebsd8.1 
> (and an appropriate touch of if_var.h). I'm running an amd64 on a  vmware vm. 
>  And I see this in dmesg:
> 
> cut-
> em0:  port 0x2000-203f mem 
> 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2
> em0: Memory Access and/or Bus Master bits were not set
> em0: [FILTER]
> em0: Ethernet address: 00:0c:29:57:d7:7f
> paste
> 
>Now, I certainly may have done something wrong with my code switch 
> (just copied over the sys/dev/e1000 directory from 8.1 and defined 
> drbr_needs_enqueue in if_var.h). I'll start double checking.
> 
>But, on the other hand, has anyone seen the new em driver 
> working/failing on a vmware vm?
> 
> 
> Thanks
> 
> 
> ---
> Ricky Charlet
> Adara Networks
> USA 408-433-4942
> 
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to 
> "freebsd-net-unsubscr...@freebsd.org"
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to 
> "freebsd-net-unsubscr...@freebsd.org"
> 
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: em driver problem on vmware

[Ricky Charlet]

Hi Jack,
  My pciconf output is attached. I'm afraid I don't grok it and will need a 
hand to even let me know if this is good/not-good.

Ricky

From: Jack Vogel [mailto:jfvo...@gmail.com]
Sent: Friday, October 29, 2010 10:07 PM
To: Ricky Charlet
Cc: Juli Mallett; freebsd-net@freebsd.org
Subject: Re: em driver problem on vmware

pciconf -l

If you got a printf from the driver its VERY odd that it says the interface
does not exist :)

Jack

On Fri, Oct 29, 2010 at 7:03 PM, Ricky Charlet 
mailto:rchar...@adaranet.com>> wrote:


> -Original Message-
> From: j...@clockworksquid.com 
> [mailto:j...@clockworksquid.com] On
> Behalf Of Juli Mallett
> Sent: Friday, October 29, 2010 6:55 PM
> To: Ricky Charlet
> Cc: freebsd-net@freebsd.org
> Subject: Re: em driver problem on vmware
>
> On Fri, Oct 29, 2010 at 17:07, Ricky  Charlet 
> mailto:rchar...@adaranet.com>>
> wrote:
> > Howdy,
> >I have freebsd80-release with an upgraded em0 driver from
> freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64
> on a  vmware vm.  And I see this in dmesg:
> >
> > cut-
> > em0:  port 0x2000-203f
> mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0
> on pci2
> > em0: Memory Access and/or Bus Master bits were not set
> > em0: [FILTER]
> > em0: Ethernet address: 00:0c:29:57:d7:7f
> > paste
> >
> >But, on the other hand, has anyone seen the new em driver
> working/failing on a vmware vm?
>
> "Memory Access and/or Bus Master bits were not set" is not a fatal
> error, it is correctable, indeed that is printed out when it is
> corrected; that is not something to worry about in and of itself as
> such, are you actually having a problem or just concerned because you
> saw that in dmesg?

 It is truly not working. I agree those lines in dmesg are good and indicate 
em0 is ready. but `ifconfig` does not see em0.


---
Ricky Charlet
Adara Networks
USA 408-433-4942



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to 
"freebsd-net-unsubscr...@freebsd.org"

hos...@pci0:0:0:0:  class=0x06 card=0x197615ad chip=0x71908086 rev=0x01 
hdr=0x00
pc...@pci0:0:1:0:   class=0x060400 card=0x chip=0x71918086 rev=0x01 
hdr=0x01
is...@pci0:0:7:0:   class=0x060100 card=0x197615ad chip=0x71108086 rev=0x08 
hdr=0x00
atap...@pci0:0:7:1: class=0x01018a card=0x197615ad chip=0x71118086 rev=0x01 
hdr=0x00
no...@pci0:0:7:3:   class=0x068000 card=0x197615ad chip=0x71138086 rev=0x08 
hdr=0x00
no...@pci0:0:7:7:   class=0x088000 card=0x074015ad chip=0x074015ad rev=0x10 
hdr=0x00
vgap...@pci0:0:15:0:class=0x03 card=0x040515ad chip=0x040515ad rev=0x00 
hdr=0x00
m...@pci0:0:16:0:   class=0x01 card=0x197615ad chip=0x00301000 rev=0x01 
hdr=0x00
pc...@pci0:0:17:0:  class=0x060401 card=0x079015ad chip=0x079015ad rev=0x02 
hdr=0x01
pc...@pci0:0:21:0:  class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pc...@pci0:0:21:1:  class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pc...@pci0:0:21:2:  class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pc...@pci0:0:21:3:  class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pc...@pci0:0:21:4:  class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pc...@pci0:0:21:5:  class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pc...@pci0:0:21:6:  class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:21:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:4: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:5: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:6: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:22:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:23:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:23:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:23:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:23:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 
hdr=0x01
pci...@pci0:0:23:4: class=0x