Date: Sat, 27 Sep 1997 10:23:46 +0800 From: Peter Wemm <peter@netplex.com.au> To: uhclem@nemesis.lonestar.org (Frank Durda IV) Cc: peter@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4628 Message-ID: <199709270223.KAA03240@spinner.netplex.com.au> In-Reply-To: Your message of "Fri, 26 Sep 1997 11:25:00 CDT." <m0xEdCq-000twnC@nemesis.lonestar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Frank Durda IV wrote:
>
> [0]Synopsis: Device driver de won't accept "media" parameters to go Full Dupl
ex:FDIV071
> [0]
> [0]State-Changed-From-To: open-closed
> [0]State-Changed-By: peter
> [0]State-Changed-When: Fri Sep 26 05:42:01 PDT 1997
> [0]State-Changed-Why:
> [0]If one modifies a shell script (such as /etc/rc.conf) one should
> [0]understand basic shell quoting.
>
> Uh, I *wish* you would STOP closing my PRs without actually reading them.
>
> I WAS NOT REPORTING the "quoting issue" you are fixating on.
> I was reporting that EVEN FROM A COMMAND LINE, the ifconfig ifmedia option
> is not accepting any of the parameters the DE driver that is included
> in the 970921 release is supposed to accept. The quoting issue and the
> lack of supporting documentation was a FYI, assuming anyone cares about
> reducing user confusion with better documentation.
To be sure, here's what you wrote:
>> I then reverted to a completely stock 970921 setup (abandoning the add-on
>> DE driver), and changed rc.conf (small problem here since ifconfig media
>> command is documented as expecting parms in double quotes and the ifconfig
>> line in rc.conf is already in double quotes), and the setting was rejected
>> with the error:
>>
>> ifconfig: SIOCGIFMEDIA: Invalid argument
>>
>>
>> The argument I am trying to pass is "Full Duplex 10baseT", exactly
>> as it appears in the 970921 pci/if_de.c module. (The board in use
>> is a PCI adapter.) So I tried the other choices listed in the DE
>> driver and all return the same error message, even when entered from
>> the command line:
>> ifconfig de0 media "Full Duplex 10baseT"
>> ifconfig: SIOCGIFMEDIA: Invalid argument
>> ifconfig de0 media "10baseT"
>> ifconfig: SIOCGIFMEDIA: Invalid argument
>>
>> I can't tell that this "media" command works at all.
Hmm. You are right, I did misunderstand that part of
your report.
However, it would seem that you are trying to issue media commands to the
RELENG_2_2 de driver. It doesn't support ifmedia at all, just the link*
options. (which are not documented, and I am not sure what they are
myself in the 2.2 driver)
> [0]One way might be to do something like this:
> [0]ifconfig_de0="mumble -media 'foo bar'"
> [0]or
> [0]ifconfig_de0='mumble -media "foo bar"'
>
> Yeah, and may we please return to the real problem, in that it won't
> accept "foo bar", even though it is listed in the driver source code?
If you'd read the source code more, you'd discover that the strings you
are looking at are used for doing console printfs etc. They (in spite of
the 'MEDIA' string in the code) are not 'ifconfig media' strings.
> [0]To get the list of currently supported medias for a driver, use 'ifconfig
-m'.
>
> Ok, I missed this and will try it. Right at this second, it seems
> to simply give me the same thing "ifconfig de0" has always given me,
> no options.
Yep. It doesn't support any.. Granted, it should report that the media
options are not supported.
> [0]What you are probably after is:
> [0]ifconfig_de0="mumble media 10baseT/UTP mediaopt full-duplex"
> [0](or s/UTP/BNC/)
>
> Ok, is this documented? Doesn't say anything about breaking the string
> up that I see in the driver like this anywhere in the ifconfig man page.
> Also, how well does it work with no quotes (of any sort) around
> the options as you have in your example? :-) Mine gives me a usage error
> when I do that. :-)
It works just fine without quotes. The `` '' in man pages is man page
quoting, not indications of actual quote marks. It's done that way so
that we can put real quotes when needed.
For what it's worth, on a machine with a SMC9332BDT with a version of
Matt's driver:
peter@spinner[10:15am]~src/bin/rm-220# ifconfig -m de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 202.12.86.3 netmask 0xffffffe0 broadcast 202.12.86.31
inet 192.203.228.67 netmask 0xfffffff0 broadcast 192.203.228.79
ether 00:e0:29:06:48:ee
media: autoselect (10baseT/UTP) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
peter@spinner[10:15am]~src/bin/rm-221# ifconfig de0 media 100baseTX mediaopt full-duplex
peter@spinner[10:16am]~src/bin/rm-222# ifconfig -m de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 202.12.86.3 netmask 0xffffffe0 broadcast 202.12.86.31
inet 192.203.228.67 netmask 0xfffffff0 broadcast 192.203.228.79
ether 00:e0:29:06:48:ee
media: 100baseTX <full-duplex> status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
peter@spinner[10:16am]~src/bin/rm-223# ifconfig de0 media autoselect
peter@spinner[10:16am]~src/bin/rm-224# ifconfig -m de0
de0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> mtu 1500
inet 202.12.86.3 netmask 0xffffffe0 broadcast 202.12.86.31
inet 192.203.228.67 netmask 0xfffffff0 broadcast 192.203.228.79
ether 00:e0:29:06:48:ee
media: autoselect
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
peter@spinner[10:16am]~src/bin/rm-225#
Again, the media types and options would not be the same for all different
cards.
> [0]Here, with a SMC9332BDT, the choices are:
> [0]supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP
<full-duplex> 10baseT/UTP
> [0]
> [0]So, one can: ifconfig de0 media 100baseT mediaopt full-duplex
> [0]to override the autoselect setting.
>
> Ok, so no change, the problem remains. This does not work with the
> stock 970921 DE driver or the 970921 ifconfig utility.
Yes, the man page doesn't say that it does either. :-) Only matt's driver
uses ifmedia (and the current fxp driver).
> Please re-open the problem report unless you have actually tested the
> problem on the appropriate hardware and have fixed the missing/incorrect
> documentation. We are not Microsoft, we are supposed to actually do
> something with the problem reports, other than close them.
I'll change the documentation to make sure there is no possible room for
misinterpretation.
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709270223.KAA03240>