From owner-freebsd-bugs Tue Apr 11 13:00:12 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA02796 for bugs-outgoing; Tue, 11 Apr 1995 13:00:12 -0700 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA02780 for ; Tue, 11 Apr 1995 13:00:06 -0700 Received: from ast.com by relay1.UU.NET with SMTP id QQylat01567; Tue, 11 Apr 1995 15:59:44 -0400 Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA01336 (5.67b/IDA-1.5 for uunet!pilchuck!rwing!eskimo!daveh); Tue, 11 Apr 1995 13:03:48 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Tue, 11 Apr 95 14:59 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #18) id m0rym1x-0004vrC; Tue, 11 Apr 95 14:55 CDT Message-Id: Date: Tue, 11 Apr 95 14:55 CDT To: daveh@eskimo.com, bugs@FreeBSD.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Tue Apr 11 1995, 14:55:20 CDT Subject: matcd0: error during 2.0-950322-SNAP installation Cc: uhclem@nemesis.lonestar.org Sender: bugs-owner@FreeBSD.org Precedence: bulk [0]Then, when wd(0,a)/kernel went probing devices, the device matcd0: would [0]eventually come up for probing and/or attachment, and the kernel would [0]declare emphatically: [0] [0] matcd0: get_stat: after reading status byte, buss didn't go idle The problem is that at one of the addresses the driver is probing (which are 0x230, 0x240, 0x250, 0x260) there is some other device and that device is confusing the probe code. Removing the SoundBlaster card WILL NOT HELP, but adding a drive to it will. This has already been fixed, but until the new snap is available, your choices are: 1. Remove the offending adapter card at the above addresses or relocate them to other I/O ports until you can rebuild the kernel or get the new version. 2. Download the new version of matcd 1(16) from the -current tree. It now assumes that if the device doesn't honor a reset, it must not be the device it was looking for. The new SNAP (0408 or later) should have the newer version built-in. 3. Send me mail and I will send the new driver to you or a bootable kernel (0322-based). 4. Rebuild the kernel with a hard port specified (I know this one is tough if you don't already have a working system.) [0]re: kernel -c [0] No such device: matcd0 [0] Invalid command or syntax. This is another bug that the newer version fixes. The string that kernel -c is looking for is "matcd int", but I don't think there is any way to get it to accept a name with a space in it. The newer version makes "matcd" work in kernel -c. [0]After the disabling fiasco, I took the SoundBlaster 16 out of this [0]machine, thinking that matcd0: was meant to represent the Matsushita [0]cd-rom which attaches to these sound cards. I went through the entire [0]procedure described above, and once again the same problem appeared. The problem is that it is spotting some other device at one of the above addresses LOWER than the address that your SoundBlaster card is at *OR* you don't have a Matsushita drive attached at all, so the driver will look at ALL of the addresses listed above. You have to remove the conflicting devices (0322 RELEASE ONLY) to get around this problem. [0]So, the system I'm working with here is an i486DX2 66Mhz system with 16mb [0]RAM, a 540mb Western Digital HD, a 540mb Quantum SCSI HD and a Toshiba [0]XM3501B cd-rom (so far unrecognizable to FreeBSD because it's on a QLogic [0]VLB SCSI controller card), a SoundBlaster 16 (presumably this is what's [0]supposed to be attached to matcd0: ???), a Diamond SpeedStar Pro w 1mb [0]RAM, and an Intel EtherExpress 16, Try removing the network card or moving its address higher. The SCSI board may also be the source of the conflict. Don't give up - the next version is solves these problems. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@trsvax.ast.com (Internet)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!trsvax.fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983