Looking for testers...

[Bill Paul]

For those who may not know, I've been tinkering with a new 'tulip clone'
driver for various PCI ethernet cards. I'm attempting to combine support
for several tulip like chipsets into a single driver in an attempt to
reduce code bloat. I've gotten things to where I think they work okay,
but I'm looking for testers who have FreeBSD-current running with the
following PCI chipsets:

- Macronix 98713, 98713A, 98715A or 98725 (NDC sohoware, CNet)
- Davicom DM9102 (Jaton XpressNet)
- ASIX AX88140A or AX88141 (CNet)
- ADMtek AL981 Comet or AN985 Centaur
- Lite-On 82c168 or 82c169 PNIC (LinkSys LNE100TX, Matrox 10/100 NIC,
  Netgear FA310-TX rev D1, D2 or D3, Kingston KNE110TX)
- Lite-On/Macronix LC82c115 PNIC II (LinkSys LNE100TX v2.0)
- Intel 21143 (Kingston KNE100TX, D-Link DFE-570TX, any other board
  with an Intel 21143 and MII-based transceiver)

If you have a card with one of these chips, download the driver from
http://www.freebsd.org/~wpaul/dc.tar.gz. This includes the source for
the dc (DEC Clone) driver plus the dcphy and pnphy drivers, as well as
pre-compiled KLD modules. The simplest way to test the driver is:

- Compile a kernel *without* the ax, al, pn, mx, dm or de drivers.
- Boot it.
- kldload /path/to/dcphy.ko
- kldload /path/to/if_dc.ko

If you have "controller miibus0" in your kernel config, then you should
be fine, otherwise you will also need to do "kldload miibus" before
loading dcphy.ko and if_dc.ko. These modules are for the x86 platform:
if you want to compile them for the alpha, you should be able to just
by using the included Makefiles.

Note the following:

- The NWAY autonegotiation support on the early rev PNIC chips
  (82c168) was horribly broken and I haven't been able to make it
  work reliably, so it's not currently supported. If you have one
  of these older cards (LinkSys or Matrox), then you will have to
  select the media mode manually. It should default to 10baseT/UTP.
  If you want anything else, you need to select it manually with
  ifconfig. You must also have the dcphy.ko module loaded for this
  chip since it includes the pnphy pseudo driver.

- Both the 82c168 and 82c169 are set to default to store and forward
  mode for transmissions. This limits performance somewhat, however
  I've seen cases where setting a lower transmit threshold leads to
  corrupt packets being transmitted at 100Mbps on some systems.

- The Macronix and PNIC II chips require the dcphy.ko module, since
  it contains the pseudo driver that makes the built-in NWAY support
  on these chipsets work.

- The 21143 cards I have use MII transceivers: there exist 21143-based
  NICs that use the 21143's internal NWAY support for autonegotiation
  and a symbol mode transceiver for 100Mbps, but I haven't bloody got
  one, so I can't be sure that they will work right. The dcphy.ko
  pseudo driver should work with the built-in 21143 NWAY, but I can't
  be sure it really works correctly without a NIC to test.

- Occasionally, you may see the driver print a warning message saying
  there was a transmit underrun and that it's increasing the TX threshold.
  This is normal: if you see this message, the driver should recover and
  the interface will continue working without any user intervention.
  You may see this two or three times after the interface is brought
  up: after that, you shouldn't see it anymore. If you see this message
  a lot and the interface stops working after you see it, then I want
  to know about it. If you only see it once or twice and the interface
  recovers and keeps going, then don't be concerned; just ignore the
  message and keep testing. Odds are you will only see this with the
  Macronix, PNIC II and Davicom chips. You may see it with others under
  certain conditions.

- You may also see a debug error message of the form:

txstat: 0x

  where  is some hexadecimal value. You shouldn't see this
  under normal cicrumstances, but if you do I'd like to know about it.

I'm mainly interested in knowing how this driver code performs and how
reliable it is. I'm much more interested in reliability than peformance.
I'm also interested to see if the driver autoselects the correct speed
and duplex mode, particularly with the Macronix and PNIC II cards that
don't use MII-based PHYs.

Good tools for testing include ttcp and netperf. Testing with things
like ftp, NFS and tcpdump is also recommended. If you encounter a
condition where the interface stops receiving or sending traffic, then
I'd like to know the following:

- What if anything did you do to induce this behavior?
- Exactly what kind of NIC do you have?
- What kind of machine (CPU and PCI chipset) do you have.
- What do the following commands say when the interface stops working:
o netstat -m
o netstat -in
o ifconfig -a
- Are there any strange error message in the 

Re: Looking for testers...

[Andrew Gallatin]

Bill Paul writes:
 > For those who may not know, I've been tinkering with a new 'tulip clone'
 > driver for various PCI ethernet cards. I'm attempting to combine support
 > for several tulip like chipsets into a single driver in an attempt to
 > reduce code bloat. I've gotten things to where I think they work okay,
 > but I'm looking for testers who have FreeBSD-current running with the
 > following PCI chipsets:

YES! Hurray!  You are my hero!  I have been suffering under the
if_de driver which utterly fails to grok 100Mb full duplex on all my
21143 equipped alphas.  This news has made my week, my month!

Positive test results will follow via private email.

THANK YOU!

Drew
--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers...

[Bill Paul]

Of all the gin joints in all the towns in all the world, Andrew Gallatin 
had to walk into mine and say:
 
> Bill Paul writes:
>  > For those who may not know, I've been tinkering with a new 'tulip clone'
>  > driver for various PCI ethernet cards. I'm attempting to combine support
>  > for several tulip like chipsets into a single driver in an attempt to
>  > reduce code bloat. I've gotten things to where I think they work okay,
>  > but I'm looking for testers who have FreeBSD-current running with the
>  > following PCI chipsets:
> 
> YES! Hurray!  You are my hero!  I have been suffering under the
> if_de driver which utterly fails to grok 100Mb full duplex on all my
> 21143 equipped alphas.  This news has made my week, my month!

Careful. I said that the only 21143 cards I have use MII transceivers.
I don't have any cards that use symbol mode and built-in NWAY. The
Macronix chips copy the 21143's built-in NWAY pretty closely and
they work pretty well, but I don't know how well it works with an
actual 21143. I don't know how DEC set up the ethernet in the alphas:
if they used an MII transceiver, then it should work okay, but if
not you could be in for trouble. I wish I didn't have to say that,
but I just don't have the hardware to test with.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers...

[Jordan K. Hubbard]

> if they used an MII transceiver, then it should work okay, but if
> not you could be in for trouble. I wish I didn't have to say that,
> but I just don't have the hardware to test with.

You know what I tell people who use that excuse... ;)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Improved SYN Cookies: Looking for testers

[Andre Oppermann]

We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few available bits.

This patch updates and improves SYN cookies mainly by:

 a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN
(initial sequence number) without the use of timestamp bits.

 b) switching to the very fast and cryptographically strong SipHash-2-4
hash MAC algorithm to protect the SYN cookie against forgery.

The patch had been reviewed by dwmalone (cookies) and cperciva (siphash).

Please find it here for testing:

 http://people.freebsd.org/~andre/syncookie-20130708.diff

Please enable TCP logdebug to see connection status reporting by the
changes.

Detailed discussion:

The purpose of SYN cookies is to encode all necessary session state
in the 32 bits of our initial sequence number to avoid storing any
information locally in memory.  This is especially important when
under heavy spoofed SYN attacks where we would either run out of
memory or the syncache would fill with bogus connection attempts
swamping out legitimate connections.

The 32 bits of the ISN are a very limited space because we also have
to store a cryptographically strong enough hash MAC in it to prevent
spoofing of valid SYN cookies.  The result is that 24 bits have to
be dedicated to the MAC hash and only 8 bits remain available for
the session state.

The common parameters used on TCP sessions have changed quite a bit
since SYN cookies very invented some 17 years ago.  Today we a lot
more bandwidth making the use window scaling almost mandatory.  Also
SACK has become standard as it makes recovering from packet loss
much more efficient.

The original SYN cookies method only stored an indexed MSS values in
the cookie.  This obviously isn't sufficient anymore and breaks in
the presence of WSCALE.  WSCALE information is only exchanged during
SYN and SYN-ACK.  If we can't keep track of it then we severely under-
estimate the available send or receive window compounded with the fact
that with large window scaling the window size information on the TCP
segment header would be even lower numerically.

A number of years back I extended SYN cookies to store the additional
state in the TCP timestamp fields, if available on a connection.  It
has been adapted by Linux as well.  While timestamps are common among
the BSD, Linux and other *nix systems Windows never enabled them by
default and thus are not present for the vast majority of clients seen
on the Internet.

The new improvement in this patch moves all necessary information into
the ISN again removing the need for timestamps.  Both the MSS and send
WSCALE are stored in 3 bit indexed form together with a single bit for
SACK.  While we can't represent all possible MSS and WSCALE values, both
are 16 bit fields in the TCP header, in only 3 bits each this, it turns
out, isn't actually necessary.

The MSS depends on the MTU of the path and with the dominance of ethernet
the main value seen is around 1460 bytes.  Encapsulations for DSL lines
and some other overheads reduce it by a few more bytes for many connections
seen.  Based on large traffic surveys I've selected the most common values
that perfectly, or with only a small down rounding difference, represent
essentially 99.99% of all connections seen in real life.  Rounding down
to the next lower value isn't a problem as we only would send slightly
more packets for the same amount of data.

The send WSCALE is bit more tricky as rounding down would let us under-
estimate the available send space available towards the remote host.
Again it turns out that a small number of values dominates all connections
and is thus carefully selected again.  The receive WSCALE isn't encoded
at all but recalculated based on the local receive socket buffer size
when a valid SYN cookie returns.  The socket buffer size most likely
didn't change in the mean time on a listen socket.  If it did we'd have
a discrepancy for those SYN cookies in flight at the time of the change.

These improvements allow one to run with SYN cookies only on Internet
facing servers.  However while SYN cookies are calculated and sent all the
time, they're only used when the syn cache overflows due to attacks or
overload.  In that cause though you can rest assured that no significant
degradation in TCP connection setup happens anymore and that even Windows
clients can make use of window scaling and SACK.

In addition the hash MAC to protect the SYN cookies is changed from MD5
to SipHash-2-4, a much faster and cryptographically secure algorithm
recently developed by Jean-Philippe Aumasson and Daniel J. Bernstein.
Ministat makes the MAC hash calculation speed difference even more obvious:

x md5
+ siphash
++
| +  |
~ .  ..  ~
| +  

Looking for testers for if_dc patches

[Bill Paul]

Several people have reported problems with if_dc botching autonegotiation
on 21143 NICs with non-MII media, such as the DEC/Compaq DE500-BA and
the built-in 10/100 ethernet on some alphas. As my first official act
as a BSDi/WC employee, I sat down and tried to fix this. I produced
some patches for if_dc.c/if_dcreg.h and dcphy.c, which are sitting at
http://people.freebsd.org/~wpaul/dc_test. To apply them, do the following:

# cd /sys/pci
# patch < if_dc.patch
# cd /sys/dev/mii
# patch < dcphy.patch

These patches should work on either 4.0-STABLE or 5.0-CURRENT. (They
should also work on 4.0-RELEASE.) There are also some fixes for the
Macronix 98713A/98715/98715A and the LC82C115 PNIC II, which also
use the 21143-style NWAY interface.

Note that I still need to add code to properly set the LEDs on 21143
boards. I went after the autoneg problem first since it was somewhat
more pressing. In any event, please try these patches and report the
results to [EMAIL PROTECTED]

-Bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Improved SYN Cookies: Looking for testers

[Fabian Keil]

Andre Oppermann  wrote:

> We have a SYN cookie implementation for quite some time now but it
> has some limitations with current realities for window scaling and
> SACK encoding the in the few available bits.
> 
> This patch updates and improves SYN cookies mainly by:
> 
>   a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN
>  (initial sequence number) without the use of timestamp bits.
> 
>   b) switching to the very fast and cryptographically strong SipHash-2-4
>  hash MAC algorithm to protect the SYN cookie against forgery.
> 
> The patch had been reviewed by dwmalone (cookies) and cperciva (siphash).
> 
> Please find it here for testing:
> 
>   http://people.freebsd.org/~andre/syncookie-20130708.diff

I've been using the patch for a couple of days and didn't notice any
issues so far. Privoxy's regression tests continue to work as expected
as well.

BTW, I think kern/173309 could be closed.

Fabian


signature.asc
Description: PGP signature

Re: Improved SYN Cookies: Looking for testers

[Andre Oppermann]

On 10.07.2013 15:18, Fabian Keil wrote:

Andre Oppermann  wrote:


We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few available bits.

This patch updates and improves SYN cookies mainly by:

   a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN
  (initial sequence number) without the use of timestamp bits.

   b) switching to the very fast and cryptographically strong SipHash-2-4
  hash MAC algorithm to protect the SYN cookie against forgery.

The patch had been reviewed by dwmalone (cookies) and cperciva (siphash).

Please find it here for testing:

   http://people.freebsd.org/~andre/syncookie-20130708.diff


I've been using the patch for a couple of days and didn't notice any
issues so far. Privoxy's regression tests continue to work as expected
as well.


Thanks for testing and reporting back.

Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1
as well to bypass the syn cache entirely?

It will give a bit of debug log output which is it telling you mostly about
rounding to the next nearest index value.  You can send the output privately
to me to spot unexpected outliers, if any.


BTW, I think kern/173309 could be closed.


OK.

--
Andre

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

Re: Improved SYN Cookies: Looking for testers

[Fabian Keil]

Andre Oppermann  wrote:

> On 10.07.2013 15:18, Fabian Keil wrote:
> > Andre Oppermann  wrote:
> >
> >> We have a SYN cookie implementation for quite some time now but it
> >> has some limitations with current realities for window scaling and
> >> SACK encoding the in the few available bits.
[...]
> >>http://people.freebsd.org/~andre/syncookie-20130708.diff
> >
> > I've been using the patch for a couple of days and didn't notice any
> > issues so far. Privoxy's regression tests continue to work as expected
> > as well.
> 
> Thanks for testing and reporting back.
> 
> Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1
> as well to bypass the syn cache entirely?

I haven't noticed any issues with net.inet.tcp.syncookies_only=1.

> It will give a bit of debug log output which is it telling you mostly about
> rounding to the next nearest index value.  You can send the output privately
> to me to spot unexpected outliers, if any.

One unexpected outlier seems to be:

Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 
tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 27 bytes of data 
after socket was closed, sending RST and removing tcpcb
Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 
tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE 
authentication, segment rejected (probably spoofed)

This also seems to have resulted in two reset packets:

fk@r500 ~/test/wireshark $tcpdump -vv -n -r syncookie-test.pcap  dst port 62972
reading from file syncookie-test.pcap, link-type NULL (BSD loopback)
12:42:47.033832 IP (tos 0x0, ttl 64, id 17522, offset 0, flags [DF], proto TCP 
(6), length 60, bad cksum 0 (->e248)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [S.], cksum 0x8c5f (correct), seq 
1633309846, ack 61471870, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS 
val 4243589075 ecr 4051741531], length 0
12:42:47.138107 IP (tos 0x0, ttl 64, id 17582, offset 0, flags [DF], proto TCP 
(6), length 52, bad cksum 0 (->e214)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xef2f (correct), seq 1, 
ack 183, win 1275, options [nop,nop,TS val 4243589180 ecr 4051741536], length 0
12:42:47.785762 IP (tos 0x0, ttl 64, id 17592, offset 0, flags [DF], proto TCP 
(6), length 120, bad cksum 0 (->e1c6)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x7209 (correct), seq 
1:69, ack 183, win 1275, options [nop,nop,TS val 4243589827 ecr 4051741536], 
length 68
12:42:47.945156 IP (tos 0x0, ttl 64, id 17609, offset 0, flags [DF], proto TCP 
(6), length 52, bad cksum 0 (->e1f9)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xe80f (correct), seq 69, 
ack 325, win 1275, options [nop,nop,TS val 4243589987 ecr 4051742343], length 0
12:42:48.470035 IP (tos 0x0, ttl 64, id 17678, offset 0, flags [DF], proto TCP 
(6), length 550, bad cksum 0 (->dfc2)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x3ce0 (correct), seq 
69:567, ack 325, win 1275, options [nop,nop,TS val 4243590511 ecr 4051742343], 
length 498
12:42:48.599754 IP (tos 0x0, ttl 64, id 17683, offset 0, flags [DF], proto TCP 
(6), length 550, bad cksum 0 (->dfbd)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x0a10 (correct), seq 
567:1065, ack 325, win 1275, options [nop,nop,TS val 4243590641 ecr 
4051743067], length 498
12:42:48.699161 IP (tos 0x0, ttl 64, id 17688, offset 0, flags [DF], proto TCP 
(6), length 2465, bad cksum 0 (->d83d)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x92bd (correct), seq 
1065:3478, ack 325, win 1275, options [nop,nop,TS val 4243590741 ecr 
4051743197], length 2413
12:42:48.824428 IP (tos 0x0, ttl 64, id 17706, offset 0, flags [DF], proto TCP 
(6), length 52, bad cksum 0 (->e198)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xd2da (correct), seq 
3478, ack 592, win 1275, options [nop,nop,TS val 4243590867 ecr 4051743216], 
length 0
12:42:48.924148 IP (tos 0x0, ttl 64, id 17713, offset 0, flags [DF], proto TCP 
(6), length 52, bad cksum 0 (->e191)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xd1dd (correct), seq 
3478, ack 639, win 1275, options [nop,nop,TS val 4243590966 ecr 4051743323], 
length 0
12:42:49.725732 IP (tos 0x0, ttl 64, id 17769, offset 0, flags [DF], proto TCP 
(6), length 99, bad cksum 0 (->e12a)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x7969 (correct), seq 
3478:3525, ack 639, win 1275, options [nop,nop,TS val 4243591767 ecr 
4051743323], length 47
12:42:49.833378 IP (tos 0x0, ttl 64, id 17784, offset 0, flags [DF], proto TCP 
(6), length 52, bad cksum 0 (->e14a)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [.], cksum 0xc9a7 (correct), seq 
3525, ack 882, win 1275, options [nop,nop,TS val 4243591876 ecr 4051744225], 
length 0
12:42:50.436702 IP (tos 0x0, ttl 64, id 17801, offset 0, flags [DF], proto TCP 
(6), length 550, bad cksum 0 (->df47)!)
10.0.0.1.8118 > 10.0.0.1.62972: Flags [P.], cksum 0x3f05 (correct), seq 
3525:4023, ack 882, win 1275,

Re: Improved SYN Cookies: Looking for testers

[Andre Oppermann]

On 12.07.2013 12:56, Fabian Keil wrote:

Andre Oppermann  wrote:


On 10.07.2013 15:18, Fabian Keil wrote:

Andre Oppermann  wrote:


We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few available bits.

[...]

http://people.freebsd.org/~andre/syncookie-20130708.diff


I've been using the patch for a couple of days and didn't notice any
issues so far. Privoxy's regression tests continue to work as expected
as well.


Thanks for testing and reporting back.

Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1
as well to bypass the syn cache entirely?


I haven't noticed any issues with net.inet.tcp.syncookies_only=1.


Excellent.


It will give a bit of debug log output which is it telling you mostly about
rounding to the next nearest index value.  You can send the output privately
to me to spot unexpected outliers, if any.


One unexpected outlier seems to be:


Both errors are normal and a sign of lazy application behavior, not a TCP
error.


Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 
tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 27 bytes of data 
after socket was closed, sending RST and removing tcpcb


This error is not uncommon and happens when the server side has closed the
socket (and sent FIN) while the client side is still trying to send data.
As the server has closed the socket we can't the deliver the data anymore
and respond with a reset to let the client know.  It typically happens with
web servers and short keep-alive timeouts.


Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 
tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE 
authentication, segment rejected (probably spoofed)


This is the same situation after the previous line but after the inpcb was
cleared.  Now a second, final (because of the FIN), in-flight packet from
the client arrives at the listen socket because the original inpcb is gone
now.  Since there isn't a matching SYN cache entry it falls back to check
for a syn cookie which obviously fails.  Having a FIN segment reach syncache
is unusual but not wrong.  In theory one could send a SYN, receive the SYN-ACK
and respond with ACK-FIN in one packet if it carried all data to be sent and
the application did a socket write shutdown already.


Client and server are running on the same system.

As I don't usually use net.inet.tcp.log_debug and haven't been able to 
intentionally
reproduce the issue (but have seen it a few times), I'm not sure yet if the 
behaviour
is actually related to the SYN cookie changes at all.


It's "normal" behavior and not related to the SYN cookie changes.

--
Andre

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

Re: Improved SYN Cookies: Looking for testers

[Fabian Keil]

Andre Oppermann  wrote:

> On 12.07.2013 12:56, Fabian Keil wrote:
> > Andre Oppermann  wrote:
> >
> >> On 10.07.2013 15:18, Fabian Keil wrote:
> >>> Andre Oppermann  wrote:
 
> >> It will give a bit of debug log output which is it telling you mostly about
> >> rounding to the next nearest index value.  You can send the output 
> >> privately
> >> to me to spot unexpected outliers, if any.
> >
> > One unexpected outlier seems to be:
> 
> Both errors are normal and a sign of lazy application behavior, not a TCP
> error.

Thanks for the explanation. Makes sense.

Fabian


signature.asc
Description: PGP signature

Re: Looking for testers for if_dc patches

[Bernd Walter]

On Tue, May 30, 2000 at 12:28:25AM -0700, Bill Paul wrote:
> Several people have reported problems with if_dc botching autonegotiation
> on 21143 NICs with non-MII media, such as the DEC/Compaq DE500-BA and
> the built-in 10/100 ethernet on some alphas. As my first official act
> as a BSDi/WC employee, I sat down and tried to fix this. I produced
> some patches for if_dc.c/if_dcreg.h and dcphy.c, which are sitting at
> http://people.freebsd.org/~wpaul/dc_test. To apply them, do the following:

[...]
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing 
-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi -g 
-nostdinc -I- -I. -I../.. -I../../../include  -D_KERNEL -include opt_global.h -elf  
-mno-fp-regs -ffixed-8 -Wa,-mev56  ../../pci/if_dc.c
../../pci/if_dc.c: In function `dc_init':
../../pci/if_dc.c:2697: structure has no member named `dc_flgs'
*** Error code 1

Stop in /var/d7/src-2000-05-28/src/sys/compile/CICELY9.

This is on 5.0-CURRENT as of 28th May on alpha

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Bill Paul]

> On Tue, May 30, 2000 at 12:28:25AM -0700, Bill Paul wrote:
> > Several people have reported problems with if_dc botching autonegotiation
> > on 21143 NICs with non-MII media, such as the DEC/Compaq DE500-BA and
> > the built-in 10/100 ethernet on some alphas. As my first official act
> > as a BSDi/WC employee, I sat down and tried to fix this. I produced
> > some patches for if_dc.c/if_dcreg.h and dcphy.c, which are sitting at
> > http://people.freebsd.org/~wpaul/dc_test. To apply them, do the following:
> 
> [...]
> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing 
>-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi -g 
>-nostdinc -I- -I. -I../.. -I../../../include  -D_KERNEL -include opt_global.h -elf  
>-mno-fp-regs -ffixed-8 -Wa,-mev56  ../../pci/if_dc.c
> ../../pci/if_dc.c: In function `dc_init':
> ../../pci/if_dc.c:2697: structure has no member named `dc_flgs'
> *** Error code 1
> 
> Stop in /var/d7/src-2000-05-28/src/sys/compile/CICELY9.
> 
> This is on 5.0-CURRENT as of 28th May on alpha

Grrr. Typo on my part, sorry. It should be flags, not flgs. I just fixed
the patch file. You can download it again, or just correct the typo manually.

-Bill
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[John Polstra]

In article <[EMAIL PROTECTED]>,
Bill Paul <[EMAIL PROTECTED]> wrote:
> Several people have reported problems with if_dc botching autonegotiation
> on 21143 NICs with non-MII media, such as the DEC/Compaq DE500-BA and
> the built-in 10/100 ethernet on some alphas. As my first official act
> as a BSDi/WC employee, I sat down and tried to fix this. I produced
> some patches for if_dc.c/if_dcreg.h and dcphy.c, which are sitting at
> http://people.freebsd.org/~wpaul/dc_test.

I was one of the people having problems before.  These patches have
made it work great in my case.  It autonegotiates properly at boot-up.
It also comes back correctly if I unplug the cable and plug it back in
again.  Thanks for working on it, Bill!

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Wilko Bulte]

On Tue, May 30, 2000 at 09:29:46AM -0700, Bill Paul wrote:
> > On Tue, May 30, 2000 at 12:28:25AM -0700, Bill Paul wrote:
> > > Several people have reported problems with if_dc botching autonegotiation
> > > on 21143 NICs with non-MII media, such as the DEC/Compaq DE500-BA and
> > > the built-in 10/100 ethernet on some alphas. As my first official act
> > > as a BSDi/WC employee, I sat down and tried to fix this. I produced
> > > some patches for if_dc.c/if_dcreg.h and dcphy.c, which are sitting at
> > > http://people.freebsd.org/~wpaul/dc_test. To apply them, do the following:
> > 
> > [...]
> > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing 
>-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi -g 
>-nostdinc -I- -I. -I../.. -I../../../include  -D_KERNEL -include opt_global.h -elf  
>-mno-fp-regs -ffixed-8 -Wa,-mev56  ../../pci/if_dc.c
> > ../../pci/if_dc.c: In function `dc_init':
> > ../../pci/if_dc.c:2697: structure has no member named `dc_flgs'
> > *** Error code 1
> > 
> > Stop in /var/d7/src-2000-05-28/src/sys/compile/CICELY9.
> > 
> > This is on 5.0-CURRENT as of 28th May on alpha
> 
> Grrr. Typo on my part, sorry. It should be flags, not flgs. I just fixed
> the patch file. You can download it again, or just correct the typo manually.

Hi Bill,

I applied your patches to -current without incidents. 

I have a testbox (Digital dual P6) that gives:

May 31 10:56:38 p6 /kernel: dc0:  port
0xec00-0xec7f m
em 0xfdfffc00-0xfdfffc7f irq 9 at device 3.0 on pci0
May 31 10:56:38 p6 /kernel: dc0: Ethernet address: 00:00:f8:75:3c:6a 
May 31 10:56:38 p6 /kernel: miibus0:  on dc0
May 31 10:56:38 p6 /kernel: dcphy0:  on
miibus
0
May 31 10:56:38 p6 /kernel: dcphy0:  10baseT, 10baseT-FDX, 100baseTX,
100baseTX-
FDX, auto
May 31 10:56:38 p6 /kernel: dc0: supplying EUI64: 00:00:f8:ff:fe:75:3c:6a
May 31 10:56:38 p6 /kernel: isab0:  at
device 7
...
May 31 10:56:39 p6 /kernel: dc0: starting DAD for
fe80:0001::0200:f8ff:fe75:3c6a
May 31 10:56:39 p6 /kernel: dc0: DAD complete for
fe80:0001::0200:f8ff:fe75:3c6a
 - no duplicates found
May 31 10:56:43 p6 /kernel: dc0: watchdog timeout
May 31 10:57:18 p6 last message repeated 3 times
May 31 10:57:58 p6 /kernel: dc0: watchdog timeout
May 31 10:58:53 p6 login: ROOT LOGIN (root) ON ttyv0
May 31 10:58:56 p6 login: ROOT LOGIN (root) ON ttyv0
May 31 10:59:57 p6 /kernel: dc0: watchdog timeout
May 31 11:03:27 p6 /kernel: dc0: watchdog timeout

This box can also house an Alpha Miata MX5 mainboard, the Intel & Alpha
boards use the same PCI riser card that also contains the 21143 chip. 
The patches don't seem to help on this particular hardware. I will try
to give the Alpha a spin too, later today. BTW: ifconfig-ing to use
10baseT/UTP does not help either. The media bulkhead is a 10baseT/10base2
one. if_de has no problems:

May 31 11:12:21 p6 /kernel: de0:  port
0xec00-0xec7
f mem 0xfdfffc00-0xfdfffc7f irq 9 at device 3.0 on pci0
May 31 11:12:21 p6 /kernel: de0: DEC 21142 [10-100Mb/s] pass 1.1
May 31 11:12:21 p6 /kernel: de0: address 00:00:f8:75:3c:6a
May 31 11:12:21 p6 /kernel: de0: supplying EUI64: 00:00:f8:ff:fe:75:3c:6a
May 31 11:12:21 p6 /kernel: isab0:  at
device 
...
May 31 11:12:21 p6 /kernel: de0: enabling 10baseT port

Rather than repeating please see also:

To: FreeBSD-alpha mailing list <[EMAIL PROTECTED]>
Subject: dc driver for embedded ethernet on Miata MX5 problems
Message-ID: <[EMAIL PROTECTED]>

and PR:

alpha/17833: dc driver for embedded ethernet on Miata MX5 problems

Thanks for your efforts, please let me know if you want me to try something
particular. 

-- 
Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Wilko Bulte]

Just to see if if_dc has kept working on a machine that had it working
before (Alpha Miata GL): works just fine with the patches applied.

Wilko
[goes back to digging up the Miata MX5]
-- 
Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Bernd Walter]

On Wed, May 31, 2000 at 12:30:51PM +0200, Wilko Bulte wrote:
> On Tue, May 30, 2000 at 09:29:46AM -0700, Bill Paul wrote:
> May 31 10:56:38 p6 /kernel: dc0:  port
> 0xec00-0xec7f m
> em 0xfdfffc00-0xfdfffc7f irq 9 at device 3.0 on pci0
> May 31 10:56:38 p6 /kernel: dc0: Ethernet address: 00:00:f8:75:3c:6a 
> May 31 10:56:38 p6 /kernel: miibus0:  on dc0
> May 31 10:56:38 p6 /kernel: dcphy0:  on
> miibus
> 0
> May 31 10:56:38 p6 /kernel: dcphy0:  10baseT, 10baseT-FDX, 100baseTX,
> 100baseTX-
> FDX, auto

Similar here on alpha with Adaptec 6911A without the watchdog timeouts.
But after rereading the original mail I asume I'm on the wrong train as my card
has an additional tranceiver which is not detected and the patch is for
the internal one.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Wilko Bulte]

On Wed, May 31, 2000 at 12:30:51PM +0200, Wilko Bulte wrote:
> On Tue, May 30, 2000 at 09:29:46AM -0700, Bill Paul wrote:
> > > On Tue, May 30, 2000 at 12:28:25AM -0700, Bill Paul wrote:
> > > > Several people have reported problems with if_dc botching autonegotiation
> > > > on 21143 NICs with non-MII media, such as the DEC/Compaq DE500-BA and
> > > > the built-in 10/100 ethernet on some alphas. As my first official act
> > > > as a BSDi/WC employee, I sat down and tried to fix this. I produced
> > > > some patches for if_dc.c/if_dcreg.h and dcphy.c, which are sitting at
> > > > http://people.freebsd.org/~wpaul/dc_test. To apply them, do the following:
> > > 
> > > [...]

> boards use the same PCI riser card that also contains the 21143 chip. 
> The patches don't seem to help on this particular hardware. I will try
> to give the Alpha a spin too, later today. BTW: ifconfig-ing to use

I finally got around to try the Miata MX5. In short: the problem is the same
as on the x86. The de driver works OK.

-- 
Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Bill Paul]

> Hi Bill,
> 
> I applied your patches to -current without incidents. 
> 
> I have a testbox (Digital dual P6) that gives:
> 
> May 31 10:56:38 p6 /kernel: dc0:  port
[...]
> May 31 11:03:27 p6 /kernel: dc0: watchdog timeout
> 
> This box can also house an Alpha Miata MX5 mainboard, the Intel & Alpha
> boards use the same PCI riser card that also contains the 21143 chip. 
> The patches don't seem to help on this particular hardware. I will try
> to give the Alpha a spin too, later today. BTW: ifconfig-ing to use
> 10baseT/UTP does not help either. The media bulkhead is a 10baseT/10base2
> one. if_de has no problems:

Alright, hold it. Stop. Just to make sure I understand:

- There's one interface involved here
- It has a 21143 chip
- It has 10baseT and AUI ports
- It's supposed to be 10Mbps only

If this is all correct, then I'd like you to try the following:

- Run pciconf -l on this machine and obtain the PCI ID for this device.
  The device ID is the hex number after the "chip=" section in the output.
  For the sake of this example, let's say it's 0x12345678.

- Bring up /sys/dev/mii/dcphy.c in your favorite editor.

- Look for the following code in the dcphy_attach() routine:

case COMPAQ_PRESARIO_ID:
/* Example of how to only allow 10Mbps modes. */
sc->mii_capabilities = BMSR_ANEG|BMSR_10TFDX|BMSR_10THDX;  
break;

- Add your PCI device ID like this:

case COMPAQ_PRESARIO_ID:
case 0x12345678:
/* Example of how to only allow 10Mbps modes. */
sc->mii_capabilities = BMSR_ANEG|BMSR_10TFDX|BMSR_10THDX;
break;

One thing I discovered is that trying to enable 100Mbps autoneg on
a device that only has a 10Mbps port doesn't work. This broke the
support for the 10Mbps ethernet in certain Compaq Presario machines,
which is why I special-cased it. This will not make the AUI port
work (I need to add extra code for that) but it if this is the same
problem as the Compaq, it should allow the 10baseT port to work.

Let me know if this has any effect.

-Bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Wilko Bulte]

On Thu, Jun 01, 2000 at 12:51:25PM -0700, Bill Paul wrote:

> > Hi Bill,
> > 
> > I applied your patches to -current without incidents. 
> > 
> > I have a testbox (Digital dual P6) that gives:
> > 
> > May 31 10:56:38 p6 /kernel: dc0:  port
> [...]
> > May 31 11:03:27 p6 /kernel: dc0: watchdog timeout
> > 
> > This box can also house an Alpha Miata MX5 mainboard, the Intel & Alpha
> > boards use the same PCI riser card that also contains the 21143 chip. 
> > The patches don't seem to help on this particular hardware. I will try
> > to give the Alpha a spin too, later today. BTW: ifconfig-ing to use
> > 10baseT/UTP does not help either. The media bulkhead is a 10baseT/10base2
> > one. if_de has no problems:
> 
> Alright, hold it. Stop. Just to make sure I understand:

Don't panic ;-) This is definitely a confusing piece of hardware.

> - There's one interface involved here

Correct.

> - It has a 21143 chip

Well, the de driver says 21142. The dc driver says 21143.

> - It has 10baseT and AUI ports

No, it has 10baseT and 10base2 (Cheapernet).

> - It's supposed to be 10Mbps only

With the current bulkhead yes. There is a replacement bulkhead in existence
that is 10baseT/100baseT capable. 

> If this is all correct, then I'd like you to try the following:
> 
> - Run pciconf -l on this machine and obtain the PCI ID for this device.
>   The device ID is the hex number after the "chip=" section in the output.
>   For the sake of this example, let's say it's 0x12345678.

For reference the ID reported is:

de0@pci0:3:0:  class=0x02 card=0x chip=0x00191011 rev=0x11 hdr=0x00

> - Bring up /sys/dev/mii/dcphy.c in your favorite editor.
> 
> - Look for the following code in the dcphy_attach() routine:
> 
> case COMPAQ_PRESARIO_ID:
> /* Example of how to only allow 10Mbps modes. */
> sc->mii_capabilities = BMSR_ANEG|BMSR_10TFDX|BMSR_10THDX;  
> break;
> 
> - Add your PCI device ID like this:
> 
> case COMPAQ_PRESARIO_ID:
>   case 0x12345678:
> /* Example of how to only allow 10Mbps modes. */
> sc->mii_capabilities = BMSR_ANEG|BMSR_10TFDX|BMSR_10THDX;
> break;
> 
> One thing I discovered is that trying to enable 100Mbps autoneg on
> a device that only has a 10Mbps port doesn't work. This broke the
> support for the 10Mbps ethernet in certain Compaq Presario machines,
> which is why I special-cased it. This will not make the AUI port
> work (I need to add extra code for that) but it if this is the same
> problem as the Compaq, it should allow the 10baseT port to work.

This one does not have AUI so that is not going to be a problem. What I do
wonder, though, is what will happen if a 10/100Mbit bulkhead is installed on
this machine. I don't expect the PCI ID to change (right?). I can pull
the 10/100 bulkhead from my Miata GL to give this a try.

In the meantime I gave your patch a quick try and I unfortunately don't
see a change in behaviour. Still watchdog timeouts and no connection.

Question: I had expected dmesg and ifconfig to report 10Mbit only modes.
They still show 100 as supported media in addition to the 10Mbit modes.

There is something else that might interest you: when replacing a 10 Mbit
only bulkhead with a 10/100 one you need to connect it to the PCI bulkhead
with a different cable to a different connector (on the PCI bulkhead). The
10/100 one is silkscreened as MII. 

Could this mean the driver sees a MII interface while in this particular
setup the bulkhead is connected to something non-MII ? Wild guess maybe..

Once again: very special hardware...

Thanks,
Wilko
-- 
Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Bill Paul]

> > - There's one interface involved here
> 
> Correct.
> 
> > - It has a 21143 chip
> 
> Well, the de driver says 21142. The dc driver says 21143.

It's just a difference in chip revision, really.
 
> This one does not have AUI so that is not going to be a problem. What I do
> wonder, though, is what will happen if a 10/100Mbit bulkhead is installed on
> this machine. I don't expect the PCI ID to change (right?). I can pull
> the 10/100 bulkhead from my Miata GL to give this a try.

It would help if you could look at both of them and tell me what chips
are on them. The 21143 can do 10Mbps all by itself, but for 100Mbps
you'd need an extra transceiver. I've been working under the assumption
that they're just using the built-in 10baseT port on the 21143, but
it's possible they're using the GPIO bits to do some funny business
to switch the ports.
 
> In the meantime I gave your patch a quick try and I unfortunately don't
> see a change in behaviour. Still watchdog timeouts and no connection.
> 
> Question: I had expected dmesg and ifconfig to report 10Mbit only modes.
> They still show 100 as supported media in addition to the 10Mbit modes.

You have to be able to tell that the chip only supports 10Mbps modes.
The 21143 is a 100Mbps chip, and only in certain cases do people design
10Mbps-only NICs around it. The problem is that to know if you've got
only 10Mbps, you normally have to slog through the SROM info, however a
lot of card vendors get this wrong, so I don't even bother with it.
 
> There is something else that might interest you: when replacing a 10 Mbit
> only bulkhead with a 10/100 one you need to connect it to the PCI bulkhead
> with a different cable to a different connector (on the PCI bulkhead). The
> 10/100 one is silkscreened as MII. 

Then it probably has a 10/100 PHY on it. Assuming the driver can probe
it without having to flip any magic GPIO bits, it should work.

> Could this mean the driver sees a MII interface while in this particular
> setup the bulkhead is connected to something non-MII ? Wild guess maybe..

I'm sure it is non-MII. It's still supposed to work, however it's hard
to tell just what I'm supposed to do to make it happy from way over here.

-Bill 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Bill Paul]

> 
> For reference the ID reported is:
> 
> de0@pci0:3:0:  class=0x02 card=0x chip=0x00191011 rev=0x11 hdr=0x00

Hm, ok. First of all, I made a mistake in what I told you. The code in
dcphy.c checks the subsystem ID, not the device ID. The device ID is always
the same, since that identifies the 21143 chip, however the subsystem ID
can vary from board to board depending on the manufacturer's whims.
The odd thing is that the subsystem ID here is 0x (the "card="
value), however that doesn't rule out running our test.

So, go back to dcphy.c and do this:
 
case COMPAQ_PRESARIO_ID:
case 0x:
   /* Example of how to only allow 10Mbps modes. */
   sc->mii_capabilities = BMSR_ANEG|BMSR_10TFDX|BMSR_10THDX;
   break;

Let me know if this has any effect.

-Bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Wilko Bulte]

On Fri, Jun 02, 2000 at 12:30:13AM -0700, Bill Paul wrote:
> > 
> > For reference the ID reported is:
> > 
> > de0@pci0:3:0:  class=0x02 card=0x chip=0x00191011 rev=0x11 hdr=0x00
> 
> Hm, ok. First of all, I made a mistake in what I told you. The code in
> dcphy.c checks the subsystem ID, not the device ID. The device ID is always
> the same, since that identifies the 21143 chip, however the subsystem ID
> can vary from board to board depending on the manufacturer's whims.
> The odd thing is that the subsystem ID here is 0x (the "card="
> value), however that doesn't rule out running our test.
> 
> So, go back to dcphy.c and do this:
>  
> case COMPAQ_PRESARIO_ID:
>   case 0x:
>/* Example of how to only allow 10Mbps modes. */
>sc->mii_capabilities = BMSR_ANEG|BMSR_10TFDX|BMSR_10THDX;
>break;
> 
> Let me know if this has any effect.

Unfortunately not. 

More data on this bulkhead:

It contains a black plastic module that calls itself:

ALL-IN-ONE
Ethernet COAX
TC3095
along with a 20Mc xtal oscillator. It looks like this is a selfcontained
DC-DC converter, pulse xformer and a 10base2 medium interface in 
a single module.

The cable connection to the PCI riser goes to a connector labeled "AUI".
My best guess is that this bulkhead is not much more than a 10baseT/10base2
transceiver in disguise, connected to an AUI interface.

I'm currently performing surgery on my other machine to see what the
10/100 bulkhead contains. 

-- 
Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Looking for testers for if_dc patches

[Wilko Bulte]

On Thu, Jun 01, 2000 at 04:32:42PM -0700, Bill Paul wrote:

> > > - It has a 21143 chip
> > 
> > Well, the de driver says 21142. The dc driver says 21143.
> 
> It's just a difference in chip revision, really.

OK.

> > This one does not have AUI so that is not going to be a problem. What I do
> > wonder, though, is what will happen if a 10/100Mbit bulkhead is installed on
> > this machine. I don't expect the PCI ID to change (right?). I can pull
> > the 10/100 bulkhead from my Miata GL to give this a try.
> 
> It would help if you could look at both of them and tell me what chips
> are on them. The 21143 can do 10Mbps all by itself, but for 100Mbps
> you'd need an extra transceiver. I've been working under the assumption
> that they're just using the built-in 10baseT port on the 21143, but
> it's possible they're using the GPIO bits to do some funny business
> to switch the ports.

The 10/100 bulkhead has two National Semiconductor chips, DP83840AVCE
and DP83223V

> You have to be able to tell that the chip only supports 10Mbps modes.
> The 21143 is a 100Mbps chip, and only in certain cases do people design
> 10Mbps-only NICs around it. The problem is that to know if you've got
> only 10Mbps, you normally have to slog through the SROM info, however a
> lot of card vendors get this wrong, so I don't even bother with it.
>  
> > There is something else that might interest you: when replacing a 10 Mbit
> > only bulkhead with a 10/100 one you need to connect it to the PCI bulkhead
> > with a different cable to a different connector (on the PCI bulkhead). The
> > 10/100 one is silkscreened as MII. 
> 
> Then it probably has a 10/100 PHY on it. Assuming the driver can probe
> it without having to flip any magic GPIO bits, it should work.

With the 10/100 in place I get a 100mbit connection (according to my hub's
LEDs) after powerup. After FreeBSD has booted (with the Compaq-like hack
in dcphy in place) I see the 100mbit LED of the hub switch off. But I don't
get a working 10mbit link either.

In the machine I borrowed the 10/100 from (a later model Miata GL) 100mbit
works like a charm with the dc driver.

On the Alphas there is also the SRM ewa speed select variable [ as if
this was not confusing enough ]. I tried setting ewa0_mode to both 10baseT
and 100baseT. In both cases there results were the same, no working link.

> I'm sure it is non-MII. It's still supposed to work, however it's hard
> to tell just what I'm supposed to do to make it happy from way over here.

Using the de driver I got a working connection and here is pciconf -l
with the 10/100 card installed:

bash-2.04# pciconf -l
de0@pci0:3:0:   class=0x02 card=0x chip=0x00191011 rev=0x11
hdr=0x00
none0@pci0:4:0: class=0x010180 card=0x chip=0x06461095 rev=0x01
hdr=0x00
isab0@pci0:7:0: class=0x00 card=0x chip=0x04848086 rev=0x43
hdr=0x00
pcib1@pci0:8:0: class=0x060400 card=0x chip=0x00241011 rev=0x01
hdr=0x01
isp0@pci0:11:0: class=0x01 card=0x53492050 chip=0x10201077 rev=0x05
hdr=0x00
none1@pci0:12:0:class=0x000100 card=0x chip=0x88d05333
rev=0x00 hdr=0x00

I don't think there is something relevant to be found that differs from the
10 mbit bulkhead.

There is something else that bothers me: I remove the 'device dc'
line from the kernel config file (leaving a device miibus and device xl in)
and adding 'device de'. config MX5, make depend && make && make install in
/sys/compile/MX5. reboot. Pang: kernel stack not valid, halt. When I do a 
config -r MX5 I can build a kernel that works/boots OK. Could it be that
there is something in the dependency for miibus? I don't recall that it
rebuilt the miibus module. And the 'kernel stack not valid' thing happens
just after the module loading message says "miibus". I don't pretend to
understand this to be honest. 

I hope the info above helps a bit, and does not add too much to the
confusion.

W/
-- 
Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

DRM in the sys/ tree: looking for testers

[Eric Anholt]

The DRM kernel modules (kernel support for 3d hardware acceleration
through the DRI) may be integrated into our sys tree soon.  I may be
getting a commit bit soon to work on this.  I think getting the modules
in the sys tree will help keep the DRI supported on FreeBSD even if I
become less active, and will help users by keeping the modules up to
date with their kernels.  It may also act as an incentive to keep me
working on the DRI when my patches may go in sooner.

So, I have been working over the last few days on integrating the
modules from drm-kmod-0.9.5 into the sys tree again, and have it almost
done.  The files are up at the website
. This also includes my
current set of code for mesa4 (XFree86 CVS, DRI CVS) and TCL (DRI CVS
tcl-0-0-1-branch) compatible DRM modules if anyone is interested in
experimenting, though they are much less tested.  For now instructions
on using it are on the news page of that website.

Could people test this in-kernel DRM and tell me how it works for them?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DRM in the sys/ tree: looking for testers

[Dag-Erling Smorgrav]

Eric Anholt <[EMAIL PROTECTED]> writes:
> Could people test this in-kernel DRM and tell me how it works for them?

Seems to work fine here (trusty ol' Matrox G200 w/8 MB).  Is there a
particular DRI application I can use to somehow stress-test or
benchmark the module?  I've gotten kind of tired of Aleph One :)

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: DRM in the sys/ tree: looking for testers

[Long, Scott]

> 
> Could people test this in-kernel DRM and tell me how it works 
> for them?

Works fine for me on a Matrox G400 with the standard Mesa apps, Linux Unreal
Tournament, and a custom build of Quake2 for FreeBSD.  Good work!

Scott
 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DRM in the sys/ tree: looking for testers

[Brandon D. Valentine]

On 18 Apr 2002, Dag-Erling Smorgrav wrote:

>Eric Anholt <[EMAIL PROTECTED]> writes:
>> Could people test this in-kernel DRM and tell me how it works for them?
>
>Seems to work fine here (trusty ol' Matrox G200 w/8 MB).  Is there a
>particular DRI application I can use to somehow stress-test or
>benchmark the module?  I've gotten kind of tired of Aleph One :)

No promises that this will compile or run on -current, but I suspect it
will.  This is _the_ OpenGL benchmark.

http://www.specbench.org/gpc/opc.static/vp50.htm

- Brandon D. Valentine


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DRM in the sys/ tree: looking for testers

[Brandon D. Valentine]

On Thu, 18 Apr 2002, Brandon D. Valentine wrote:

>http://www.specbench.org/gpc/opc.static/vp50.htm

This is probably a more useful URL:

http://www.specbench.org/gpc/opc.static/overview.htm

(thought I hit back before copying-and-pasting the URL, but I guess not)

- Brandon D. Valentine


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DRM in the sys/ tree: looking for testers

[Dag-Erling Smorgrav]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> Eric Anholt <[EMAIL PROTECTED]> writes:
> > Could people test this in-kernel DRM and tell me how it works for them?
> Seems to work fine here (trusty ol' Matrox G200 w/8 MB).  Is there a
> particular DRI application I can use to somehow stress-test or
> benchmark the module?  I've gotten kind of tired of Aleph One :)

OK, slight update here: anything that involves uploading textures
fails, and leaves DRI unusable until I restart the server.  For
instance, I can run the "gears" demo just fine, but if I run the
"fire" demo, I get lots of error messages about uploading textures,
and can't run the "gears" demo any more until I restart X.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DRM in the sys/ tree: looking for testers

[moto kawasaki]

Thank you very much,  Mr. Eric Anholt,

I have been testing your code on my PC, and found that kernel cannot
initialize agpgart device so far.

Environment:
Dell Latitude C400 (w/ Intel 82830 aka I830MG)
FreeBSD 4.5 STABLE (last cvsuped around 2002/Apr/24)
XFree86 4.2.0 (using /usr/ports/x11/XFree86-4/, cvsuped on the same day)
sysdrm-2002-04-21-tcldrm.tar.gz
sysdrm-2002-04-20-tclmodules.tar.gz
sysdrm-2002-04-20-tclstableconf.diff
  (following http://gladstone.uoregon.edu/~eanholt/dri/install.html)

Also, please find attached several configuration files and logs.

I myself am not an expert of neither FreeBSD kernel nor XFree86,
but I am eager to become a test monkey for saving my life :-)


Thank you very much.




Yours,


moto kawasaki <[EMAIL PROTECTED]>


H4sIA3RT62vbMBD/7EL+h4MU1kJipW6XlsA+pF3ahT4Ya0o+Ftm+xCKyZPTI47
/fSXZKx7ZgCDqffq8793snfXiYvcx+ze9gOIQHVGhEARs0CiUUWq3E2hvuhFawEhJhpQ3c
G8Tb1+9MXN6MCSBg3FO51gZBKOqo2wv0uErYeHEAjURuEQzyksoIFVdlrvUGLBZde0B6bK
nv/qC+JwQ76bjoVznXTBjb7XZpJybVZs2OkKzV38oftn9p5WrZISw+05NALq0GvuVC8pw8
Sl1wKQ/kBZi3htmKG2SlLj4IAohYwUH7L9vg2Tq6gK0v6oNSWGdE7oP4AWgqm50g81zu+M
GSYwytMbhWPiy1kSUsRYmwxJw6zBYNnP3H6HmcQwchuUPrPiefdj6nCnBfcW+dIJmSRIFe
gW5CD7lWZTuzEh1ZJ/m4byRXvH1NnR1BiVtRhPsK7UdcjUGLKtBG1yl7mr8s/rExKcxjUE
AZxtgUJeRzB9yC0/Fu402jKR2ypLBAa4U7BHoeKQdQVFhsCMxElxCIjg5Pu1QmYE3B7MHG
pWRBBuv2erCFizS7GqdZejWCbDTK2OiSZdcwyiYX40k2hrKE2b6B095J76TmRUWkSdItd7
8PReOTZE7H97ufb59LV3+Xvh5L7XF8PNJclUuSx+ly+jp9nAeevach2+QmsPZrvsFuLsn3
2e3bw7fhOkn6t17QVnRf4064CtZlfnZxTiPJ/Rrsoc61tBGBJBwHmzxPFz/eZ89vT9PFjF
BefdNo4+LO7G+uAWsv44B6vwEAAP//dFVNT6tAFF3rr5iXbjSxpkZt4uIteAxYYmEIQ02M
eWmgHRtSYHAYNPx77x1anardTcK53+ccTj9DgshLTwAb1FooeL9LtS3qzbfEiJoaWPw2hW
NXVVcXqx1hGiW1XJl+PgN8nyP8n1BbUYqe+Bnc0Ki5b7WoDpHLhDFoYgRP0rVGikASJaXe
U/B5K0RjTOXPfyuWMz9dxBSmhWojrzahmKWVL5p0zRoVQtphDVbcAmrSIJk5fIYzVTAB6K
QRyiiphoJA4rzYgJ4VmJRUhbCHC4fhQgEq6g+mOrwG3Q0GUGr0QxqpgQ9FVtrTWZmjIXMk
NN7heOroa2nRsaVdEPykxGsHQ6zt9jllfDcCPn+/i0vvptOJuTlnBN/H2xmw+45cOk5Y+K
2pCzKAfmsoTpg79BMriT5gDORnRyyMnXR5c401ZNUA/bCAkQda6c3lNXl+8LyYpLOAHxLF
5cGSenPn6e/V7WQyORlRUWY9OQNbqdpzkosXNETgQQ7kJwi36eKyiLM5SsopS/lOjILRxT
Yqy42VgfG0srRPueBeAnF+cA9hOZ5lvCJiXQCbLNRjwBfOfGmBR29F2wFBjoY8pInjerit
rVbZSqAt/KQ4f+KPfBYiDJ/jVvewK/NHA/f/YLNqmhqEgejZf7EzPagzOpaqZ4dCWzMWyZ
T60VMmLcFmLAWBOvrv3U1AgXppJ8tL2Ozy9j3z5fbQQTTroVNshXxT8HFQhw4BzOGTo8NV
KvMt1rEN5c5weC2cMTU3K/UXNAEyBLvLSqcK5QdZURK+tVE88DBir4IvWLhgy5WIvPuJ/4
QiMPtF4aT1Ai7G7qM/Z5jOYIGER/FIdQVrtBuFyndd6j6MfcEeo6U7nwvPnzyfDBoVR3ZS
AJCfhbUASCMzYWGZAc1pFE6IAl6P5QvT9z3mDkhWUjlcqJg+7MFfoQJORYLoO01VRQ4rOO
wqXX/mOJat62lvcTnzBAt7284ofA7sKqSULMFRq0ppmdgElIk0q3yj7QWmuyzPvyEu0A6U
f8+TeDM8kaitpbwDoxQsFFPfAV18AMoj/o7aaAOmTfYkGHZfnsROD+DUal07ga3EmMRyll
u9ljDX60JVyCLDYF2VsLqcgC8rCdwLPOZCYvK+MF4k259WRDxTdrnOPq0xMeJmXomuyzxL
MuIo0TjbK/KO7evaerhL17gg/Oeszr9VF8zguC4vdV2cm+6tEez8Ax5Z8G3n1M4CveK76T
JlQ4uj/iAo15u4AWGqnk+TtcH10sh10sYm3aZ3wD8AAAD//3RXy27CMBA88xc+JoeKtyiH
HtIEqUhAKeSObCclaSFBsXn9fWedGpIILoDiWbzZx+wsgZWugPEgvkHvtRh6G/RKSBUZUL
NrcK60Qzk77gW2BhILFFQiTZLvukACwI+NKxNBt02ma495H153NOixb75Pd9cmThqvPrze
GLKNspRnIucFsjX1R5fL5Z6vmt0+MnaYtMO+Px4NmBPGvwXfs8B/6Y87Tui6dYtUHcjia5
dv8U6PfMlkQYiFv2qjE0WaKzYjcB0FMfYQxZwsPkPLQ1ceVKyVWxuaLZDofLOeQL9sZkuw
3Of7ZDP3lm+dywBV2ipzY6YN3KBZw7WGRmW7eMvlla6zgWDnJM6YtRHYOkggmtCRKTGTle
fETo24RadbrTdPzvUHQj9DJvzZSSorJ83onv7jRhnDVG4cl+nBfvQrQOeLNPvhpsZe+o34
a1LMLJz7rPvq9zttfA47lZqErksP2MT4rtJbSoqjMhxLEPxmjlUm7h0VcYIERgUyTxpt4l
CvqgpIGdAa1v/azgJNU8VaVrDSVKkfVEiaK+PHEt86KfLjNrEN5pTys3SRmz91y/daedOA
kmp7DfMK8v0baiCyy5UxUkdRFWy3tPwBAAD//2xYwW7CMAz9lew6gco67bDThEqROCCqwi
puU0gzQE2ga0KBv58dF5pSLiCBncSO/fxejCvsSbJiS80r65bLBiybESzmvLRS0BL4X9c7
L23HW0BZSjaEDEin0RwkN2X+0nXV6oquc6ALF5cmJXH9QK5tJbXs7yX2lB3H9/680368ol
Z2w/1ZQh7i5QQqTVxTwCB0GDBggYolwL3CAD8fKmtP1+/v/SQdXFeEPDM2h97sG2h1aYOe
jKNPYMHP4MaeJdq9n7FjYyO44rmk8LgtNjjjmggNdTlecyGvhI54cfhDsgxCkPcwKf1B4t
x7YwrY0IORsyHzL5pgMEf41rDR5c2rWaP7hqHPTOot7zY+M6XiBpBJgHA/BPTFDDAC4LaA
j6f8OGycybLxuhqk1qie3BuL/OVAoG50myZWNWD4JqE3Coc+krRo0RLytuHb+O8hjRqcaK
Sje7XCRCZRtvqZpnGMugLLuRS1ZbUNQ7yDu/ToHsOjGnUHKu/zdA00P4tTh9PGE+fr27sP
yE4O27Snb32nIH2i73S5SJ23xWJ0xGmjjqJg4lQZlAk9srXbH4pkDLV+OqBux6cbu/vnw+
p5G4SB6F/xFjo0IUBVdciQkgwMiVCaoWMiwYAE2IKm4uf33dkYG5RuSPj5PjjuvTte5khk
i2+gzHalXhJxCSF6vfVxHeCcfKX7M0hrF5ET2efJ1l+vFbBsMQwUVnUiTzCiJNqTDfgVWg
4Hf0jzUNbX0zdq1cB5g6p+9FOZnvNvXWKxvjiXxKsY1DGccEDj1UHvtiDecRn3nRZ8V01I
u8TJzlgO+LjUJH5pA1AYKydrxdhO0/3lIAKtUJ3Jy3YsJMOT4E7dURChDisc4jIUlWzKBs
8FZtLQR22foaIJlQA1ptEQHnoiGCjArPzCEJfyKrlsATjo/OIhG0s8zFLdAqPl7ZyJKxnZ
w8YtFxQz6G0Biv8DJQz6MNm/d7RwrYWfc6VmSX533xmi97BPGb/W5JZ3zKi+qxgmWZNc03
yT5ULSH6vMrbOTqlqatBxt9z4EmXqGkoS5aJ96wQqFu1Fxp+h19WXiSFvltoQkytJ+PaNm
ZpDDMd3QPq+G9o22QzKI4Ha7PuD9aqVV6B8AAAD//2xZy1LCMBT9lbgqCxgSam3jjhZwOu
NrpCMuiaXUjBWc1Ef9e09ukEJxQ5ght7f3fc6lnTkNWeRjxjE/f5CS090f8HgQru7tr+bg
ciB5n47AijzCwqIhiX9fFI1FtfzNdiL0upvUQa92cOPrynYE4MK7bHrJ4gIVhjIGqNmtAA
vm7eDRm9YQ9hwNBGHfmlVBSHmnBZ9W81kbXCdBw3ineV++R17Mj704EuLcp0h8KaMxWpnd
zqlKv3ZZyNq504mR/dPGLsxrBoA/xLiJWS8aBUHYZ/aIOv59zzd/JGb8FkrQmIY8KbiVJW
uOBUzlUkZV

Re: DRM in the sys/ tree: looking for testers

[moto kawasaki]

Hi,

It is minor problem but when I added "options DRM_DEBUG" in my kernel
configuration file under /usr/src/sys/i386/conf/, I got the following
error.

cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstr
ict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fform
at-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contri
b/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2
../../dev/drm/i830_dma.c
../../dev/drm/i830_dma.c: In function `i830_getbuf':
../../dev/drm/i830_dma.c:1506: `current' undeclared (first use in this function)
../../dev/drm/i830_dma.c:1506: (Each undeclared identifier is reported only once
../../dev/drm/i830_dma.c:1506: for each function it appears in.)
*** Error Code 1

Stop in /usr/src/sys/compile/KAWASAKI

Thank you.

moto kawasaki <[EMAIL PROTECTED]>









From: moto kawasaki <[EMAIL PROTECTED]>
Subject: Re: DRM in the sys/ tree: looking for testers
Date: Fri, 26 Apr 2002 16:03:16 +0900 (JST)
Message-ID: <[EMAIL PROTECTED]>

kawasaki> 
kawasaki> Thank you very much,  Mr. Eric Anholt,
kawasaki> 
kawasaki> I have been testing your code on my PC, and found that kernel cannot
kawasaki> initialize agpgart device so far.
kawasaki> 
kawasaki> Environment:
kawasaki> Dell Latitude C400 (w/ Intel 82830 aka I830MG)
kawasaki> FreeBSD 4.5 STABLE (last cvsuped around 2002/Apr/24)
kawasaki> XFree86 4.2.0 (using /usr/ports/x11/XFree86-4/, cvsuped on the same day)
kawasaki> sysdrm-2002-04-21-tcldrm.tar.gz
kawasaki> sysdrm-2002-04-20-tclmodules.tar.gz
kawasaki> sysdrm-2002-04-20-tclstableconf.diff
kawasaki>   (following http://gladstone.uoregon.edu/~eanholt/dri/install.html)
kawasaki> 
kawasaki> Also, please find attached several configuration files and logs.
kawasaki> 
kawasaki> I myself am not an expert of neither FreeBSD kernel nor XFree86,
kawasaki> but I am eager to become a test monkey for saving my life :-)
kawasaki> 
kawasaki> 
kawasaki> Thank you very much.
kawasaki> 
kawasaki> 
kawasaki> 
kawasaki> 
kawasaki> Yours,
kawasaki> 
kawasaki> 
kawasaki> moto kawasaki <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DRM in the sys/ tree: looking for testers

[Eric Anholt]

On Fri, 2002-04-26 at 01:03, moto kawasaki wrote:
> 
> Thank you very much,  Mr. Eric Anholt,
> 
> I have been testing your code on my PC, and found that kernel cannot
> initialize agpgart device so far.

The i8x0 DRM drivers require AGP to be working.  I took a look at your
i830 patch today, and compared it to the linux kernel version.  I added
some more checks for invalid options (binding memory into offsets used
by the stolen memory), and added the enabling of the gatt that linux
does.  The only difference that I see between our drivers after this
diff is that linux forces enabling of the integrated graphics.

The diff is at http://gladstone.uoregon.edu/~eanholt/dri/i810diff

If we aren't sure how well the driver is working, testgart might help
for debugging without using X.  A copy of linux testgart from utah-glx
is at http://gladstone.uoregon.edu/~eanholt/dri/testgart.c



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message