Back to home page

OSCL-LXR

 
 

    


0001 .. SPDX-License-Identifier: GPL-2.0
0002 
0003 ======
0004 ARCnet
0005 ======
0006 
0007 .. note::
0008 
0009    See also arcnet-hardware.txt in this directory for jumper-setting
0010    and cabling information if you're like many of us and didn't happen to get a
0011    manual with your ARCnet card.
0012 
0013 Since no one seems to listen to me otherwise, perhaps a poem will get your
0014 attention::
0015 
0016                 This driver's getting fat and beefy,
0017                 But my cat is still named Fifi.
0018 
0019 Hmm, I think I'm allowed to call that a poem, even though it's only two
0020 lines.  Hey, I'm in Computer Science, not English.  Give me a break.
0021 
0022 The point is:  I REALLY REALLY REALLY REALLY REALLY want to hear from you if
0023 you test this and get it working.  Or if you don't.  Or anything.
0024 
0025 ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
0026 nice, but after that even FEWER people started writing to me because they
0027 didn't even have to install the patch.  <sigh>
0028 
0029 Come on, be a sport!  Send me a success report!
0030 
0031 (hey, that was even better than my original poem... this is getting bad!)
0032 
0033 
0034 .. warning::
0035 
0036    If you don't e-mail me about your success/failure soon, I may be forced to
0037    start SINGING.  And we don't want that, do we?
0038 
0039    (You know, it might be argued that I'm pushing this point a little too much.
0040    If you think so, why not flame me in a quick little e-mail?  Please also
0041    include the type of card(s) you're using, software, size of network, and
0042    whether it's working or not.)
0043 
0044    My e-mail address is: apenwarr@worldvisions.ca
0045 
0046 These are the ARCnet drivers for Linux.
0047 
0048 This new release (2.91) has been put together by David Woodhouse
0049 <dwmw2@infradead.org>, in an attempt to tidy up the driver after adding support
0050 for yet another chipset. Now the generic support has been separated from the
0051 individual chipset drivers, and the source files aren't quite so packed with
0052 #ifdefs! I've changed this file a bit, but kept it in the first person from
0053 Avery, because I didn't want to completely rewrite it.
0054 
0055 The previous release resulted from many months of on-and-off effort from me
0056 (Avery Pennarun), many bug reports/fixes and suggestions from others, and in
0057 particular a lot of input and coding from Tomasz Motylewski.  Starting with
0058 ARCnet 2.10 ALPHA, Tomasz's all-new-and-improved RFC1051 support has been
0059 included and seems to be working fine!
0060 
0061 
0062 Where do I discuss these drivers?
0063 ---------------------------------
0064 
0065 Tomasz has been so kind as to set up a new and improved mailing list.
0066 Subscribe by sending a message with the BODY "subscribe linux-arcnet YOUR
0067 REAL NAME" to listserv@tichy.ch.uj.edu.pl.  Then, to submit messages to the
0068 list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
0069 
0070 There are archives of the mailing list at:
0071 
0072         http://epistolary.org/mailman/listinfo.cgi/arcnet
0073 
0074 The people on linux-net@vger.kernel.org (now defunct, replaced by
0075 netdev@vger.kernel.org) have also been known to be very helpful, especially
0076 when we're talking about ALPHA Linux kernels that may or may not work right
0077 in the first place.
0078 
0079 
0080 Other Drivers and Info
0081 ----------------------
0082 
0083 You can try my ARCNET page on the World Wide Web at:
0084 
0085         http://www.qis.net/~jschmitz/arcnet/
0086 
0087 Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
0088 might be interested in, which includes several drivers for various cards
0089 including ARCnet.  Try:
0090 
0091         http://www.smc.com/
0092 
0093 Performance Technologies makes various network software that supports
0094 ARCnet:
0095 
0096         http://www.perftech.com/ or ftp to ftp.perftech.com.
0097 
0098 Novell makes a networking stack for DOS which includes ARCnet drivers.  Try
0099 FTPing to ftp.novell.com.
0100 
0101 You can get the Crynwr packet driver collection (including arcether.com, the
0102 one you'll want to use with ARCnet cards) from
0103 oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
0104 without patches, though, and also doesn't like several cards.  Fixed
0105 versions are available on my WWW page, or via e-mail if you don't have WWW
0106 access.
0107 
0108 
0109 Installing the Driver
0110 ---------------------
0111 
0112 All you will need to do in order to install the driver is::
0113 
0114         make config
0115                 (be sure to choose ARCnet in the network devices
0116                 and at least one chipset driver.)
0117         make clean
0118         make zImage
0119 
0120 If you obtained this ARCnet package as an upgrade to the ARCnet driver in
0121 your current kernel, you will need to first copy arcnet.c over the one in
0122 the linux/drivers/net directory.
0123 
0124 You will know the driver is installed properly if you get some ARCnet
0125 messages when you reboot into the new Linux kernel.
0126 
0127 There are four chipset options:
0128 
0129  1. Standard ARCnet COM90xx chipset.
0130 
0131 This is the normal ARCnet card, which you've probably got. This is the only
0132 chipset driver which will autoprobe if not told where the card is.
0133 It following options on the command line::
0134 
0135  com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
0136 
0137 If you load the chipset support as a module, the options are::
0138 
0139  io=<io> irq=<irq> shmem=<shmem> device=<name>
0140 
0141 To disable the autoprobe, just specify "com90xx=" on the kernel command line.
0142 To specify the name alone, but allow autoprobe, just put "com90xx=<name>"
0143 
0144  2. ARCnet COM20020 chipset.
0145 
0146 This is the new chipset from SMC with support for promiscuous mode (packet
0147 sniffing), extra diagnostic information, etc. Unfortunately, there is no
0148 sensible method of autoprobing for these cards. You must specify the I/O
0149 address on the kernel command line.
0150 
0151 The command line options are::
0152 
0153  com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
0154 
0155 If you load the chipset support as a module, the options are::
0156 
0157  io=<io> irq=<irq> node=<node_ID> backplane=<backplane> clock=<CKP>
0158  timeout=<timeout> device=<name>
0159 
0160 The COM20020 chipset allows you to set the node ID in software, overriding the
0161 default which is still set in DIP switches on the card. If you don't have the
0162 COM20020 data sheets, and you don't know what the other three options refer
0163 to, then they won't interest you - forget them.
0164 
0165  3. ARCnet COM90xx chipset in IO-mapped mode.
0166 
0167 This will also work with the normal ARCnet cards, but doesn't use the shared
0168 memory. It performs less well than the above driver, but is provided in case
0169 you have a card which doesn't support shared memory, or (strangely) in case
0170 you have so many ARCnet cards in your machine that you run out of shmem slots.
0171 If you don't give the IO address on the kernel command line, then the driver
0172 will not find the card.
0173 
0174 The command line options are::
0175 
0176  com90io=<io>[,<irq>][,<name>]
0177 
0178 If you load the chipset support as a module, the options are:
0179  io=<io> irq=<irq> device=<name>
0180 
0181  4. ARCnet RIM I cards.
0182 
0183 These are COM90xx chips which are _completely_ memory mapped. The support for
0184 these is not tested. If you have one, please mail the author with a success
0185 report. All options must be specified, except the device name.
0186 Command line options::
0187 
0188  arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
0189 
0190 If you load the chipset support as a module, the options are::
0191 
0192  shmem=<shmem> irq=<irq> node=<node_ID> device=<name>
0193 
0194 
0195 Loadable Module Support
0196 -----------------------
0197 
0198 Configure and rebuild Linux.  When asked, answer 'm' to "Generic ARCnet
0199 support" and to support for your ARCnet chipset if you want to use the
0200 loadable module. You can also say 'y' to "Generic ARCnet support" and 'm'
0201 to the chipset support if you wish.
0202 
0203 ::
0204 
0205         make config
0206         make clean
0207         make zImage
0208         make modules
0209 
0210 If you're using a loadable module, you need to use insmod to load it, and
0211 you can specify various characteristics of your card on the command
0212 line.  (In recent versions of the driver, autoprobing is much more reliable
0213 and works as a module, so most of this is now unnecessary.)
0214 
0215 For example::
0216 
0217         cd /usr/src/linux/modules
0218         insmod arcnet.o
0219         insmod com90xx.o
0220         insmod com20020.o io=0x2e0 device=eth1
0221 
0222 
0223 Using the Driver
0224 ----------------
0225 
0226 If you build your kernel with ARCnet COM90xx support included, it should
0227 probe for your card automatically when you boot. If you use a different
0228 chipset driver complied into the kernel, you must give the necessary options
0229 on the kernel command line, as detailed above.
0230 
0231 Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
0232 available where you picked up this driver.  Think of your ARCnet as a
0233 souped-up (or down, as the case may be) Ethernet card.
0234 
0235 By the way, be sure to change all references from "eth0" to "arc0" in the
0236 HOWTOs.  Remember that ARCnet isn't a "true" Ethernet, and the device name
0237 is DIFFERENT.
0238 
0239 
0240 Multiple Cards in One Computer
0241 ------------------------------
0242 
0243 Linux has pretty good support for this now, but since I've been busy, the
0244 ARCnet driver has somewhat suffered in this respect. COM90xx support, if
0245 compiled into the kernel, will (try to) autodetect all the installed cards.
0246 
0247 If you have other cards, with support compiled into the kernel, then you can
0248 just repeat the options on the kernel command line, e.g.::
0249 
0250         LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
0251 
0252 If you have the chipset support built as a loadable module, then you need to
0253 do something like this::
0254 
0255         insmod -o arc0 com90xx
0256         insmod -o arc1 com20020 io=0x2e0
0257         insmod -o arc2 com90xx
0258 
0259 The ARCnet drivers will now sort out their names automatically.
0260 
0261 
0262 How do I get it to work with...?
0263 --------------------------------
0264 
0265 NFS:
0266         Should be fine linux->linux, just pretend you're using Ethernet cards.
0267         oak.oakland.edu:/simtel/msdos/nfs has some nice DOS clients.  There
0268         is also a DOS-based NFS server called SOSS.  It doesn't multitask
0269         quite the way Linux does (actually, it doesn't multitask AT ALL) but
0270         you never know what you might need.
0271 
0272         With AmiTCP (and possibly others), you may need to set the following
0273         options in your Amiga nfstab:  MD 1024 MR 1024 MW 1024
0274         (Thanks to Christian Gottschling <ferksy@indigo.tng.oche.de>
0275         for this.)
0276 
0277         Probably these refer to maximum NFS data/read/write block sizes.  I
0278         don't know why the defaults on the Amiga didn't work; write to me if
0279         you know more.
0280 
0281 DOS:
0282         If you're using the freeware arcether.com, you might want to install
0283         the driver patch from my web page.  It helps with PC/TCP, and also
0284         can get arcether to load if it timed out too quickly during
0285         initialization.  In fact, if you use it on a 386+ you REALLY need
0286         the patch, really.
0287 
0288 Windows:
0289         See DOS :)  Trumpet Winsock works fine with either the Novell or
0290         Arcether client, assuming you remember to load winpkt of course.
0291 
0292 LAN Manager and Windows for Workgroups:
0293         These programs use protocols that
0294         are incompatible with the Internet standard.  They try to pretend
0295         the cards are Ethernet, and confuse everyone else on the network.
0296 
0297         However, v2.00 and higher of the Linux ARCnet driver supports this
0298         protocol via the 'arc0e' device.  See the section on "Multiprotocol
0299         Support" for more information.
0300 
0301         Using the freeware Samba server and clients for Linux, you can now
0302         interface quite nicely with TCP/IP-based WfWg or Lan Manager
0303         networks.
0304 
0305 Windows 95:
0306         Tools are included with Win95 that let you use either the LANMAN
0307         style network drivers (NDIS) or Novell drivers (ODI) to handle your
0308         ARCnet packets.  If you use ODI, you'll need to use the 'arc0'
0309         device with Linux.  If you use NDIS, then try the 'arc0e' device.
0310         See the "Multiprotocol Support" section below if you need arc0e,
0311         you're completely insane, and/or you need to build some kind of
0312         hybrid network that uses both encapsulation types.
0313 
0314 OS/2:
0315         I've been told it works under Warp Connect with an ARCnet driver from
0316         SMC.  You need to use the 'arc0e' interface for this.  If you get
0317         the SMC driver to work with the TCP/IP stuff included in the
0318         "normal" Warp Bonus Pack, let me know.
0319 
0320         ftp.microsoft.com also has a freeware "Lan Manager for OS/2" client
0321         which should use the same protocol as WfWg does.  I had no luck
0322         installing it under Warp, however.  Please mail me with any results.
0323 
0324 NetBSD/AmiTCP:
0325         These use an old version of the Internet standard ARCnet
0326         protocol (RFC1051) which is compatible with the Linux driver v2.10
0327         ALPHA and above using the arc0s device. (See "Multiprotocol ARCnet"
0328         below.)  ** Newer versions of NetBSD apparently support RFC1201.
0329 
0330 
0331 Using Multiprotocol ARCnet
0332 --------------------------
0333 
0334 The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
0335 "virtual network device":
0336 
0337         ======  ===============================================================
0338         arc0    RFC1201 protocol, the official Internet standard which just
0339                 happens to be 100% compatible with Novell's TRXNET driver.
0340                 Version 1.00 of the ARCnet driver supported _only_ this
0341                 protocol.  arc0 is the fastest of the three protocols (for
0342                 whatever reason), and allows larger packets to be used
0343                 because it supports RFC1201 "packet splitting" operations.
0344                 Unless you have a specific need to use a different protocol,
0345                 I strongly suggest that you stick with this one.
0346 
0347         arc0e   "Ethernet-Encapsulation" which sends packets over ARCnet
0348                 that are actually a lot like Ethernet packets, including the
0349                 6-byte hardware addresses.  This protocol is compatible with
0350                 Microsoft's NDIS ARCnet driver, like the one in WfWg and
0351                 LANMAN.  Because the MTU of 493 is actually smaller than the
0352                 one "required" by TCP/IP (576), there is a chance that some
0353                 network operations will not function properly.  The Linux
0354                 TCP/IP layer can compensate in most cases, however, by
0355                 automatically fragmenting the TCP/IP packets to make them
0356                 fit.  arc0e also works slightly more slowly than arc0, for
0357                 reasons yet to be determined.  (Probably it's the smaller
0358                 MTU that does it.)
0359 
0360         arc0s   The "[s]imple" RFC1051 protocol is the "previous" Internet
0361                 standard that is completely incompatible with the new
0362                 standard.  Some software today, however, continues to
0363                 support the old standard (and only the old standard)
0364                 including NetBSD and AmiTCP.  RFC1051 also does not support
0365                 RFC1201's packet splitting, and the MTU of 507 is still
0366                 smaller than the Internet "requirement," so it's quite
0367                 possible that you may run into problems.  It's also slower
0368                 than RFC1201 by about 25%, for the same reason as arc0e.
0369 
0370                 The arc0s support was contributed by Tomasz Motylewski
0371                 and modified somewhat by me.  Bugs are probably my fault.
0372         ======  ===============================================================
0373 
0374 You can choose not to compile arc0e and arc0s into the driver if you want -
0375 this will save you a bit of memory and avoid confusion when eg. trying to
0376 use the "NFS-root" stuff in recent Linux kernels.
0377 
0378 The arc0e and arc0s devices are created automatically when you first
0379 ifconfig the arc0 device.  To actually use them, though, you need to also
0380 ifconfig the other virtual devices you need.  There are a number of ways you
0381 can set up your network then:
0382 
0383 
0384 1. Single Protocol.
0385 
0386    This is the simplest way to configure your network: use just one of the
0387    two available protocols.  As mentioned above, it's a good idea to use
0388    only arc0 unless you have a good reason (like some other software, ie.
0389    WfWg, that only works with arc0e).
0390 
0391    If you need only arc0, then the following commands should get you going::
0392 
0393         ifconfig arc0 MY.IP.ADD.RESS
0394         route add MY.IP.ADD.RESS arc0
0395         route add -net SUB.NET.ADD.RESS arc0
0396         [add other local routes here]
0397 
0398    If you need arc0e (and only arc0e), it's a little different::
0399 
0400         ifconfig arc0 MY.IP.ADD.RESS
0401         ifconfig arc0e MY.IP.ADD.RESS
0402         route add MY.IP.ADD.RESS arc0e
0403         route add -net SUB.NET.ADD.RESS arc0e
0404 
0405    arc0s works much the same way as arc0e.
0406 
0407 
0408 2. More than one protocol on the same wire.
0409 
0410    Now things start getting confusing.  To even try it, you may need to be
0411    partly crazy.  Here's what *I* did. :) Note that I don't include arc0s in
0412    my home network; I don't have any NetBSD or AmiTCP computers, so I only
0413    use arc0s during limited testing.
0414 
0415    I have three computers on my home network; two Linux boxes (which prefer
0416    RFC1201 protocol, for reasons listed above), and one XT that can't run
0417    Linux but runs the free Microsoft LANMAN Client instead.
0418 
0419    Worse, one of the Linux computers (freedom) also has a modem and acts as
0420    a router to my Internet provider.  The other Linux box (insight) also has
0421    its own IP address and needs to use freedom as its default gateway.  The
0422    XT (patience), however, does not have its own Internet IP address and so
0423    I assigned it one on a "private subnet" (as defined by RFC1597).
0424 
0425    To start with, take a simple network with just insight and freedom.
0426    Insight needs to:
0427 
0428         - talk to freedom via RFC1201 (arc0) protocol, because I like it
0429           more and it's faster.
0430         - use freedom as its Internet gateway.
0431 
0432    That's pretty easy to do.  Set up insight like this::
0433 
0434         ifconfig arc0 insight
0435         route add insight arc0
0436         route add freedom arc0  /* I would use the subnet here (like I said
0437                                         to in "single protocol" above),
0438                                         but the rest of the subnet
0439                                         unfortunately lies across the PPP
0440                                         link on freedom, which confuses
0441                                         things. */
0442         route add default gw freedom
0443 
0444    And freedom gets configured like so::
0445 
0446         ifconfig arc0 freedom
0447         route add freedom arc0
0448         route add insight arc0
0449         /* and default gateway is configured by pppd */
0450 
0451    Great, now insight talks to freedom directly on arc0, and sends packets
0452    to the Internet through freedom.  If you didn't know how to do the above,
0453    you should probably stop reading this section now because it only gets
0454    worse.
0455 
0456    Now, how do I add patience into the network?  It will be using LANMAN
0457    Client, which means I need the arc0e device.  It needs to be able to talk
0458    to both insight and freedom, and also use freedom as a gateway to the
0459    Internet.  (Recall that patience has a "private IP address" which won't
0460    work on the Internet; that's okay, I configured Linux IP masquerading on
0461    freedom for this subnet).
0462 
0463    So patience (necessarily; I don't have another IP number from my
0464    provider) has an IP address on a different subnet than freedom and
0465    insight, but needs to use freedom as an Internet gateway.  Worse, most
0466    DOS networking programs, including LANMAN, have braindead networking
0467    schemes that rely completely on the netmask and a 'default gateway' to
0468    determine how to route packets.  This means that to get to freedom or
0469    insight, patience WILL send through its default gateway, regardless of
0470    the fact that both freedom and insight (courtesy of the arc0e device)
0471    could understand a direct transmission.
0472 
0473    I compensate by giving freedom an extra IP address - aliased 'gatekeeper' -
0474    that is on my private subnet, the same subnet that patience is on.  I
0475    then define gatekeeper to be the default gateway for patience.
0476 
0477    To configure freedom (in addition to the commands above)::
0478 
0479         ifconfig arc0e gatekeeper
0480         route add gatekeeper arc0e
0481         route add patience arc0e
0482 
0483    This way, freedom will send all packets for patience through arc0e,
0484    giving its IP address as gatekeeper (on the private subnet).  When it
0485    talks to insight or the Internet, it will use its "freedom" Internet IP
0486    address.
0487 
0488    You will notice that we haven't configured the arc0e device on insight.
0489    This would work, but is not really necessary, and would require me to
0490    assign insight another special IP number from my private subnet.  Since
0491    both insight and patience are using freedom as their default gateway, the
0492    two can already talk to each other.
0493 
0494    It's quite fortunate that I set things up like this the first time (cough
0495    cough) because it's really handy when I boot insight into DOS.  There, it
0496    runs the Novell ODI protocol stack, which only works with RFC1201 ARCnet.
0497    In this mode it would be impossible for insight to communicate directly
0498    with patience, since the Novell stack is incompatible with Microsoft's
0499    Ethernet-Encap.  Without changing any settings on freedom or patience, I
0500    simply set freedom as the default gateway for insight (now in DOS,
0501    remember) and all the forwarding happens "automagically" between the two
0502    hosts that would normally not be able to communicate at all.
0503 
0504    For those who like diagrams, I have created two "virtual subnets" on the
0505    same physical ARCnet wire.  You can picture it like this::
0506 
0507 
0508           [RFC1201 NETWORK]                   [ETHER-ENCAP NETWORK]
0509       (registered Internet subnet)           (RFC1597 private subnet)
0510 
0511                              (IP Masquerade)
0512           /---------------\         *            /---------------\
0513           |               |         *            |               |
0514           |               +-Freedom-*-Gatekeeper-+               |
0515           |               |    |    *            |               |
0516           \-------+-------/    |    *            \-------+-------/
0517                   |            |                         |
0518                Insight         |                      Patience
0519                            (Internet)
0520 
0521 
0522 
0523 It works: what now?
0524 -------------------
0525 
0526 Send mail describing your setup, preferably including driver version, kernel
0527 version, ARCnet card model, CPU type, number of systems on your network, and
0528 list of software in use to me at the following address:
0529 
0530         apenwarr@worldvisions.ca
0531 
0532 I do send (sometimes automated) replies to all messages I receive.  My email
0533 can be weird (and also usually gets forwarded all over the place along the
0534 way to me), so if you don't get a reply within a reasonable time, please
0535 resend.
0536 
0537 
0538 It doesn't work: what now?
0539 --------------------------
0540 
0541 Do the same as above, but also include the output of the ifconfig and route
0542 commands, as well as any pertinent log entries (ie. anything that starts
0543 with "arcnet:" and has shown up since the last reboot) in your mail.
0544 
0545 If you want to try fixing it yourself (I strongly recommend that you mail me
0546 about the problem first, since it might already have been solved) you may
0547 want to try some of the debug levels available.  For heavy testing on
0548 D_DURING or more, it would be a REALLY good idea to kill your klogd daemon
0549 first!  D_DURING displays 4-5 lines for each packet sent or received.  D_TX,
0550 D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,
0551 which is obviously quite big.
0552 
0553 Starting with v2.40 ALPHA, the autoprobe routines have changed
0554 significantly.  In particular, they won't tell you why the card was not
0555 found unless you turn on the D_INIT_REASONS debugging flag.
0556 
0557 Once the driver is running, you can run the arcdump shell script (available
0558 from me or in the full ARCnet package, if you have it) as root to list the
0559 contents of the arcnet buffers at any time.  To make any sense at all out of
0560 this, you should grab the pertinent RFCs. (some are listed near the top of
0561 arcnet.c).  arcdump assumes your card is at 0xD0000.  If it isn't, edit the
0562 script.
0563 
0564 Buffers 0 and 1 are used for receiving, and Buffers 2 and 3 are for sending.
0565 Ping-pong buffers are implemented both ways.
0566 
0567 If your debug level includes D_DURING and you did NOT define SLOW_XMIT_COPY,
0568 the buffers are cleared to a constant value of 0x42 every time the card is
0569 reset (which should only happen when you do an ifconfig up, or when Linux
0570 decides that the driver is broken).  During a transmit, unused parts of the
0571 buffer will be cleared to 0x42 as well.  This is to make it easier to figure
0572 out which bytes are being used by a packet.
0573 
0574 You can change the debug level without recompiling the kernel by typing::
0575 
0576         ifconfig arc0 down metric 1xxx
0577         /etc/rc.d/rc.inet1
0578 
0579 where "xxx" is the debug level you want.  For example, "metric 1015" would put
0580 you at debug level 15.  Debug level 7 is currently the default.
0581 
0582 Note that the debug level is (starting with v1.90 ALPHA) a binary
0583 combination of different debug flags; so debug level 7 is really 1+2+4 or
0584 D_NORMAL+D_EXTRA+D_INIT.  To include D_DURING, you would add 16 to this,
0585 resulting in debug level 23.
0586 
0587 If you don't understand that, you probably don't want to know anyway.
0588 E-mail me about your problem.
0589 
0590 
0591 I want to send money: what now?
0592 -------------------------------
0593 
0594 Go take a nap or something.  You'll feel better in the morning.