From owner-freebsd-questions Thu Feb 2 09:44:51 1995 Return-Path: questions-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA10758 for questions-outgoing; Thu, 2 Feb 1995 09:44:51 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA10752 for ; Thu, 2 Feb 1995 09:44:48 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA13709; Thu, 2 Feb 95 10:37:55 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502021737.AA13709@cs.weber.edu> Subject: Re: XFree86-3.1 install hangs, and misc To: fod@netcom.com (Frank O'Donnell) Date: Thu, 2 Feb 95 10:37:54 MST Cc: questions@FreeBSD.org In-Reply-To: <199502020516.VAA14695@netcom11.netcom.com> from "Frank O'Donnell" at Feb 1, 95 09:16:31 pm X-Mailer: ELM [version 2.4dev PL52] Sender: questions-owner@FreeBSD.org Precedence: bulk [ ... 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.