Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jul 1996 13:04:05 -0400
From:      Gary Chrysler <tcg@ime.net>
To:        Larry Dolinar <LARRYD@bldg1.croute.com>
Cc:        questions@freebsd.org
Subject:   Re: irq 12
Message-ID:  <31FF9205.5C0B@ime.net>
References:  <97AC600782E@bldg1.croute.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Larry Dolinar wrote:
> 
> Half-observation, half-question:
> 
> Some of you may recall my post about a printserver I was setting up using
> 2.1.0-R on a 486DX-33 with IDE and 3 parallel ports.  I later switched to
> a 486DX-66 with 8MB, and it seems more stable.  I even recompiled the
> kernel for non-polling mode on all 3 lpts.
> 
> The failure mode we still observe from time to time: after an
> indeterminate period of inactivity (ie, no print requests), the host
> seems to refuse all sorts of TCP/IP contact (ftp/telnet/lpr) except
> ping. Consequently no printing.  Oddly enough the host itself still
> allows ftp/telnet access from the console to other hosts.
> 
> Even a shutdown (not cold boot) doesn't fix it.  A cold boot generally
> does.  One other odd thing we noticed after a shutdown is that by running
> a netstat -r after login and waiting till hell freezes over for the full
> results, the "missing" contact is reinstated.  In other words, the
> problem goes away.
> 
> The NIC is, as some would expect, an NE2000 clone (at irq 12, iobase 300).
> Trying to use irq 2 or 5 (although -c/visual reports no conflict)
> generally results in ed0:timeout messages during boot, a sure sign of
> trouble.
> 
> We've seen oddball behavior on WinNT 3.51 workstations using bus mouse
> input (presumably irq 12) as well: after a period of no mouse use, the
> mouse freezes up.  We no longer use anything but serial mice in that
> environment.
> 
> Finally, the question: despite its availability, is irq 12 considered one
> of the black sheep of the PC hardware family, and to be avoided for
> things like NIC settings?  Any horror stories to be shared?
> 
> thanks for listening,
> larry
> 
> ps.  Yes, the kernel was modified for irq12 on ed0, but the behavior
>      preceded the kernel change.
> 
> pps. The kernel config, stripped of all comments:
> 
> machine     "i386"
> cpu     "I386_CPU"
> cpu     "I486_CPU"
> ident       "VLB486PS"
> maxusers    10
> options     MATH_EMULATE        #Support for x87 emulation
> options     INET            #InterNETworking
> options     FFS         #Berkeley Fast Filesystem
> options     NFS         #Network Filesystem
> options     MSDOSFS         #MSDOS Filesystem
> options     "CD9660"        #ISO 9660 Filesystem
> options     PROCFS          #Process filesystem
> options     "COMPAT_43"     #Compatible with BSD 4.3
> options     BOUNCE_BUFFERS      #include support for DMA bounce buffers
> options     UCONSOLE        #Allow users to grab the console
> options     SYSVSHM
> options     SYSVSEM
> options     SYSVMSG
> config      kernel  root on wd0
> controller  isa0
> controller  fdc0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
> disk        fd0 at fdc0 drive 0
> disk        fd1 at fdc0 drive 1
> controller  wdc0    at isa? port "IO_WD1" bio irq 14 vector wdintr
> disk        wd0 at wdc0 drive 0
> disk        wd1 at wdc0 drive 1
> device      sc0 at isa? port "IO_KBD" tty irq 1 vector scintr
> device      npx0    at isa? port "IO_NPX" irq 13 vector npxintr
> device      sio0    at isa? port "IO_COM1" tty irq 4 vector siointr
> device      sio1    at isa? port "IO_COM2" tty irq 3 vector siointr
> device      lpt0    at isa? port? tty
> device      lpt1    at isa? port? tty
> device      lpt2    at isa? port? tty
> device ed0 at isa? port 0x300 net irq  12 iomem 0xd8000 vector edintr
> pseudo-device   loop
> pseudo-device   ether
> pseudo-device   log
> pseudo-device   sl  1
> pseudo-device   tun 1
> pseudo-device   pty 16
> pseudo-device   gzip        # Exec gzipped a.out's

I'd really like to say you are having IRQ conflicts but I don't
know enough about how FreeBSD handles lpt ports and they're IRQ's
to say.. :)

My geuss is FreeBSD gets that info from the BIOS.

Physically check your lpt boards and make sure they are
setup correctly and not conflicting.
I would set them as: (I've never done this for FreeBSD)
  lpt0 = 0x3bc/7, lpt1 = 0x378/5, lpt1 = 0x278/(upto card)

I'd be interested in seeing your dmesg output.

Someone else may have better/more info.

I seem to have problems with NE2000's at 0x300/12, I find 0x2c0/10
works best for me.

-Enjoy
Gary
~~~~~~~~~~~~~~~~
Improve America's Knowledge... Share yours
The Borg... Where minds meet
(207) 929-3848



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31FF9205.5C0B>