Date: Thu, 2 Feb 95 10:37:54 MST From: terry@cs.weber.edu (Terry Lambert) To: fod@netcom.com (Frank O'Donnell) Cc: questions@FreeBSD.org Subject: Re: XFree86-3.1 install hangs, and misc Message-ID: <9502021737.AA13709@cs.weber.edu> In-Reply-To: <199502020516.VAA14695@netcom11.netcom.com> from "Frank O'Donnell" at Feb 1, 95 09:16:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... 1) XFree86 from CDROM install problems ... ]
Jordan?
I remember there being some problem with the X image on the CDROM,
and that manually installing it instead of using the checksumming
install script fixed it, but I can't rememebr the details.
[ ... 2) mitsumi mount problems ... ]
I believe you have to use slice 'b' to mount the CDROM.
I also think you have to use the "mount -t isofs" (or something to
that effect) instead of using "mount_cd9660" directly. There is
a working example on the mount man page.
> 3) The troubleshooting doc says that, if I'm booting FreeBSD
> off my second hard drive, when the boot manager comes up I have
> to type in "wd(1,a)/kernel" everytime or hack the boot manager
> code (or wait for FreeBSD 2.1). I don't mind hacking the code,
> but since I'm still learning Unix, rather than installing all
> the source and wading through it, I wonder if there is a simple
> byte I can change on my first hard drive with an MS-DOS utility
> like Norton Disk Editor.
No. You must hack the code:
] I took this opportunity to look at the -current boot.c and see what
] the state of setting the default disk unit was... Recall that the
] issue was setting the default to "wd(1,a)" if one were loading the
] boot blocks from wd1. This makes things work nicely for people like
] me with FreeBSD installed on a 2nd hard disks.
]
] There was a concern about broken BIOSes which return garbage values
] for the drive number. In this case, the people with broken BIOSes
] will have to type "wd(0,a)" (or whatever), instead of the people with
] 2nd hard disks having to type "wd(1,a)". It sounds like a toss-up to
] me...
]
] Anyway, my suggestion is to put both bits of code into boot.c (#ifdef
] BROKEN_BIOS ???), and have a Makefile option to compile with one or
] the other. I think this will make life easier for a lot of people.
]
] Comments?
]
]
] Tom Pavel
]
] Stanford Linear Accelerator Center
] pavel@slac.stanford.edu
*** boot.c Wed Jul 13 22:28:55 1994
--- boot.c.orig Wed Jun 15 20:53:27 1994
***************
*** 83,90 ****
* As a default set it to the first partition of the first *
* floppy or hard drive *
\***************************************************************/
! part = 0;
! unit = (drive & 0x7f);
maj = (drive&0x80 ? 0 : 2); /* a good first bet */
name = names[currname++];
--- 83,89 ----
* As a default set it to the first partition of the first *
* floppy or hard drive *
\***************************************************************/
! part = unit = 0;
maj = (drive&0x80 ? 0 : 2); /* a good first bet */
name = names[currname++];
Because the patch applies to separating a cascade assignment (where the
lvalue of one assign is used as the rvalue of another), you *must*
actually change the code instead of setting a value.
I can't remember the assembler generated; I thing it does a load, store,
store. If it promoted both variables to register, and changed this to
load immediate, load immediate, then you could blow a 0 to a 1 and get
what you are looking for.
Takes me back to the days of bit-hacking the 386BSD 0.0 and 0.1 boot
disks to make them boot on BIOS reporting something other than 640k of
base memory so I could install to source hack them. 8-).
Without specific revisions, I can't tell if you have a broken BIOS or
not. You can probably try it and find out for yourself in the time
another email exchange would take.
If your BIOS id broken, you can replace "unit = (drive & 0x7f);" with
"unit = 1;" for your particular install (where you are using the second
disk).
> 4) I notice that if I run a FreeBSD session then shut down,
> warm- boot and run MS-DOS, there are a couple of peculiarities.
> First, as Windows starts, I get an error from Soundblaster 16
> saying the midiport configuration in system.ini is wrong.
> Second, my Hayes 144 internal modem doesn't respond to its
> usual initialization string or dial commands. Both of these
> are fixed if I power the machine off and on to coldboot, and
> then start a DOS/Windows session. Is it possible that in its
> probe of the machine's hardware FreeBSD is writing something
> out to ports or whatever that is leaving the hardware in a
> funny state?
I don't know about the MIDI. I suspect that you have your hardware
set up under DOS such that there are conflicting interrupts... so the
message is correct: your configuration in system.ini *is* wrong. Since
a power off reset clears dynamically stored values, it goes away when
you power cycle, until the next time the BSD driver resolves the
interrupt conflict for you.
The Hayes 144 internal modem is acting funny probably because BSD
recognizes it as a 16550 and enables FIFO's. Many BIOS do not
know how to get UARTs into a known state in this regard because they
are blissfully unaware that it is possible to get better performance
of of particular hardware. They are coded to the lowest common
denominator.
You can verify this by looking at the card probe message during boot.
Depending on the configuration of your hardware, you *may* be able to
do something about this without building a new kernel.
It's possible that the reason the modem isn't reset is because it isn't
where the BIOS thinks of as COM1: or COM2:. Rearranging your comm port
order could fix this.
It's also possible that you can fix it by a jumper or a NVRAM setting on
the modem itself (part of the modem setup). The real problem is that
the hardware doesn't do a hard reset on the UART (blowing out the FIFO
enabling) when the card get a soft reset, and there's a possibility that
the card has a jumper or setting to fix this.
If all else fails, you can disable the enabling of the FIFO in BSD by
following the instructions in the SIO man page and rebuilding your
kernel. Note, however, you are working around a bug in your hardware
and a bug in your BIOS, *not* a bug in BSD, by doing this.
Several internal US Robotics modems are known to not have this problem,
but the US Robotics Sportster 14.4 series is known to lock up when it
talks to a Rockwell chipset on the other end of the wire, so don't
rush out and buy one without test driving it if you decides to replace
your Hayes.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502021737.AA13709>