Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

more OpenBSD woes: recompiling the kernel



It seems that OpenBSD doesn't like my modem, a Zoom 56K internal ISA
fax-modem.  When I have the modem jumpers set to COM3, Linux's PPP
software will happily talk to the modem through /dev/ttyS2, but
OpenBSD's PPP software won't talk to it through the equivalent device
(which, if memory serves, is /dev/cua02).

(Note that this is *not* a "winmodem" -- the manual says that if
you're running Windows and don't have the Zoom's device driver for
Windows, the modem will still run using the generic Windows modem
driver.)

When the modem is set to plug-and-play mode, OpenBSD complains that it
doesn't recognize it; the modem gives its manufacturer-specific device
number, but doesn't give a generic PNP device number that the kernel
knows about.  Fortunately, the isapnp(4) man page gives a simple
solution to this: add the manufacturer-specific ID to
/sys/dev/isa/pnpdevs and recompile the kernel.

So I added the appropriate line to that file, followed the
instructions for recompiling the kernel and ... well, I typed "make
depend && make" at about 1:00 pm on Monday, the compile was still
running last night, and when I checked the machine this morning, it
looked like it was wedged.  (There wasn't any disk activity, but I
didn't have a prompt, and when I switched to another virtual terminal,
I couldn't log in.)

If, when I come home tonight, there's been no progress on the compile,
my tentative plan is:

(1) Use "config -e" to modify the kernel without recompiling.  (I
hadn't done this the first time around because I was paying more
attention to the isapnp(4) page than the config(8) page.)

(2) If that fails, create a configuration file that disables all the
options I don't need (e.g., things related to X, PCI, and Linux binary
compatibility), and then recompile the kernel from that -- I hope that
would make the build go faster.  (On the other hand, I don't want to
find out the hard way that a program I need requires a kernel option
that I disabled....)

(3) Get a Linux CD and just install Linux on the system.

Comments?  How long should I *expect* a kernel build to take, on a
486SX with 8 MB RAM?

--
perl -le"for(@w=(q[dm='r 0rJaa,u0cksthe';dc=967150;dz=~s/d/substrdm,\
(di+=dc%2?4:1)%=16,1ordi-2?'no':'Perl h'/e whiledc>>=1;printdz]))\
{s/d/chr(36)/eg;eval;}#In Windows type this all on 1 line w/o '\'s"
== seth gordon == sgordon at kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org