From owner-freebsd-hardware Sun Mar 31 01:21:33 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA11367 for hardware-outgoing; Sun, 31 Mar 1996 01:21:33 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA11361 Sun, 31 Mar 1996 01:21:21 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA28942; Sun, 31 Mar 1996 19:11:25 +0930 From: Michael Smith Message-Id: <199603310941.TAA28942@genesis.atrad.adelaide.edu.au> Subject: Re: Cannot boot after install To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sun, 31 Mar 1996 19:11:24 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, jkh@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <9602308282.AA828224213@ccgate.infoworld.com> from "Brett Glass" at Mar 30, 96 12:31:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > > If I recall correctly, the ATA-2 spec says that drives should not default > > to green mode; you're probably going to have to check with the spec and > > add some special code to the 'wd' driver to recognise your drive and > > disable 'green mode'. > > I have the kernel code, but am unfamiliar with ATA-2. Anyone here know > where to get the spec? Also, it might be possible to add a driver flag > for disabling read-ahead. Hmm. Let me clarify a few things having browsed the documentation I have to hand ere. - The spec I am familiar with is : working document of the CAM (Common Access Method Committee) draft proposal ATA (AT Attachment) Rev 2.1 June 11, 1990 ... this is obviously not the ATA-2 spec; my apologies for the confusion there. - There's no clear indication in the document as to what the drive's default configuration should be. The spec is pretty cloudy in places 8( Having said that, it still _seems_ that your drive is not behaving per the spec. Rather than quote screeds of it here, look for 'ata-21.doc' (or possibly .zip). I got my copy off gatekeeper.dec.com, you'll probably do better these days asking http://altavista.digital.com/ for it. > P.S. -- A week from Monday, you'll see some comments on the FreeBSD > kernel configuration program in InfoWorld. Check out > > http://www.infoworld.com/pageone/opinions/glass.htm Then or now? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Sun Mar 31 04:07:32 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA22689 for hardware-outgoing; Sun, 31 Mar 1996 04:07:32 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA22682 for ; Sun, 31 Mar 1996 04:07:26 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id NAA20161; Sun, 31 Mar 1996 13:45:16 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by gun.de (8.7.5/8.7.3) with SMTP id MAA00402; Sun, 31 Mar 1996 12:21:01 +0200 (MET DST) Date: Sun, 31 Mar 1996 12:21:00 +0200 (MET DST) From: Andreas Klemm To: Brett Glass cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Cannot boot after install In-Reply-To: <9602298281.AA828133263@ccgate.infoworld.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 29 Mar 1996, Brett Glass wrote: > > Turn the green mode crap off! It's utterly unacceptable for pretty > > much any UNIX system you can name (including Linux) to have one of its > > drives suddently decide to take a vacation. This thing must have some > > BIOS option for disabling it. > > Unfortunately, the BIOS has no such option. I called Zeos, and they say > that the OS's IDE driver should turn power management off if it does not > want it on. This certainly seems like a good idea for any UNIX system. Well this sounds silly. A lame excuse of your hardware vendor. Figure out, only because one hardware vendor decides, that this has to be done by the OS, not by BIOS or jumper setting, all OS vendors or SCSI controller vendors have to rewrite their drivers or firmware to turn off the green feature in case of trouble ?! - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMV5cjPMLpmkD/U+FAQHHFAQAn2myjA7Ti6uVGXbHHq2QliBp+NjhvTWy Du0bJ1rfNDM0Bnh++yOjc2nZHxgRJQuwDeezrssR6iajcUS8QZsYfplEX8kvm1eX hycDnk08EpgJmshQa9wYr2nYH4BKIVwuz1Zx4akh4xTokQUw9uqC/HKbszTUaW5X xZ0qAzBEik8= =e7E0 -----END PGP SIGNATURE----- From owner-freebsd-hardware Sun Mar 31 09:16:37 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA04832 for hardware-outgoing; Sun, 31 Mar 1996 09:16:37 -0800 (PST) Received: from cocoa.ops.neosoft.com (root@cocoa.ops.neosoft.com [206.109.5.227]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA04803 Sun, 31 Mar 1996 09:16:27 -0800 (PST) Received: (from dbaker@localhost) by cocoa.ops.neosoft.com (8.7.5/8.6.12) id LAA02288; Sun, 31 Mar 1996 11:16:06 -0600 (CST) Date: Sun, 31 Mar 1996 11:16:02 -0600 (CST) From: Daniel Baker X-Sender: dbaker@cocoa.ops.neosoft.com To: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Quickcam qcamcontrol problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey, I think the new qcam drivers and programs are pretty cool, but I've been having some problems.... :-( First of all, if all of the arguments on qcamcontrol work except for the brightness one (-b). It causes it to have a segmentation fault and then it dumps core. Secondly, it causes my machine to reboot sometimes.. I have it in cron to take a picture every once in a while and put it on my webpage, and that makes my machine very very unstable, because it will reboot often, but sometimes when I do it as a command line option, it will just freeze and reboot -- not sure if it's a panic.. Is anybody else having these problems, or is it just me? Daniel Daniel Baker - Daniel@Cuckoo.COM "Uhhhhhhh, thank you, drive through please" From owner-freebsd-hardware Sun Mar 31 12:10:50 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA24986 for hardware-outgoing; Sun, 31 Mar 1996 12:10:50 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA24981 for ; Sun, 31 Mar 1996 12:10:47 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA11131; Mon, 1 Apr 1996 06:10:03 +1000 Date: Mon, 1 Apr 1996 06:10:03 +1000 From: Bruce Evans Message-Id: <199603312010.GAA11131@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, freebsd-hardware@freebsd.org, heric@aug.com Subject: Re: ASUS ncr scsi controller question Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Different controllers do sector translation in different ways, and >sometimes reserve sectors for themselves. They're not always compatible. >You might not be able to read your disk after you've changed controllers. SCSI controllers should be compatible. They can't remap sectors because that is the drives' responsibility... Bruce From owner-freebsd-hardware Sun Mar 31 12:42:18 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA26597 for hardware-outgoing; Sun, 31 Mar 1996 12:42:18 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA26591 Sun, 31 Mar 1996 12:42:15 -0800 (PST) Message-Id: <199603312042.MAA26591@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: Brett_Glass@ccgate.infoworld.com, freebsd-hardware@freebsd.org, heric@aug.com Subject: Re: ASUS ncr scsi controller question In-reply-to: Your message of "Mon, 01 Apr 1996 06:10:03 +1000." <199603312010.GAA11131@godzilla.zeta.org.au> Date: Sun, 31 Mar 1996 12:42:15 -0800 From: "Justin T. Gibbs" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>Different controllers do sector translation in different ways, and >>sometimes reserve sectors for themselves. They're not always compatible. >>You might not be able to read your disk after you've changed controllers. > >SCSI controllers should be compatible. They can't remap sectors because >that is the drives' responsibility... > >Bruce The only time they are not is with boot devices where the BIOS geometry may change. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hardware Sun Mar 31 17:01:55 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA14997 for hardware-outgoing; Sun, 31 Mar 1996 17:01:55 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA14969 for ; Sun, 31 Mar 1996 17:01:43 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA01915; Mon, 1 Apr 1996 10:50:51 +0930 From: Michael Smith Message-Id: <199604010120.KAA01915@genesis.atrad.adelaide.edu.au> Subject: Re: Cannot boot after install To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Mon, 1 Apr 1996 10:50:50 +0930 (CST) Cc: hdalog@zipnet.net, davidg@Root.COM, hardware@freebsd.org In-Reply-To: <9602308282.AA828250915@ccgate.infoworld.com> from "Brett Glass" at Mar 30, 96 10:38:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > The heads still retract, though. It'd be good to turn power management off, > and turn off prefetches at the same time. If Linux can do it, surely > FreeBSD can. The two are seperate issues. As I've already mentioned, turning prefetch off in the kernel may be _too_late_. You should do it in the BIOS. Note that there are some interesting comments in the ATA spec I was referring to regarding power-saving modes. Basically, the "lowest" a drive is allowed to go without an explicit command should still respond, as per normal, to commands, however response may be delayed by up to 30 seconds. If your drive is responding with an error condition (indicating that it's gone into 'sleep' mode), it is violating the spec. > --Brett > > P.S. -- Am still trying to diagnose that arplookup failure. Why might the > system be attempting to do an ARP on a system that isn't even on the local > net? And that isn't named anywhere in the network configuration files? You may have routed running; turn it off in /etc/sysconfig. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Mon Apr 1 07:09:32 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA29012 for hardware-outgoing; Mon, 1 Apr 1996 07:09:32 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA29007 for ; Mon, 1 Apr 1996 07:09:29 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3laI-000x1UC; Mon, 1 Apr 96 07:31 PST Received: from cc:Mail by ccgate.infoworld.com id AA828371258; Mon, 31 Mar 96 20:11:18 PST Date: Mon, 31 Mar 96 20:11:18 PST From: "Brett Glass" Message-Id: <9603018283.AA828371258@ccgate.infoworld.com> To: hardware@freebsd.org Subject: Digiboard X/em drivers Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd like to get a Digiboard X/em (a processor card that can hook up to several external serial port modules) working with FreeBSD. There are references to Digiboard drivers in the FAQs, but no information on whether this specific product is supported. A search through the FTP site did not turn anything up. Does anyone know if there is driver support for the X/em? --Brett Glass From owner-freebsd-hardware Mon Apr 1 07:09:37 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA29028 for hardware-outgoing; Mon, 1 Apr 1996 07:09:37 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA29022 for ; Mon, 1 Apr 1996 07:09:34 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3laH-000x1TC; Mon, 1 Apr 96 07:31 PST Received: from cc:Mail by ccgate.infoworld.com id AA828371256; Mon, 31 Mar 96 20:10:32 PST Date: Mon, 31 Mar 96 20:10:32 PST From: "Brett Glass" Message-Id: <9603018283.AA828371256@ccgate.infoworld.com> To: "Brett Glass" , jkh@time.cdrom.com, hardware@freebsd.org Subject: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Aha! Have found some instructions for writing code that can be incorporated into the kernel to solve the timeout problem. ftp://ftp.seagate.com/techsuppt/misc/no_idle.zip explains how to disable the timeouts and gives sample code for DOS. (It'd have to be different for FreeBSD's disk driver.) I will take a stab at adding some code to my kernel this evening; however, since most low-level OS code has a "culture" behind it (that is, an unwritten list of ways to do things and things one shouldn't do at all costs), I'm worried that I'll violate some unwritten rule and mess everything up. Would someone more experienced with hacking the FreeBSD kernel be willing to help by looking over my code and/or incorporating the relevant instructions (it's only three I/O operations per drive, with pauses between)? The code should probably be activated by flags (one per drive for each IDE interface). What is the proper procedure for implementing and assigning a device driver flag, and making sure that there are no conflicts? Are any flag bits reserved in FreeBSD disk drivers? --Brett P.S. -- Have also found a fix for the read-ahead problem, but it is specific to my machine. Zeos had -- in poorly labeled and virtually undocumented form -- a BIOS upgrade for this system on their Web site. This BIOS -- but not the one that most users got -- has a switch to turn off read-aheads on the buggy RZ1000 chip. This should be considered a special case, though; other brands of computers may not have such BIOSes available. Linux detects the buggy chip and disables read-aheads; FreeBSD should do the same rather than expecting this capability to exist in the BIOS. From owner-freebsd-hardware Mon Apr 1 07:09:51 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA29067 for hardware-outgoing; Mon, 1 Apr 1996 07:09:51 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA29044 Mon, 1 Apr 1996 07:09:44 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3laX-000x1UC; Mon, 1 Apr 96 07:32 PST Received: from cc:Mail by ccgate.infoworld.com id AA828371297; Mon, 01 Apr 96 02:14:11 PST Date: Mon, 01 Apr 96 02:14:11 PST From: "Brett Glass" Message-Id: <9603018283.AA828371297@ccgate.infoworld.com> To: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Subject: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tonight, I bit the bullet and hacked the FreeBSD kernel (specifically, the wdc driver) to disable "green" mode on LARIAT.ORG's ST5660A IDE hard drive. As reported in earlier messages, the drive was retracting its heads and spinning down during periods of inactivity, which caused FreeBSD's disk routines to time out and complain. The system would splatter the screen with kernel error messages and freeze for seconds at a time. (I haven't tried FreeBSD on a laptop, but this must occur frequently in that environment if the same kind of drive is used.) In any event, after an extensive search of the Web, I dredged up the key piece of information needed to solve the problem from the archive ftp://ftp.seagate.com/techsuppt/misc/no_idle.zip on Seagate's Web site. Essentially, to turn off the "green mode" inactivity timer, one issues controller command 0xFB for the relevant drive, with a 0 in the controller's sector count register, during initialization. (A number larger than zero sets the timer to that number of milliseconds.) I'm not a UNIX kernel hacker (or I wasn't, anyway), and was utterly unfamiliar with all the conventions used in FreeBSD, so the source in wd.c took quite a while to analyze. (It's much more complex than it needs to be, and uses -- Aargh! -- uninterruptible busy-waits at the kernel level. THIS is why the entire OS freezes for seconds at a time.) After much staring at the code, I figured out how to get an existing function to do most of the work. The increase in kernel size was therefore negligible. Turning "green mode" off should be optional, so I grabbed two apparently unused configuration flag bits -- 0x0100 and 0x0200 -- for wdc. (The configuration utility doesn't expose flag words for the individual drives; if it did, the flags would really belong THERE.) These bits disable inactivity timeouts on the master and slave drives, respectively. The new kernel seemed to work without breaking anything, but since I haven't played with this code before, and am not ENTIRELY sure that I didn't step on something, I'd like a second or third opinion. [Aside: Maybe, at the same time, someone could tell me what the SLEEPHACK configuration bit does. It looks as if it's supposed to make the driver more tolerant of drive spindowns on laptops, but I'm not sure that it will work as advertised. On this machine, the unwedge() function, which it calls, also complains when the disk spins down.] I don't know how integration of kernel modifications into FreeBSD works, but I'd be glad to send the diffs for the two files I changed (wd.c and wdreg.h) to anyone who wants them. (I started with 2.1.0-RELEASE.) Feel free to integrate them into -current, and add information about the flags to the FAQ. Maybe this will save the next person the week of agony I endured before I figured out how to get this system running. --Brett From owner-freebsd-hardware Mon Apr 1 07:29:58 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA00321 for hardware-outgoing; Mon, 1 Apr 1996 07:29:58 -0800 (PST) Received: from DeepCore.dk (dial200.cybercity.dk [194.16.56.200]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA00312 for ; Mon, 1 Apr 1996 07:29:52 -0800 (PST) Received: (from sos@localhost) by DeepCore.dk (8.7.5/8.7.3) id RAA00318; Mon, 1 Apr 1996 17:29:05 +0200 (MET DST) Message-Id: <199604011529.RAA00318@DeepCore.dk> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Mon, 1 Apr 1996 17:29:05 +0200 (MET DST) Cc: Brett_Glass@ccgate.infoworld.com, jkh@time.cdrom.com, hardware@FreeBSD.org In-Reply-To: <9603018283.AA828371256@ccgate.infoworld.com> from "Brett Glass" at Mar 31, 96 08:10:32 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Brett Glass who wrote: > > Aha! Have found some instructions for writing code that can be incorporated > into the kernel to solve the timeout problem. What timeout problem ?? > ftp://ftp.seagate.com/techsuppt/misc/no_idle.zip > > explains how to disable the timeouts and gives sample code for DOS. (It'd > have to be different for FreeBSD's disk driver.) I will take a stab at > adding some code to my kernel this evening; however, since most low-level > OS code has a "culture" behind it (that is, an unwritten list of ways to do > things and things one shouldn't do at all costs), I'm worried that I'll > violate some unwritten rule and mess everything up. Would someone more > experienced with hacking the FreeBSD kernel be willing to help by looking > over my code and/or incorporating the relevant instructions (it's only > three I/O operations per drive, with pauses between)? Could you be a little more specific ?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hardware Mon Apr 1 09:05:51 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06914 for hardware-outgoing; Mon, 1 Apr 1996 09:05:51 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06906 Mon, 1 Apr 1996 09:05:48 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3nOw-000wyEC; Mon, 1 Apr 96 09:28 PST Received: from cc:Mail by ccgate.infoworld.com id AA828378283; Mon, 01 Apr 96 09:31:58 PST Date: Mon, 01 Apr 96 09:31:58 PST From: "Brett Glass" Message-Id: <9603018283.AA828378283@ccgate.infoworld.com> To: sos@FreeBSD.org Cc: jkh@time.cdrom.com, hardware@FreeBSD.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Aha! Have found some instructions for writing code that can be >> incorporated into the kernel to solve the timeout problem. What timeout problem ?? On this machine, a Zeos Pantera 486 "Rattler," the disk was retracting its heads (and, sometimes, even spinning down!) during periods of inactivity. FreeBSD's kernel threw a fit when it next tried to access the drive; the console was covered with ugly messages warning of timeouts in the disk routine, and everything hung for nearly 30 seconds. Not a good way to respond to a "green" computer system, which is common nowadays. > Could you be a little more specific ?? See my followup. --Brett From owner-freebsd-hardware Mon Apr 1 09:05:59 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06962 for hardware-outgoing; Mon, 1 Apr 1996 09:05:59 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06947 Mon, 1 Apr 1996 09:05:56 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3nP0-000ws0C; Mon, 1 Apr 96 09:28 PST Received: from cc:Mail by ccgate.infoworld.com id AA828378286; Mon, 01 Apr 96 09:46:25 PST Date: Mon, 01 Apr 96 09:46:25 PST From: "Brett Glass" Message-Id: <9603018283.AA828378286@ccgate.infoworld.com> To: Michael Smith Cc: hdalog@zipnet.net, davidg@Root.COM, hardware@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: Cannot boot after install Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Note that there are some interesting comments in the ATA spec I was > referring to regarding power-saving modes. Basically, the "lowest" a > drive is allowed to go without an explicit command should still respond, > as per normal, to commands, however response may be delayed by up to 30 > seconds. If your drive is responding with an error condition (indicating > that it's gone into 'sleep' mode), it is violating the spec. In that case, the drive is absolutely within spec. It comes up within 30 seconds. However, FreeBSD literally locks up until it sees a response fron the drive. This is a problem with FreeBSD. It should not busy-wait in the kernel, forsaking all other tasks, until it gets a response. This is, after all, a multitasking OS! ;-) The kernel hack I did (turning off the power-saving mode) is appropriate for desktop machines; in fact, for them, it's a good idea. But it's NOT appropriate for laptops and other low-power applications. The kernel needs to be fixed so that the drive *can* spin down without locking up the entire machine. --Brett From owner-freebsd-hardware Mon Apr 1 09:06:08 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07005 for hardware-outgoing; Mon, 1 Apr 1996 09:06:08 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06976 Mon, 1 Apr 1996 09:06:00 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3nP4-000wunC; Mon, 1 Apr 96 09:28 PST Received: from cc:Mail by ccgate.infoworld.com id AA828378291; Mon, 01 Apr 96 09:57:24 PST Date: Mon, 01 Apr 96 09:57:24 PST From: "Brett Glass" Message-Id: <9603018283.AA828378291@ccgate.infoworld.com> To: Andreas Klemm Cc: freebsd-hardware@freebsd.org, bugs@freebsd.org Subject: Re: Cannot boot after install Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Well this sounds silly. A lame excuse of your hardware vendor. Unfortunately, the maker of the drive happens to be Seagate. They're rather large, and just got larger. One has to accommodate them. > Figure out, only because one hardware vendor decides, that this > has to be done by the OS, not by BIOS or jumper setting, all OS > vendors or SCSI controller vendors have to rewrite their drivers > or firmware to turn off the green feature in case of trouble ?! This is an ATA drive. I was really surprised to find no jumper, but there isn't one. Seagate supplies a software solution for DOS, where (ironically) it is least needed. Anyway, the real problem is that FreeBSD's ATA disk driver is single-threaded and busy-waits in the kernel for commands to be accepted by the drive. The spindown/spinup would not really be a problem if the driver was coded using more robust techniques. (OS/2, for example, has no problems on the same machine.) --Brett From owner-freebsd-hardware Mon Apr 1 09:06:29 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07109 for hardware-outgoing; Mon, 1 Apr 1996 09:06:29 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06952 Mon, 1 Apr 1996 09:05:57 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3nP5-000wyEC; Mon, 1 Apr 96 09:28 PST Received: from cc:Mail by ccgate.infoworld.com id AA828378293; Mon, 01 Apr 96 10:00:44 PST Date: Mon, 01 Apr 96 10:00:44 PST From: "Brett Glass" Message-Id: <9603018283.AA828378293@ccgate.infoworld.com> To: freebsd-hardware@freebsd.org, hackers@freebsd.org, bugs@freebsd.org Subject: Changes to FreeBSD kernel to keep "green" drives on Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here are the diffs to FreeBSD 2.1.0-RELEASE that turn off the inactivity timer. Turning on these flags will always be a good idea for desktop systems with "green" hard drives, but the kernel still needs fixing to handle systems in which an inactivity timeout is desirable (e.g. laptops). --Brett Changes to wd.c: 105a106,111 > #define WDOPT_NO_IDLE_0 0x0100 /* Flags added by Brett Glass to shut off */ > #define WDOPT_NO_IDLE_1 0x0200 /* inactivity timeout on some IDE drives, */ > /* such as ST5660A. On each interface, */ > /* 0x0100 and 0x0200 are for master and */ > /* slave, respectively. */ > 229a236,237 > #define DKFL_NO_IDLE 0x00800 /* disk has had inactivity timer > turned off -BG */ 443a452,453 > if (du->dk_flags & DKFL_NO_IDLE) > printf(", inactivity timer disabled"); 1610a1621,1633 > } > > /* If this drive should have its inactivity timer turned off, issue > the command to do it. If the command succeeds, then set a flag > in the disk's struct so we can report that it worked. -BG */ > > du->dk_flags &= ~DKFL_NO_IDLE; /* Assume command will fail */ > > /* Shift WDOPT_NO_IDLE_0 left if unit 1 to get WDOPT_NO_IDLE_1*/ > if (flags & (WDOPT_NO_IDLE_0 << (du->dk_unit))) { > if (wdcommand(du, 0, 0, 0, 0, WDCC_IDLEMODE) == 0) { > du->dk_flags |= DKFL_NO_IDLE; > } Changes to wdreg.h: 99a100,102 > /* Following constant added by Brett Glass for the command that > disables/enables "green" mode on drives such as the Seagate ST5660A */ > #define WDCC_IDLEMODE 0xFB /* configure active/idle mode -BG*/ From owner-freebsd-hardware Mon Apr 1 09:23:25 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA08610 for hardware-outgoing; Mon, 1 Apr 1996 09:23:25 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA08602 Mon, 1 Apr 1996 09:23:23 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3nfo-000wyzC; Mon, 1 Apr 96 09:45 PST Received: from cc:Mail by ccgate.infoworld.com id AA828379330; Mon, 01 Apr 96 10:12:04 PST Date: Mon, 01 Apr 96 10:12:04 PST From: "Brett Glass" Message-Id: <9603018283.AA828379330@ccgate.infoworld.com> To: Michael Smith Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, jkh@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Cannot boot after install Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Having said that, it still _seems_ that your drive is not behaving > per the spec. It seems to be. It does accept the command; it just says it's busy until it has spun up. And the spinup takes less than 30 seconds. > Then or now? The reference to FreeBSD's configuration routines (as an example of what other OSes should do!) will appear in the April 8 InfoWorld. It'll be online that morning at http://www.infoworld.com/pageone/opinions/glass.htm. --Brett From owner-freebsd-hardware Mon Apr 1 09:41:56 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09588 for hardware-outgoing; Mon, 1 Apr 1996 09:41:56 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA09577 for ; Mon, 1 Apr 1996 09:41:54 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3nxr-000wzLC; Mon, 1 Apr 96 10:04 PST Received: from cc:Mail by ccgate.infoworld.com id AA828380442; Mon, 01 Apr 96 10:33:58 PST Date: Mon, 01 Apr 96 10:33:58 PST From: "Brett Glass" Message-Id: <9603018283.AA828380442@ccgate.infoworld.com> To: "Justin T. Gibbs" , bde@zeta.org.au Cc: freebsd-hardware@FreeBSD.ORG, heric@aug.com Subject: Re: ASUS ncr scsi controller question Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The only time they are not is with boot devices where the BIOS geometry > may change. Exactly. When you change controllers, you are -- in effect -- changing BIOSes. This, in turn, can change the supported BIOS geometries and the translation scheme. Incompatibilities are most likely to occur if the controller reserves blocks for itself at the beginning or end of the drive. (This is not uncommon; it's a good way to store feature information in a nonvolatile way.) The CAM spec describes a way in which a controller can figure out what another controller was doing when it set up the drive. But as far as I know, controller vendors -- not really caring about the possibility of customers switching brands -- did not implement it widely. --Brett From owner-freebsd-hardware Mon Apr 1 09:55:01 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10448 for hardware-outgoing; Mon, 1 Apr 1996 09:55:01 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA10430 for ; Mon, 1 Apr 1996 09:54:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.5/8.6.10) with SMTP id JAA21922 for freebsd-hardware@freebsd.org; Mon, 1 Apr 1996 09:54:47 -0800 (PST) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199604011754.JAA21922@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: freebsd-hardware@freebsd.org Subject: Parity Errors Date: Mon, 01 Apr 96 09:54:47 -0800 X-Mts: smtp Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a 486DX33 with 20MB of 70ns memory, 64K (unknown speed) cache, an Adaptec 1542CF controller, an IDE controller, a Trident 8900D adapter, a SMC Elite 16 Ethernet card, a parallel/serial card, and a serial card. The motherboard is based on an Opti Chipset. The memory and cache are configured for zero wait state operation. Occasionally the system panics with a parity error. Sometimes I'll get three in one day and other times I won't get an error for six weeks. The errors usually occur during boot, during the mount of a CDROM, or when an NFS client mounts mounts a filesystem. An interesting point is that these errors only occur under FreeBSD (2.0.5R and 2.1.0R). This machine has successfully run DOS, OS/2 2.x, Minix 1.5, Coherent 4.x, and Linux (1.1, 1.2, and 1.3) without any parity errors. The QA Plus diagnostic package, which I've used to find many parity errors before, e.g. when purchasing memory upgrades, did not complain about any problems. Is it possible that FreeBSD is exercising the hardware in a manner it has never been used before or is this a known FreeBSD problem? I can configure the machine for memory and/or cache read or write wait states independently. Should I add a wait state and where, memory or cache, read or write? Any help would be appreciated. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-hardware Mon Apr 1 10:23:50 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA12848 for hardware-outgoing; Mon, 1 Apr 1996 10:23:50 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA12809 Mon, 1 Apr 1996 10:23:41 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id KAA04704; Mon, 1 Apr 1996 10:21:49 -0800 (PST) Message-Id: <199604011821.KAA04704@ref.tfs.com> Subject: Re: Changes to FreeBSD kernel to keep "green" drives on To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Mon, 1 Apr 1996 10:21:49 -0800 (PST) From: "JULIAN Elischer" Cc: freebsd-hardware@FreeBSD.org, hackers@FreeBSD.org, bugs@FreeBSD.org In-Reply-To: <9603018283.AA828378293@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 10:00:44 am X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Here are the diffs to FreeBSD 2.1.0-RELEASE that turn off the inactivity > timer. Turning on these flags will always be a good idea for desktop > systems with "green" hard drives, but the kernel still needs fixing to > handle systems in which an inactivity timeout is desirable (e.g. laptops). My laptop has always beed set up to timeout the drive after 30 secons.. the system has been coping wth this successfully since 386BSD0.1 (1992). the drive takes about 1.5 seconds to spin-up... the standard timeoutes in the driver seem to cope.. when the batery is low it sometimes has to try several times to overcome 'stiction' (you can hear teh drive kick the spindle a couple of times before it starts,, the driver seems to handle this as well, though it takes about 4 seconds to get going in this case. I know phk has been looking at spin-up optimisatiosn.. (e.g. if a drive takes more than a set time to come ready, assumen it was spinning up and schedule a 'sync' to catch it while it's already going.. From owner-freebsd-hardware Mon Apr 1 11:10:58 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18539 for hardware-outgoing; Mon, 1 Apr 1996 11:10:58 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18533 Mon, 1 Apr 1996 11:10:51 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA00611; Tue, 2 Apr 1996 05:06:24 +1000 Date: Tue, 2 Apr 1996 05:06:24 +1000 From: Bruce Evans Message-Id: <199604011906.FAA00611@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >ftp://ftp.seagate.com/techsuppt/misc/no_idle.zip >on Seagate's Web site. Essentially, to turn off the "green mode" >inactivity timer, one issues controller command 0xFB for the relevant >drive, with a 0 in the controller's sector count register, during >initialization. (A number larger than zero sets the timer to that number of >milliseconds.) 0xFB is vendor specific according to the (old) ata-r4c draft. That standard has a lot about sleep, standby and idle modes, but only host- controlled modes. >I'm not a UNIX kernel hacker (or I wasn't, anyway), and was utterly >unfamiliar with all the conventions used in FreeBSD, so the source in >wd.c took quite a while to analyze. (It's much more complex than it needs >to be, and uses -- Aargh! -- uninterruptible busy-waits at the kernel >level. THIS is why the entire OS freezes for seconds at a time.) After It's much less complex than it needs to be :-). >[Aside: Maybe, at the same time, someone could tell me what the SLEEPHACK >configuration bit does. It looks as if it's supposed to make the driver >more tolerant of drive spindowns on laptops, but I'm not sure that it will >work as advertised. On this machine, the unwedge() function, which it >calls, also complains when the disk spins down.] It just forces a wdunwedge() call if the drive is unexpectedly busy in wdcommand(). wdunwedge() might fail because TIMEOUT is too short. It should be at least 31000000 (31 seconds). Bruce From owner-freebsd-hardware Mon Apr 1 11:51:48 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21287 for hardware-outgoing; Mon, 1 Apr 1996 11:51:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA21264 Mon, 1 Apr 1996 11:51:42 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA14012; Mon, 1 Apr 1996 12:47:03 -0700 From: Terry Lambert Message-Id: <199604011947.MAA14012@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Mon, 1 Apr 1996 12:47:02 -0700 (MST) Cc: freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <9603018283.AA828371297@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 02:14:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Tonight, I bit the bullet and hacked the FreeBSD kernel (specifically, the > wdc driver) to disable "green" mode on LARIAT.ORG's ST5660A IDE hard drive. > As reported in earlier messages, the drive was retracting its heads and > spinning down during periods of inactivity, which caused FreeBSD's disk > routines to time out and complain. The system would splatter the screen > with kernel error messages and freeze for seconds at a time. (I haven't > tried FreeBSD on a laptop, but this must occur frequently in that > environment if the same kind of drive is used.) Disabling "green" mode is probably not the cannonically correct soloution. The probably correct soloution would be to recognize the mode is active (spindle motor status query maybe?) and deal with it. The big thing about that is that the retriesand everything would have to be hidden, by class, at a common layer for a clean implementation that didn't care about particular hardware (like yours). > I'm not a UNIX kernel hacker (or I wasn't, anyway), and was utterly > unfamiliar with all the conventions used in FreeBSD, so the source in > wd.c took quite a while to analyze. (It's much more complex than it needs > to be, and uses -- Aargh! -- uninterruptible busy-waits at the kernel > level. THIS is why the entire OS freezes for seconds at a time.) After > much staring at the code, I figured out how to get an existing > function to do most of the work. The increase in kernel size was therefore > negligible. That's a very different problem. Basically, the kernel needs some event level driver preeemptability. You could do this by changing the busy waits to one-shot driven polls... but this would need a one shot facility, and would require significantly reworking the timer code to get that capability. > [Aside: Maybe, at the same time, someone could tell me what the SLEEPHACK > configuration bit does. It looks as if it's supposed to make the driver > more tolerant of drive spindowns on laptops, but I'm not sure that it will > work as advertised. On this machine, the unwedge() function, which it > calls, also complains when the disk spins down.] The unwedge can be a problem -- this was discussed in detail before on the lists -- it had to do with a tiemout while unwedging and the disk spinning up-dow-up-down in yo-yo mode as a result of drive reset. I thought that that had been handled. Anyway, it's better to have a soloution than to just be screwed. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Mon Apr 1 12:16:40 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA23465 for hardware-outgoing; Mon, 1 Apr 1996 12:16:40 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA23411 Mon, 1 Apr 1996 12:16:24 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3qNR-000wsdC; Mon, 1 Apr 96 12:39 PST Received: from cc:Mail by ccgate.infoworld.com id AA828389720; Mon, 01 Apr 96 12:50:46 PST Date: Mon, 01 Apr 96 12:50:46 PST From: "Brett Glass" Message-Id: <9603018283.AA828389720@ccgate.infoworld.com> To: "JULIAN Elischer" Cc: freebsd-hardware@FreeBSD.org, hackers@FreeBSD.org, bugs@FreeBSD.org Subject: Re: Changes to FreeBSD kernel to keep "green" drives on Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > My laptop has always beed set up to timeout the drive after 30 secons.. > the system has been coping wth this successfully since 386BSD0.1 (1992). > the drive takes about 1.5 seconds to spin-up... > the standard timeoutes in the driver seem to cope.. Apparently, it depends on just how long the drive takes to come up to speed. It takes less power if it can ramp up more slowly, so the "greenest" drives will have the worst problems. --Brett From owner-freebsd-hardware Mon Apr 1 13:11:39 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29139 for hardware-outgoing; Mon, 1 Apr 1996 13:11:39 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA29107 for ; Mon, 1 Apr 1996 13:11:33 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3rEv-000wu6C; Mon, 1 Apr 96 13:34 PST Received: from cc:Mail by ccgate.infoworld.com id AA828393031; Mon, 01 Apr 96 13:44:39 PST Date: Mon, 01 Apr 96 13:44:39 PST From: "Brett Glass" Message-Id: <9603018283.AA828393031@ccgate.infoworld.com> To: freebsd-hardware@freebsd.org Subject: Diffs, created using -c option this time Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At the request of Garrett Wollman, I'm sending the diffs again -- this time, using diff -c. Note that x.y.orig is the original source, and x.y is the new source. --Brett *** wd.c.orig Sun Mar 31 21:21:00 1996 --- wd.c Mon Apr 1 00:36:01 1996 *************** *** 103,108 **** --- 103,114 ---- #define WDOPT_SLEEPHACK 0x4000 #define WDOPT_MULTIMASK 0x00ff + #define WDOPT_NO_IDLE_0 0x0100 /* Flags added by Brett Glass to shut off */ + #define WDOPT_NO_IDLE_1 0x0200 /* inactivity timeout on some IDE drives, */ + /* such as ST5660A. On each interface, */ + /* 0x0100 and 0x0200 are for master and */ + /* slave, respectively. */ + static int wd_goaway(struct kern_devconf *, int); static int wdc_goaway(struct kern_devconf *, int); static int wd_externalize(struct proc *, struct kern_devconf *, void *, size_t); *************** *** 227,232 **** --- 233,240 ---- #define DKFL_32BIT 0x00100 /* use 32-bit i/o mode */ #define DKFL_MULTI 0x00200 /* use multi-i/o mode */ #define DKFL_BADSCAN 0x00400 /* report all errors */ + #define DKFL_NO_IDLE 0x00800 /* disk has had inactivity timer + turned off -BG */ struct wdparams dk_params; /* ESDI/IDE drive/controller parameters */ int dk_dkunit; /* disk stats unit number */ int dk_multi; /* multi transfers */ *************** *** 441,446 **** --- 449,456 ---- printf(", multi-block-%d", du->dk_multi); if (du->cfg_flags & WDOPT_SLEEPHACK) printf(", sleep-hack"); + if (du->dk_flags & DKFL_NO_IDLE) + printf(", inactivity timer disabled"); printf("\n"); if (du->dk_params.wdp_heads == 0) printf("wd%d: size unknown, using %s values\n", *************** *** 1608,1613 **** --- 1618,1636 ---- } } else { du->dk_multi = 1; + } + + /* If this drive should have its inactivity timer turned off, issue + the command to do it. If the command succeeds, then set a flag + in the disk's struct so that this can be displayed. -BG */ + + du->dk_flags &= ~DKFL_NO_IDLE; /* Assume command will fail */ + + /* Shift WDOPT_NO_IDLE_0 left if unit 1 to get WDOPT_NO_IDLE_1*/ + if (flags & (WDOPT_NO_IDLE_0 << (du->dk_unit))) { + if (wdcommand(du, 0, 0, 0, 0, WDCC_IDLEMODE) == 0) { + du->dk_flags |= DKFL_NO_IDLE; + } } #ifdef NOTYET ------------------ Cut here ---------------- *** wdreg.h.orig Sun Mar 31 21:20:52 1996 --- wdreg.h Sun Mar 31 21:24:42 1996 *************** *** 97,102 **** --- 97,105 ---- #define WDCC_EXTDCMD 0xE0 /* send extended command */ #define WDCC_READP 0xEC /* read parameters from controller */ #define WDCC_FEATURES 0xEF /* features control */ + /* Following constant added by Brett Glass for the command that + disables/enables "green" mode on drives such as the Seagate ST5660A */ + #define WDCC_IDLEMODE 0xFB /* configure active/idle mode -BG*/ #define WDFEA_RCACHE 0xAA /* read cache enable */ #define WDFEA_WCACHE 0x02 /* write cache enable */ From owner-freebsd-hardware Mon Apr 1 13:11:41 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29150 for hardware-outgoing; Mon, 1 Apr 1996 13:11:41 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA29129 Mon, 1 Apr 1996 13:11:37 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3rEx-000wuBC; Mon, 1 Apr 96 13:34 PST Received: from cc:Mail by ccgate.infoworld.com id AA828393033; Mon, 01 Apr 96 13:53:35 PST Date: Mon, 01 Apr 96 13:53:35 PST From: "Brett Glass" Message-Id: <9603018283.AA828393033@ccgate.infoworld.com> To: Bruce Evans , freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > wdunwedge() might fail because TIMEOUT is too short. It should be at > least 31000000 (31 seconds). Based on Michael's account of what's in the ATA spec (i.e. that the drive can take 30 seconds to come ready), this is correct. But it shouldn't wait the whole 31 seconds always, as the current code would do. It should check again and again and GIVE UP after 31 seconds (or slightly more). Of course, pausing 30 seconds in the kernel could be catastrophic for some applications, so implementing some of those proprietary commands is still useful. The modification I sent in covers Seagate's. --Brett From owner-freebsd-hardware Mon Apr 1 15:16:52 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA11060 for hardware-outgoing; Mon, 1 Apr 1996 15:16:52 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA11039 Mon, 1 Apr 1996 15:16:48 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3tCA-000wqzC; Mon, 1 Apr 96 15:39 PST Received: from cc:Mail by ccgate.infoworld.com id AA828400543; Mon, 01 Apr 96 14:26:29 PST Date: Mon, 01 Apr 96 14:26:29 PST From: "Brett Glass" Message-Id: <9603018284.AA828400543@ccgate.infoworld.com> To: Terry Lambert Cc: freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Disabling "green" mode is probably not the cannonically correct > soloution. No, but it's an important feature to have available. While it's necessary to have the OS "deal with it" when the drive spins down, it's also extremely useful (especially on a multitasking OS with virtual memory) to be able to tell the drive NOT to spin down. Since this involves issuing low-level disk controller commands, it's properly implemented either as a kernel option or as a privileged utility. There's no ioctl to issue a controller command (should there be?), so the code has to go in the kernel for now. > The probably correct soloution would be to recognize > the mode is active (spindle motor status query maybe?) and deal > with it. This should be incorporated as well -- so that users COULD let the drive spin down (e.g. on a laptop). The idea of clock-interrupt-driven polling is a good one, since it would let other tasks run. With 2.0.1-RELEASE, you can't even type on the keyboard while waiting for a drive to spin up. And on this system, IP packets were being dropped, and the serial buffers on the system were overflowing due to incoming PPP traffic! Not good. --Brett From owner-freebsd-hardware Mon Apr 1 16:51:39 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA17747 for hardware-outgoing; Mon, 1 Apr 1996 16:51:39 -0800 (PST) Received: from arnie.systems.sa.gov.au (arnie.systems.sa.gov.au [143.216.242.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA17701 Mon, 1 Apr 1996 16:51:27 -0800 (PST) Received: from state.systems.sa.gov.au by arnie.systems.sa.gov.au (PMDF V4.3-7 #13538) id <01I3295BXWAO003G0B@arnie.systems.sa.gov.au>; Tue, 2 Apr 1996 10:07:58 +1030 Received: from dogbert.systems.sa.gov.au (dogbert.systems.sa.gov.au) by state.systems.sa.gov.au (PMDF V5.0-4 #13538) id <01I32928TV1C002QN2@state.systems.sa.gov.au>; Tue, 02 Apr 1996 10:04:56 +0930 Received: from jolt.systems.sa.gov.au (jolt.systems.sa.gov.au [143.216.237.8]) by dogbert.systems.sa.gov.au (8.6.12/8.6.12) with SMTP id KAA01485; Tue, 02 Apr 1996 10:10:46 +0930 Date: Tue, 02 Apr 1996 10:23:35 +0930 From: Garth Kidd Subject: Re: Cannot boot after install In-reply-to: Brett Glass <"Re: Cannot boot after install"@state.systems.sa.gov.au> (Apr 1, 9:46) To: Brett Glass , Michael Smith Cc: hdalog@zipnet.net, davidg@Root.COM, hardware@FreeBSD.org, bugs@FreeBSD.org Message-id: <960402110732.ZM2871@jolt.systems.sa.gov.au> MIME-version: 1.0 X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <9603018283.AA828378286@ccgate.infoworld.com> Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass wrote: > The kernel hack I did (turning off the power-saving mode) is appropriate > for desktop machines; in fact, for them, it's a good idea. But it's NOT > appropriate for laptops and other low-power applications. The kernel > needs to be fixed so that the drive *can* spin down without locking up > the entire machine. That might be fine for normal filesystem access, Brett, but consider your poor swap partition. If a page fault occurs, the kernel's just going to have to sit around and wait for the drive to spin up, ne? Unless you want to re-write the scheduler so that processes can only get CPU when all of their pages are in memory at the time, you're going to have to either put up with 30-second hangs or run with no swap. -- garth@dogbert.systems.sa.gov.au | Garth Kidd +61-8-207-7740 (voice) | Professional Services Division +61-8-207-7860 (fax) | Southern Systems | Adelaide, AUSTRALIA From owner-freebsd-hardware Mon Apr 1 17:21:00 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20142 for hardware-outgoing; Mon, 1 Apr 1996 17:21:00 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA20122 Mon, 1 Apr 1996 17:20:57 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA14908; Mon, 1 Apr 1996 18:11:01 -0700 From: Terry Lambert Message-Id: <199604020111.SAA14908@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Mon, 1 Apr 1996 18:11:01 -0700 (MST) Cc: terry@lambert.org, freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <9603018284.AA828400543@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 02:26:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Disabling "green" mode is probably not the cannonically correct > > soloution. > > No, but it's an important feature to have available. While it's necessary > to have the OS "deal with it" when the drive spins down, it's also > extremely useful (especially on a multitasking OS with virtual memory) to > be able to tell the drive NOT to spin down. Since this involves issuing > low-level disk controller commands, it's properly implemented either as a > kernel option or as a privileged utility. There's no ioctl to issue a > controller command (should there be?), so the code has to go in the kernel > for now. OK. I agree. There should be an ioctl to issue a controller command for WD controllers -- we have one for SCSI. > > The probably correct soloution would be to recognize > > the mode is active (spindle motor status query maybe?) and deal > > with it. > > This should be incorporated as well -- so that users COULD let the drive > spin down (e.g. on a laptop). The idea of clock-interrupt-driven polling is > a good one, since it would let other tasks run. With 2.0.1-RELEASE, you > can't even type on the keyboard while waiting for a drive to spin up. And > on this system, IP packets were being dropped, and the serial buffers on > the system were overflowing due to incoming PPP traffic! Not good. I would prefer to have a reschedulable one-shot than to directly use the timer interrupt. The distinction is that the interrupt can be scheduled as a one shot down to the hardware resoloution instead of being limited to the clock frequency. The win here is that I can have a hardware interrupt to cause timed service routines in the kernel without giving up RT. This lets you replace recurrening events with rescheduling the oneshot, and replace DELAY() with a one-shot scheduling. The hard part in implementing this would be keeping other things, like the PC speaker sound driver, operational. If all you wanted to solve was the long duration hang of the WDC, I *suppose* (he said reluctantly) you could hook the system clock ISR using a callback registration list of some kind. It would be rather simple to implement, knowing beforehand that your even will occur *after* rather than *when* the timer goes (useless for a floppy tape driver in the kernel to kill of the user space "ft" program). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Mon Apr 1 17:24:05 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20426 for hardware-outgoing; Mon, 1 Apr 1996 17:24:05 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA20300 for ; Mon, 1 Apr 1996 17:23:22 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA08833; Tue, 2 Apr 1996 11:15:30 +0930 From: Michael Smith Message-Id: <199604020145.LAA08833@genesis.atrad.adelaide.edu.au> Subject: Re: Parity Errors To: cschuber@orca.gov.bc.ca Date: Tue, 2 Apr 1996 11:15:29 +0930 (CST) Cc: freebsd-hardware@FreeBSD.org In-Reply-To: <199604011754.JAA21922@passer.osg.gov.bc.ca> from "Cy Schubert - ITSD Open Systems Group" at Apr 1, 96 09:54:47 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Cy Schubert - ITSD Open Systems Group stands accused of saying: > 4.x, and Linux (1.1, 1.2, and 1.3) without any parity errors. The > QA Plus diagnostic package, which I've used to find many parity > errors before, e.g. when purchasing memory upgrades, did not > complain about any problems. Diagnotics like QAPlus aren't worth spit. They don't exercise memory in any of the dozens of interesting ways that 'real' operating systems do. > Is it possible that FreeBSD is exercising the hardware in a manner > it has never been used before or is this a known FreeBSD problem? FreeBSD can't generate NMI signals; it's your motherboard hardware that's doing that. It wouldn't surprise me if Linux just ignored them 8) > I can configure the machine for memory and/or cache read or write > wait states independently. Should I add a wait state and where, > memory or cache, read or write? If you can disable parity checking with your BIOS, do that. Failing that, wind your main memory read and write waitstates out as slow as they'll go, and if you can add DMA waitstates then do that too. It's possible that it's not a speed thing though - it may just be that you have a dodgy memory part and there's nothing you can do about it. > Cy Schubert OV/VM: BCSC02(CSCHUBER) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Mon Apr 1 17:37:33 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA21290 for hardware-outgoing; Mon, 1 Apr 1996 17:37:33 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA21239 for ; Mon, 1 Apr 1996 17:36:13 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA08971; Tue, 2 Apr 1996 11:25:58 +0930 From: Michael Smith Message-Id: <199604020155.LAA08971@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Tue, 2 Apr 1996 11:25:58 +0930 (CST) Cc: Brett_Glass@ccgate.infoworld.com, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603018283.AA828371256@ccgate.infoworld.com> from "Brett Glass" at Mar 31, 96 08:10:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > The code should probably be activated by flags (one per drive for each IDE > interface). What is the proper procedure for implementing and assigning a > device driver flag, and making sure that there are no conflicts? Are any > flag bits reserved in FreeBSD disk drivers? Don't do it this way, particularly since you are adding a command to activate a vendor-specific function. You should create a rogues table, and define your Seagate fix as a 'rogue feature', triggered by the drive id in wdattach(). If the feature were _standard_, then you might want to look at a simple wdcontrol utility and a set of ioctls. > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Mon Apr 1 17:49:10 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA22419 for hardware-outgoing; Mon, 1 Apr 1996 17:49:10 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA22397 Mon, 1 Apr 1996 17:49:06 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3vWg-000wt0C; Mon, 1 Apr 96 18:08 PST Received: from cc:Mail by ccgate.infoworld.com id AA828409505; Mon, 01 Apr 96 18:38:32 PST Date: Mon, 01 Apr 96 18:38:32 PST From: "Brett Glass" Message-Id: <9603018284.AA828409505@ccgate.infoworld.com> To: Garth Kidd , msmith@atrad.adelaide.edu.au Cc: hdalog@zipnet.net, davidg@Root.COM, hardware@FreeBSD.org, bugs@FreeBSD.org Subject: Re: Cannot boot after install Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > That might be fine for normal filesystem access, Brett, but consider your > poor swap partition. If a page fault occurs, the kernel's just going to > have to sit around and wait for the drive to spin up, ne? Not necessarily. It is possible for tasks that have NOT page faulted to keep running while others are waiting for pages to arrive. (It's even better if the swapper can postpone the choosing of the "victim" page until the drive is ready to go, but this is rarely done because most bus mastering controllers need to be pointed at a block of RAM in advance.) If a task that's running in the interim suddenly needs a page, it will simply block and be queued up for it. > Unless you want to re-write the scheduler so that processes can only get > CPU when all of their pages are in memory at the time, you're going to > have to either put up with 30-second hangs or run with no swap. Again, this is not necessary. The key thing is not to have no disk accesses but rather to perform them concurrently with other tasks. It's a fundamental rule of concurrent programming that critical sections should never block or busy-wait. FreeBSD's disk access code breaks that rule, potentially hanging the machine if a peripheral goes offline and leaving it vulnerable to all sorts of hardware quirks. To avoid this, one needs to create a finite state machine. (There is one, of a sort, in the disk code now -- but it is not implemented to avoid busy-waits.) In a correct implementation, each state is a non-blocking critical section. When the state machine must wait for an event (in this case, for the disk to come ready), it alters its state variables in preparation for a state transition and immediately yields control to the scheduler. When it is re-awakened either by a clock tick or by an I/O completion interrupt, it proceeds with the code for the next state. If the clock tick method is used, there will be "polling" states that branch to themselves -- yielding control each time -- until a condition is satisfied. There's a very good and surprisingly interesting exposition of this topic in the book "Soul of a New Machine." It even covers the case of double faults. --Brett From owner-freebsd-hardware Mon Apr 1 19:16:18 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA27806 for hardware-outgoing; Mon, 1 Apr 1996 19:16:18 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA27788 Mon, 1 Apr 1996 19:16:10 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3ww4-000wqNC; Mon, 1 Apr 96 19:39 PST Received: from cc:Mail by ccgate.infoworld.com id AA828414922; Mon, 01 Apr 96 20:12:03 PST Date: Mon, 01 Apr 96 20:12:03 PST From: "Brett Glass" Message-Id: <9603018284.AA828414922@ccgate.infoworld.com> To: Terry Lambert Cc: terry@lambert.org, freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > OK. I agree. There should be an ioctl to issue a controller command > for WD controllers -- we have one for SCSI. Easy to do, since there's already an "issue a controller command" function called wdcommand(). What are the conventions for ioctl numbering, structs passed to ioctls, etc. in FreeBSD? If you're experienced at hacking this kernel, it shouldn't take more than 15 minutes of coding to add the new command. > I would prefer to have a reschedulable one-shot than to directly use > the timer interrupt. > The distinction is that the interrupt can be scheduled as a one shot > down to the hardware resoloution instead of being limited to the clock > frequency. Either kind of timer would probably suffice. High frequencies and super resolutions wouldn't be necessary, since disk I/O is a somewhat slow process. A period of 10-20 milliseconds -- about the same as a typical disk seek time -- would be sufficient. > The win here is that I can have a hardware interrupt to cause timed > service routines in the kernel without giving up RT. > This lets you replace recurrening events with rescheduling the > oneshot, and replace DELAY() with a one-shot scheduling. This would certainly work. But the advantage of the timer is that it would be sharable; the one-shot wouldn't be. In any event, how much would the scheduler and vm modules have to change -- if at all -- to allow unaffected processes to continue during swapper I/O? --Brett From owner-freebsd-hardware Mon Apr 1 21:34:34 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA07872 for hardware-outgoing; Mon, 1 Apr 1996 21:34:34 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA07862 for ; Mon, 1 Apr 1996 21:34:30 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3yt4-000wqNC; Mon, 1 Apr 96 21:44 PST Received: from cc:Mail by ccgate.infoworld.com id AA828422418; Mon, 01 Apr 96 21:54:25 PST Date: Mon, 01 Apr 96 21:54:25 PST From: "Brett Glass" Message-Id: <9603018284.AA828422418@ccgate.infoworld.com> To: Michael Smith Cc: jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Don't do it this way, particularly since you are adding a command > to activate a vendor-specific function. > You should create a rogues table, and define your Seagate fix as a > 'rogue feature', triggered by the drive id in wdattach(). If it were done this way, timeouts would always be turned off even when power savings were desired. It's better to keep it optional. Therefore, two configuration flags -- one for the master and one for the slave -- would still be a good idea, even in the presence of a "rogues" table. The best approach if we did NOT want to use kernel flags would be to create an IOCTL that lets a utility (running with proper permissions, of course) set the controller registers and execute an arbitrary ATA command. This would parallel what's done in the SCSI driver. A user who wanted to disable inactivity timeouts, or wanted to invoke any other drive feature, could write a very simple program to issue the ioctl. The program could be placed in rc, rc.boot, or whichever rc-like file was appropriate. But there's a big disavantage inherent in the latter approach: A user who was INSTALLING FreeBSD could well run into big problems. Why? Because the utility wouldn't be there during installation, and the install might fail if the drive spun down. (This is what happened to me.) Kernel configuration flags, on the other hand, are great because they are available right away. They can be set using the configuration editor at boot time, so that inactivity timeouts are disabled as soon as the OS starts up. So, all things considered, here's how I'd combine your ideas and mine to come up with the most workable solution. I think we should keep the kernel configuration flags, so that the inactivity timer can be turned off immediately (or not!) as the driver starts up. If a drive's NO_IDLE flag is turned on, wdgetctrlr() (which is called by wdattach()) can check a table, as you described. Better still, it can invoke a cascade of detection/configuration routines, each designed to handle some makes and models. The first routine that recognizes the drive configures it and exits the chain. If execution "falls out the bottom," or a configuration command fails, a warning message can be printed indicating that the drive was not recognized. Or we can simply clear the flag I've added to the disk record, so that there's no message indicating that the inactivity timer was turned off. (The big advantage of this approach over a table is that the routines can do specialized parsing on drive IDs, handling groups of model numbers and suffixes elegantly.) For the moment, we could detect just Seagate (which we know how to handle now; in fact, the code already checks to see if the command works on that drive). We can then add more makes and models as we learn how to deal with them. Sound like a plan? --Brett From owner-freebsd-hardware Mon Apr 1 22:22:09 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA11597 for hardware-outgoing; Mon, 1 Apr 1996 22:22:09 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA11579 for ; Mon, 1 Apr 1996 22:21:58 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id QAA12379; Tue, 2 Apr 1996 16:11:32 +0930 From: Michael Smith Message-Id: <199604020641.QAA12379@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Tue, 2 Apr 1996 16:11:32 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603018284.AA828422418@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 09:54:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > > Don't do it this way, particularly since you are adding a command > > to activate a vendor-specific function. > > > You should create a rogues table, and define your Seagate fix as a > > 'rogue feature', triggered by the drive id in wdattach(). > > If it were done this way, timeouts would always be turned off even when > power savings were desired. It's better to keep it optional. Therefore, > two configuration flags -- one for the master and one for the slave -- > would still be a good idea, even in the presence of a "rogues" table. Timeouts should default to off, in order to deal with problems like yours. The rogues table would also be able to indicate to ioctl code that wanted to reenable power-saving modes that the disk required special handling. "Works suboptimally" is a better default case than "crashes strangely". 8) > Kernel configuration flags, on the other hand, are great because > they are available right away. They can be set using the configuration > editor at boot time, so that inactivity timeouts are disabled as soon as > the OS starts up. The flagspace is too small. There are a few ideas brewing (kernel "environment variables", for example) that would help get around this, but nothing that's anywhere near showtime. > immediately (or not!) as the driver starts up. If a drive's NO_IDLE flag is > turned on, wdgetctrlr() (which is called by wdattach()) can check a table, > as you described. Better still, it can invoke a cascade of > detection/configuration routines, each designed to handle some makes and > models. The first routine that recognizes the drive configures it and exits > the chain. If execution "falls out the bottom," or a configuration command That's not so crash hot. Use a table with a list of drive ID responses and flags which define quirks; it's not just at attach time that oddities may have to be worked around. If the ID strings are formatted in a 'civilised' fashion, it should be possible to select on manufacturer, model or revision by only comparing the length of ID supplied in the table. > off. (The big advantage of this approach over a table is that the routines > can do specialized parsing on drive IDs, handling groups of model numbers > and suffixes elegantly.) ... but requiring the wheel to be reinvented for every new quirk, bloating the driver and making the code even harder to understand 8) > Sound like a plan? Throw it around a few more times, let some of the _real_ pickers think about it, and do it! > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Mon Apr 1 23:16:59 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA15556 for hardware-outgoing; Mon, 1 Apr 1996 23:16:59 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA15547 for ; Mon, 1 Apr 1996 23:16:55 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA03313; Mon, 1 Apr 1996 23:15:00 -0800 From: "Rodney W. Grimes" Message-Id: <199604020715.XAA03313@GndRsh.aac.dev.com> Subject: Re: Parity Errors To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 1 Apr 1996 23:15:00 -0800 (PST) Cc: cschuber@orca.gov.bc.ca, freebsd-hardware@FreeBSD.org In-Reply-To: <199604020145.LAA08833@genesis.atrad.adelaide.edu.au> from Michael Smith at "Apr 2, 96 11:15:29 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Cy Schubert - ITSD Open Systems Group stands accused of saying: > > > 4.x, and Linux (1.1, 1.2, and 1.3) without any parity errors. The > > QA Plus diagnostic package, which I've used to find many parity > > errors before, e.g. when purchasing memory upgrades, did not > > complain about any problems. > > Diagnotics like QAPlus aren't worth spit. They don't exercise memory > in any of the dozens of interesting ways that 'real' operating systems > do. And they can't test memory like a real memory tester either. I can show you sticks of simms that run QAPlus for weeks on end but fail under FreeBSD and fail in a simm tester. ... > > I can configure the machine for memory and/or cache read or write > > wait states independently. Should I add a wait state and where, > > memory or cache, read or write? > > If you can disable parity checking with your BIOS, do that. DO NOT DO THIS! Ignoring a hardware fault indicated by the motherboard logic is asking for more problems that it will ever solve. This _CAN_ lead to SERIOUS file system corruption! > Failing that, > wind your main memory read and write waitstates out as slow as they'll go, > and if you can add DMA waitstates then do that too. Wind them out 1 step at a time, going overboard can cause more problems than it solves. Start with the BIOS setup defaults, if you have tweaked these down to zero from a default of 1 it is most likely the cause of your problem. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-hardware Mon Apr 1 23:27:04 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA16329 for hardware-outgoing; Mon, 1 Apr 1996 23:27:04 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA16323 Mon, 1 Apr 1996 23:27:01 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA01028; Tue, 2 Apr 1996 17:23:05 +1000 Date: Tue, 2 Apr 1996 17:23:05 +1000 From: Bruce Evans Message-Id: <199604020723.RAA01028@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> wdunwedge() might fail because TIMEOUT is too short. It should be at >> least 31000000 (31 seconds). >Based on Michael's account of what's in the ATA spec (i.e. that the drive >can take 30 seconds to come ready), this is correct. But it shouldn't wait It should wait 1 second longer for the slave drive. >the whole 31 seconds always, as the current code would do. It should check >again and again and GIVE UP after 31 seconds (or slightly more). Note that long waits (> 10 usec) usually only occur in initialization and panic dump code when it can't even use timeouts. Most waits occur at interrupt time when it can't use tsleep. >Of course, pausing 30 seconds in the kernel could be catastrophic for some >applications, Perhaps more importantly, pausing 30 seconds outside the kernel may be catastrophic :-). There is probably little difference where the wait occurs except on multi-disk-controller systems where the IDE controller is little used. >so implementing some of those proprietary commands is still >useful. The modification I sent in covers Seagate's. It can't be used in the standard driver because its operation is unknown. It might format the drives... Bruce From owner-freebsd-hardware Tue Apr 2 00:16:39 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19538 for hardware-outgoing; Tue, 2 Apr 1996 00:16:39 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA19484 Tue, 2 Apr 1996 00:16:29 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u40GE-0003xOC; Mon, 1 Apr 96 23:12 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id GAA01576; Tue, 2 Apr 1996 06:32:40 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "JULIAN Elischer" cc: Brett_Glass@ccgate.infoworld.com (Brett Glass), freebsd-hardware@FreeBSD.org, hackers@FreeBSD.org, bugs@FreeBSD.org Subject: Re: Changes to FreeBSD kernel to keep "green" drives on In-reply-to: Your message of "Mon, 01 Apr 1996 10:21:49 PST." <199604011821.KAA04704@ref.tfs.com> Date: Tue, 02 Apr 1996 06:32:40 +0000 Message-ID: <1574.828426760@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I know phk has been looking at spin-up optimisatiosn.. > (e.g. if a drive takes more than a set time to come ready, assumen it was > spinning up and schedule a 'sync' to catch it while it's already going.. Actually The thing I did was an utterly disgusting hack "sleep-hack" that assumes that if the disk went to sleep, it will wake up with a different geometry. (workaround for a BIOS-bug). -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hardware Tue Apr 2 00:23:55 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19994 for hardware-outgoing; Tue, 2 Apr 1996 00:23:55 -0800 (PST) Received: from arnie.systems.sa.gov.au (arnie.systems.sa.gov.au [143.216.242.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA19726 Tue, 2 Apr 1996 00:19:28 -0800 (PST) Received: from state.systems.sa.gov.au by arnie.systems.sa.gov.au (PMDF V4.3-7 #13538) id <01I32P5HM8VK003AH1@arnie.systems.sa.gov.au>; Tue, 2 Apr 1996 17:45:41 +1030 Received: from dogbert.systems.sa.gov.au (dogbert.systems.sa.gov.au) by state.systems.sa.gov.au (PMDF V5.0-4 #13538) id <01I32P57FSCW002R40@state.systems.sa.gov.au>; Tue, 02 Apr 1996 17:45:27 +0930 Received: from jolt.systems.sa.gov.au (jolt.systems.sa.gov.au [143.216.237.8]) by dogbert.systems.sa.gov.au (8.6.12/8.6.12) with SMTP id RAA01937; Tue, 02 Apr 1996 17:51:22 +0930 Date: Tue, 02 Apr 1996 15:37:31 +0930 From: Garth Kidd Subject: Re: Cannot boot after install In-reply-to: Brett Glass <"Re: Cannot boot after install"@state.systems.sa.gov.au> (Apr 1, 18:38) To: Brett Glass , Garth Kidd , msmith@atrad.adelaide.edu.au Cc: hdalog@zipnet.net, davidg@Root.COM, hardware@FreeBSD.org, bugs@FreeBSD.org Message-id: <960402184753.ZM2871@jolt.systems.sa.gov.au> MIME-version: 1.0 X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <9603018284.AA828409505@ccgate.infoworld.com> Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > That might be fine for normal filesystem access, Brett, but consider > > your poor swap partition. If a page fault occurs, the kernel's just > > going to have to sit around and wait for the drive to spin up, ne? > > Not necessarily. It is possible for tasks that have NOT page faulted to > keep running while others are waiting for pages to arrive. That's a nice trick. Deem whistles and cheers included for whomever is responsible :). -- garth@dogbert.systems.sa.gov.au | Garth Kidd +61-8-207-7740 (voice) | Professional Services Division +61-8-207-7860 (fax) | Southern Systems | Adelaide, AUSTRALIA From owner-freebsd-hardware Tue Apr 2 00:48:19 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA21035 for hardware-outgoing; Tue, 2 Apr 1996 00:48:19 -0800 (PST) Received: from ns.cityscape.co.uk (ns.cityscape.co.uk [194.159.0.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA21029 Tue, 2 Apr 1996 00:48:14 -0800 (PST) Received: from ns.cityscape.co.uk (ns.cityscape.co.uk [194.159.0.5]) by ns.cityscape.co.uk (8.6.4/8.6.4) with SMTP id JAA04540; Tue, 2 Apr 1996 09:48:43 +0100 Date: Tue, 2 Apr 1996 09:48:42 +0100 (BST) From: Bernard Jauregui To: freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org Subject: Internal ISDN Cards Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Using FreeBSD in all our routers, it would be really good to have ISDN cards in some some machines, however I can find nothing documented. Are no generally available cards supported ? Has anyone else any experience with ISDN and BSD ? Does anyone know of an internal ISDN card that mimics a COM port (as modems do) ? Racal have generously lent me a couple of X.Toll cards. What resources are available for developing a native BSD driver ? I have minimal UNIX kernel hacking experience - is driver writing a big deal ? Thanks for any help here. BJ From owner-freebsd-hardware Tue Apr 2 02:04:34 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA29464 for hardware-outgoing; Tue, 2 Apr 1996 02:04:34 -0800 (PST) Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA29434 Tue, 2 Apr 1996 02:04:25 -0800 (PST) From: garyj@frt.dec.com Received: from cssmuc.frt.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA27398; Tue, 2 Apr 1996 01:54:57 -0800 Received: from localhost by cssmuc.frt.dec.com; (5.65v3.2/1.1.8.2/14Nov95-0232PM) id AA11054; Tue, 2 Apr 1996 11:54:47 +0200 Message-Id: <9604020954.AA11054@cssmuc.frt.dec.com> X-Mailer: exmh version 1.6.4 10/10/95 To: bernard%cityscape.co.uk@inet-gw-1.pa.dec.com Cc: questions%freebsd.org@inet-gw-1.pa.dec.com, freebsd-hardware%freebsd.org@inet-gw-1.pa.dec.com In-Reply-To: Message from Bernard Jauregui of Tue, 02 Apr 96 09:48:42 BST. Reply-To: gjennejohn@frt.dec.com Subject: Re: Internal ISDN Cards Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Apr 96 11:54:46 +0200 X-Mts: smtp Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk bernard@cityscape.co.uk writes: > > Using FreeBSD in all our routers, it would be really good to have ISDN > cards in some some machines, however I can find nothing documented. > > Are no generally available cards supported ? > depends on what you mean by "generally available". At the moment only some cards by German manufacturers are supported. These cards are the Teles/Creatix S0/16, the Teles S0/16.3 (actually, this is under development) and the so-called niccy cards from Dr. Neuhaus. > Has anyone else any experience with ISDN and BSD ? > I, and a number of others here in Gemany, are using it with good success. Of course, we're using the German cards. > Does anyone know of an internal ISDN card that mimics a COM port (as > modems do) ? > There's a number of them. Look at Dan Kegel's ISDN page. He lists a whole slew of cards there. There's even some company in the UK which makes an internal ISDN card that looks like a serial port. The URL is: http://www.alumni.caltech.edu/~dank/isdn/ > Racal have generously lent me a couple of X.Toll cards. What resources > are available for developing a native BSD driver ? > > I have minimal UNIX kernel hacking experience - is driver writing a big > deal ? > Can be. Do you have all the documentation needed to write a driver which can talk to the board ? Like register descriptions, memory maps, etc. ? What does the board look like ? Is it memory-mapped, port-mapped, do you have to download code to it ? Lots of questions which can't be answered without more info. Linux supports lots of cards. Try looking at recent Linux kernel source. --- Gary Jennejohn (work) gjennejohn@frt.dec.com (home) Gary.Jennejohn@munich.netsurf.de (play) gj@freebsd.org From owner-freebsd-hardware Tue Apr 2 02:47:17 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA04540 for hardware-outgoing; Tue, 2 Apr 1996 02:47:17 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA04518 Tue, 2 Apr 1996 02:47:05 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA08815; Tue, 2 Apr 1996 20:40:15 +1000 Date: Tue, 2 Apr 1996 20:40:15 +1000 From: Bruce Evans Message-Id: <199604021040.UAA08815@godzilla.zeta.org.au> To: julian@ref.tfs.com, phk@critter.tfs.com Subject: Re: Changes to FreeBSD kernel to keep "green" drives on Cc: Brett_Glass@ccgate.infoworld.com, bugs@freebsd.org, freebsd-hardware@freebsd.org, hackers@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Actually The thing I did was an utterly disgusting hack "sleep-hack" that >assumes that if the disk went to sleep, it will wake up with a different >geometry. (workaround for a BIOS-bug). Workaround for a FreeBSD bug? I think the usual way out of full sleep mode is to do a soft reset, and it's reasonable for that to set the geometry to the default. The driver may have worked without the hack by getting confused enough to call wdunwedge() to wake up the drive The hack probably made this more deterministic. The driver now always uses the default geometry, so setting the geometry after wakeup is probably a no-op. However, IIRC the standard says to always set it after resets. Bruce From owner-freebsd-hardware Tue Apr 2 03:26:03 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA07116 for hardware-outgoing; Tue, 2 Apr 1996 03:26:03 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA07111 Tue, 2 Apr 1996 03:26:01 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u44CZ-0003vlC; Tue, 2 Apr 96 03:24 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id LAA02779; Tue, 2 Apr 1996 11:24:38 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: julian@ref.tfs.com, Brett_Glass@ccgate.infoworld.com, bugs@freebsd.org, freebsd-hardware@freebsd.org, hackers@freebsd.org Subject: Re: Changes to FreeBSD kernel to keep "green" drives on In-reply-to: Your message of "Tue, 02 Apr 1996 20:40:15 +1000." <199604021040.UAA08815@godzilla.zeta.org.au> Date: Tue, 02 Apr 1996 11:24:36 +0000 Message-ID: <2777.828444276@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Actually The thing I did was an utterly disgusting hack "sleep-hack" that > >assumes that if the disk went to sleep, it will wake up with a different > >geometry. (workaround for a BIOS-bug). > > Workaround for a FreeBSD bug? No, a BIOS-bug. > I think the usual way out of full sleep > mode is to do a soft reset, and it's reasonable for that to set the > geometry to the default. yes, but the APM BIOS-oid sets a different, and pretty badly wrong geometry, so I have to reset the drives default geometry. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hardware Tue Apr 2 03:44:41 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA08679 for hardware-outgoing; Tue, 2 Apr 1996 03:44:41 -0800 (PST) Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA08654 for ; Tue, 2 Apr 1996 03:44:32 -0800 (PST) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id MAA20358 for freebsd-hardware@freebsd.org; Tue, 2 Apr 1996 12:16:55 +0200 Message-Id: <199604021016.MAA20358@nixpbe.pdb.sni.de> Subject: Re: Internal ISDN Cards To: bernard@cityscape.co.uk (Bernard Jauregui) Date: Tue, 2 Apr 96 13:37:39 MET DST From: Greg Lehey Cc: freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org, isdn@muc.ditec.de In-Reply-To: ; from "Bernard Jauregui" at Apr 2, 96 9:48 am X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Using FreeBSD in all our routers, it would be really good to have ISDN > cards in some some machines, however I can find nothing documented. Yes, I'm afraid documentation is still a problem :-( > Are no generally available cards supported ? Currently supported boards include the Teles and Creatix S0 and Dr. Neuhaus Niccy 3008 and 3009. > Does anyone know of an internal ISDN card that mimics a COM port (as > modems do) ? We've been through quite a lengthy discussion of this point in hackers and the ISDN list recently. The result was that the Germans didn't think much of the modem-style TAs (and the Americans did). I won't bore people with my reasons again, but basically dedicated ISDN boards are cheaper, faster and more reliable. On the down side, we still need to get the software up to scratch. > Has anyone else any experience with ISDN and BSD ? There's a mail list at isdn@muc.ditec.de. At the moment I've forgotten how to sign up--Gary, your call (why didn't you mention this in your reply)? The language is supposed to be English, though sometimes people lapse... > Racal have generously lent me a couple of X.Toll cards. What resources > are available for developing a native BSD driver ? Gary's gone into detail here. What are the boards like? ------------------------------------------------------------ Greg Lehey LEMIS grog@lemis.de Schellnhausen 2 Tel: +49-6637-919123 36325 Feldatal Fax: +49-6637-919122 Germany From owner-freebsd-hardware Tue Apr 2 03:57:36 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA09675 for hardware-outgoing; Tue, 2 Apr 1996 03:57:36 -0800 (PST) Received: from gw.muc.ditec.de (gw.muc.ditec.de [194.120.126.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA09656 Tue, 2 Apr 1996 03:57:27 -0800 (PST) Received: from tartufo.muc.ditec.de (tartufo.muc.ditec.de [134.98.18.2]) by gw.muc.ditec.de (8.6.11/8.6.9) with SMTP id NAA12549; Tue, 2 Apr 1996 13:48:14 +0200 Received: by tartufo.muc.ditec.de (/\=-/\ Smail3.1.16.1 #16.39) id ; Tue, 2 Apr 96 13:51 MSZ Message-Id: From: me@tartufo.muc.ditec.de (Michael Elbel) Subject: Re: Internal ISDN Cards To: lehey.pad@sni.de (Greg Lehey) Date: Tue, 2 Apr 1996 13:51:03 +0200 (MSZ) Cc: bernard@cityscape.co.uk, freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org, isdn@muc.ditec.de In-Reply-To: <199604021016.MAA20362@nixpbe.pdb.sni.de> from "Greg Lehey" at Apr 2, 96 01:37:39 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Has anyone else any experience with ISDN and BSD ? > > There's a mail list at isdn@muc.ditec.de. At the moment I've > forgotten how to sign up--Gary, your call (why didn't you mention this Send mail to isdn-request@muc.ditec.de Michael -- Michael Elbel, DITEC, Muenchen, Germany - me@muc.ditec.de Fermentation fault (coors dumped) From owner-freebsd-hardware Tue Apr 2 04:00:11 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA10029 for hardware-outgoing; Tue, 2 Apr 1996 04:00:11 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA09854 Tue, 2 Apr 1996 03:59:58 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA12115; Tue, 2 Apr 1996 21:51:57 +1000 Date: Tue, 2 Apr 1996 21:51:57 +1000 From: Bruce Evans Message-Id: <199604021151.VAA12115@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: Changes to FreeBSD kernel to keep "green" drives on Cc: Brett_Glass@ccgate.infoworld.com, bugs@freebsd.org, freebsd-hardware@freebsd.org, hackers@freebsd.org, julian@ref.tfs.com Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Workaround for a FreeBSD bug? >No, a BIOS-bug. >> I think the usual way out of full sleep >> mode is to do a soft reset, and it's reasonable for that to set the >> geometry to the default. >yes, but the APM BIOS-oid sets a different, and pretty badly wrong geometry, >so I have to reset the drives default geometry. Does it just set the BIOS geometry? Who would know what that is :-). I guess it is setting the geometry so that drivers don't have to. If it was any good then it would make it appear that the drive was never asleep, and then the sleep hack couldn't work. Bruce From owner-freebsd-hardware Tue Apr 2 04:09:23 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA11043 for hardware-outgoing; Tue, 2 Apr 1996 04:09:23 -0800 (PST) Received: from aztec.co.za (aztec.co.za [196.7.70.131]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA11036 for ; Tue, 2 Apr 1996 04:09:20 -0800 (PST) Received: from pcmgate.pcm.co.za [196.3.254.241] by aztec.co.za with smtp (Smail3.1.29.1 #2) id m0u44sT-000aqXC; Tue, 2 Apr 96 14:08 EET Received: from IRVINEP5 (irvinep5.pcm.co.za [196.3.226.90]) by pcmgate.pcm.co.za (8.6.12/8.6.12) with SMTP id OAA03973 for ; Tue, 2 Apr 1996 14:00:54 +0200 Message-Id: <199604021200.OAA03973@pcmgate.pcm.co.za> Comments: Authenticated sender is From: "Irvine Short" Organization: Professional Computer Manufacturers To: freebsd-hardware@freebsd.org Date: Tue, 2 Apr 1996 14:04:57 +2 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: sio2: 65 events for device with no tp Reply-to: ishort@pcm.co.za X-Confirm-Reading-To: ishort@pcm.co.za X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Windows (v2.30) Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi All What is this message? I have just compiled a kernel with support for an ARNET 8 port serial card with 8 16450 ports in it. If I can make it work thenI will upgrade the chips to 16550's. my dmesg output is fine, listing all my serial ports sio0 thru sio9 The Arnet is set to IRQ 9 and base addresses 200 for the first 4 ports and 220 for the second 4 After having removed the reference to IRQ 7 on the lpt line I am getting lots of stray IRQ7 messages. Does this mean that the card is generatingIRQ's even with nothing connected to it and the OS does not know what to do with them? Regards, Irvine Short http://www.pcm.co.za/homepage/ishort/irv_home.html Technical Support Professional Computer Manufacturers Cape Town, South Africa Tel: ++27-21-235084 Fax ++27-21-235089 From owner-freebsd-hardware Tue Apr 2 04:09:41 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA11087 for hardware-outgoing; Tue, 2 Apr 1996 04:09:41 -0800 (PST) Received: from fire.dkrz.de (fire.dkrz.de [136.172.110.250]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA11072 for ; Tue, 2 Apr 1996 04:09:33 -0800 (PST) Received: from racer.dkrz.de (racer.dkrz.de [136.172.110.55]) by fire.dkrz.de (8.7.5/8.7.3) with ESMTP id OAA14355; Tue, 2 Apr 1996 14:08:30 +0200 (MET DST) Received: (from gwk@localhost) by racer.dkrz.de (8.7.4/8.7.3) id OAA15017; Tue, 2 Apr 1996 14:06:05 +0200 (MET DST) Date: Tue, 2 Apr 1996 14:06:05 +0200 (MET DST) Message-Id: <199604021206.OAA15017@racer.dkrz.de> From: "Georg-W. Koltermann" To: msmith@atrad.adelaide.edu.au CC: cschuber@orca.gov.bc.ca, freebsd-hardware@FreeBSD.org In-reply-to: <199604020145.LAA08833@genesis.atrad.adelaide.edu.au> (message from Michael Smith on Tue, 2 Apr 1996 11:15:29 +0930 (CST)) Subject: Re: Parity Errors Reply-to: gwk@cray.com Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > From: Michael Smith > Date: Tue, 2 Apr 1996 11:15:29 +0930 (CST) > Cc: freebsd-hardware@FreeBSD.org >> > Cy Schubert - ITSD Open Systems Group stands accused of saying: > > ... > > > I can configure the machine for memory and/or cache read or write > > wait states independently. Should I add a wait state and where, > > memory or cache, read or write? > > If you can disable parity checking with your BIOS, do that. ... Huh? Why would THAT be a good idea? I at least prefer to get the error message and abort instead of silently continuing with false data!!! Regards, Georg-W. Koltermann, gwk@cray.com From owner-freebsd-hardware Tue Apr 2 04:28:55 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA15408 for hardware-outgoing; Tue, 2 Apr 1996 04:28:55 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA15376 for ; Tue, 2 Apr 1996 04:28:49 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id WAA14688; Tue, 2 Apr 1996 22:20:55 +0930 From: Michael Smith Message-Id: <199604021250.WAA14688@genesis.atrad.adelaide.edu.au> Subject: Re: Parity Errors To: gwk@cray.com Date: Tue, 2 Apr 1996 22:20:55 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, cschuber@orca.gov.bc.ca, freebsd-hardware@FreeBSD.org In-Reply-To: <199604021206.OAA15017@racer.dkrz.de> from "Georg-W. Koltermann" at Apr 2, 96 02:06:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Georg-W. Koltermann stands accused of saying: > > > > If you can disable parity checking with your BIOS, do that. ... > > Huh? Why would THAT be a good idea? Because the machine will keep going. I have at least one, possibly two systems here that generate spurious NMI's on a regular basis. If the system subsequently fails to work happily, there's some other problem. One step at a time... (FWIW, both of the offending systems 'make world' quite happily, although one has no provision for disabling NMI in the BIOS and thus requires one to continue from ddb.) > I at least prefer to get the error message and abort instead of > silently continuing with false data!!! 'tall depends on where the real error is I guess 8) > Georg-W. Koltermann, gwk@cray.com -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Tue Apr 2 04:34:55 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA16731 for hardware-outgoing; Tue, 2 Apr 1996 04:34:55 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA16683 Tue, 2 Apr 1996 04:34:44 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u45H5-0003vnC; Tue, 2 Apr 96 04:33 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id MAA02986; Tue, 2 Apr 1996 12:33:27 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: Brett_Glass@ccgate.infoworld.com, bugs@freebsd.org, freebsd-hardware@freebsd.org, hackers@freebsd.org, julian@ref.tfs.com Subject: Re: Changes to FreeBSD kernel to keep "green" drives on In-reply-to: Your message of "Tue, 02 Apr 1996 21:51:57 +1000." <199604021151.VAA12115@godzilla.zeta.org.au> Date: Tue, 02 Apr 1996 12:33:26 +0000 Message-ID: <2984.828448406@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Workaround for a FreeBSD bug? > >No, a BIOS-bug. > > >> I think the usual way out of full sleep > >> mode is to do a soft reset, and it's reasonable for that to set the > >> geometry to the default. > >yes, but the APM BIOS-oid sets a different, and pretty badly wrong geometry, > >so I have to reset the drives default geometry. > > Does it just set the BIOS geometry? Who would know what that is :-). > I guess it is setting the geometry so that drivers don't have to. If > it was any good then it would make it appear that the drive was never > asleep, and then the sleep hack couldn't work. The problem is that my drive has 1400 cyls, 16 heads, 63 S/T the bios munges this various ways, it bitands 1023 on the cylinder and chops the heads to 15. You can see what that does to the capacity. Until somebody can reburn the BIOS eprom for me, I'll have to live with that hack :-( -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hardware Tue Apr 2 06:02:34 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA24655 for hardware-outgoing; Tue, 2 Apr 1996 06:02:34 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA24637 Tue, 2 Apr 1996 06:02:27 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id XAA26252; Tue, 2 Apr 1996 23:58:46 +1000 Date: Tue, 2 Apr 1996 23:58:46 +1000 From: Bruce Evans Message-Id: <199604021358.XAA26252@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, terry@lambert.org Subject: Re: Hacked kernel with option to disable "green" mode Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Easy to do, since there's already an "issue a controller command" function >called wdcommand(). What are the conventions for ioctl numbering, >structs passed to ioctls, etc. in FreeBSD? If you're experienced at >hacking this kernel, it shouldn't take more than 15 minutes of coding to >add the new command. If you're experienced then you will know that only bugs can be added in 15 minutes. wdcommand() only issues the command. The results of the command would be reported at the next interrupt and might confuse the handling of the next command. You can wait for the results using wdwait(), as is done in wdgetctlr(), etc., but busy-waiting is evil. ioctl() can sleep, but this moves the problem to stopping concurrent access to the controller. The DKFL_LABELLING flag is a hack to avoid the problem at first-open time. There used to be calls to wdwsetctlr() for the label-setting ioctls (changing the geometry in the label used to change it in the controller), but concurrent access wasn't handled right for that case. >> I would prefer to have a reschedulable one-shot than to directly use >> the timer interrupt. > ... >> This lets you replace recurrening events with rescheduling the >> oneshot, and replace DELAY() with a one-shot scheduling. >This would certainly work. But the advantage of the timer is that it would >be sharable; the one-shot wouldn't be. You haven't seen Terry's one-shot timers :-). Neither have I, but I expect they would be shareable. E.g., if the next interrupt is scheduled after 75 usec and something wants one after 22 usec, then the timer would be reprogrammed to schedule the next interrupt after 22 usec nsec and again later to schedule the original interrupt. Of course, it might take 5-20 usec to reprogram the timer (20 usec on a 386/20) and another 5-20 usec to switch contexts, not to mention 5-20 usec to accept the interrupt and 5-20 usec to handle it, so one-shots are probably not viable for such small timeouts. I think they will be viable for timeouts a few hundred usec when the system becomes more real-time. See another discussion about bugs that cause clock latencies of > 10000 usec. >In any event, how much would the scheduler and vm modules have to change >-- if at all -- to allow unaffected processes to continue during swapper >I/O? Not at all, I think. Large changes would probably be required to give enough (if any) unaffected processes. Bruce From owner-freebsd-hardware Tue Apr 2 08:08:51 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05332 for hardware-outgoing; Tue, 2 Apr 1996 08:08:51 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA05326 for ; Tue, 2 Apr 1996 08:08:48 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u490E-000wzQC; Tue, 2 Apr 96 08:32 PST Received: from cc:Mail by ccgate.infoworld.com id AA828461240; Tue, 02 Apr 96 08:30:30 PST Date: Tue, 02 Apr 96 08:30:30 PST From: "Brett Glass" Message-Id: <9603028284.AA828461240@ccgate.infoworld.com> To: Michael Smith Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Timeouts should default to off, in order to deal with problems like > yours. I'm not so sure. Pity the poor laptop owner whose drive spins up relatively quickly (so that turning off the timeout isn't absolutely necessary). He installs FreeBSD, and suddenly finds his batteries completely discharged! The mailing lists receive dozens of complaints, and FreeBSD becomes known as a notebook power hog. > The rogues table would also be able to indicate to ioctl code > that wanted to reenable power-saving modes that the disk required special > handling. In other words, you'd want to create a "power saving" ioctl? > The flagspace is too small. In this case, it's easy to enlarge. Just expose per-drive flags as well as per-controller flags. > That's not so crash hot. Use a table with a list of drive ID responses > and flags which define quirks; it's not just at attach time that oddities > may have to be worked around. A table would not cover all the contingencies. Each manufacturer has its own way of creating model numbers for products. Some put letters at the beginning; some at the end. Some have, over time, switched the letters from the end to the beginning or vice versa. (Maxtor, for example, moved the letters from the end to the beginning, then added more at the end again.) Some have hyphens in the model numbers (or have added or removed them over time). Some have dozens of models that act similarly; there's no need to bloat the table by adding every one. Some have even changed their numbering systems during mergers and acquisitions. A cascade of routines that both recognize ID strings and act on the relevant devices is, in my experience, the most efficient and elegant solution. If one tries to implement a table, one winds up having to include recognition code anyway; the table becomes a waste of space. > ... but requiring the wheel to be reinvented for every new quirk, > bloating the driver and making the code even harder to understand 8) If the code is organized in a sensible manner, and has even a few comments saying what it's doing, it is easier to understand. As for bloating: as explained above, a table would likely bloat the code more than a simple routine. The code to issue the command is usually quite small; I did the Seagate in three lines (including just one function call). The recognition code *has* to be there if one is going to have accurate recognition. --Brett From owner-freebsd-hardware Tue Apr 2 08:31:02 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA07006 for hardware-outgoing; Tue, 2 Apr 1996 08:31:02 -0800 (PST) Received: from persprog.com (persprog.com [204.215.255.203]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA07001 for ; Tue, 2 Apr 1996 08:30:56 -0800 (PST) Received: by persprog.com (8.7.5/4.10) id LAA23718; Tue, 2 Apr 1996 11:27:28 -0500 Received: from novell(192.2.2.201) by cerberus.ppi.com via smap (V1.3) id sma023716; Tue Apr 2 11:27:23 1996 Received: from NOVELL/SpoolDir by novell.persprog.com (Mercury 1.12); Tue, 2 Apr 96 11:25:28 +0500 Received: from SpoolDir by NOVELL (Mercury 1.12); Tue, 2 Apr 96 11:25:22 +0500 From: "David Alderman" Organization: Personalized Programming, Inc. To: freebsd-hardware@FreeBSD.org, cschuber@orca.gov.bc.ca Date: Tue, 2 Apr 1996 11:25:21 EST Subject: Re: Parity Errors Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <76BBE93DA1@novell.persprog.com> Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > FreeBSD can't generate NMI signals; it's your motherboard hardware that's > doing that. It wouldn't surprise me if Linux just ignored them 8) > I've seen NMI's come out of motherboards from problems other than main RAM. Sometimes noise or other problems can cause NMI's with poor motherboard designs. I seem to remember stray DMA requests can sometimes trigger an NMI. Has anyone seen parity on the cache? It's probably not FreeBSD to blame - it is more likely FreeBSD is revealing a latent weakness in your system. Does anyone remember if NMI is brought out to the ISA bus? This would open up all kinds of possibilities. ====================================== When philosophy conflicts with reality, choose reality. Dave Alderman -- dave@persprog.com ====================================== From owner-freebsd-hardware Tue Apr 2 09:27:32 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10409 for hardware-outgoing; Tue, 2 Apr 1996 09:27:32 -0800 (PST) Received: from sneezy (sneezy.sri.com [128.18.40.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA10402 for ; Tue, 2 Apr 1996 09:27:29 -0800 (PST) Received: by sneezy (SMI-8.6/SMI-SVR4) id JAA29670; Tue, 2 Apr 1996 09:22:23 -0800 Date: Tue, 2 Apr 1996 09:22:23 -0800 From: nate@sneezy.sri.com (Nate Williams ) Message-Id: <199604021722.JAA29670@sneezy> To: "Brett Glass" Cc: Michael Smith , hardware@FreeBSD.ORG Subject: Re: Cannot boot after install In-Reply-To: <9603018283.AA828378286@ccgate.infoworld.com> References: <9603018283.AA828378286@ccgate.infoworld.com> Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ Been off the air on a business trip. Don't expect rapid replies as my email machine is 3000 miles away, and the lag is no fun. ] > > Note that there are some interesting comments in the ATA spec I was > > referring to regarding power-saving modes. Basically, the "lowest" a > > drive is allowed to go without an explicit command should still respond, > > as per normal, to commands, however response may be delayed by up to 30 > > seconds. If your drive is responding with an error condition (indicating > > that it's gone into 'sleep' mode), it is violating the spec. ... > However, FreeBSD literally locks up until it sees a response from > the drive. This is a problem with FreeBSD. It should not busy-wait in > the kernel, forsaking all other tasks, until it gets a response. This is, > after all, a multitasking OS! ;-) > > The kernel hack I did (turning off the power-saving mode) is appropriate > for desktop machines; in fact, for them, it's a good idea. But it's NOT > appropriate for laptops and other low-power applications. The kernel needs > to be fixed so that the drive *can* spin down without locking up the entire > machine. FWIW, the same problem occurs on my laptop occasionally when it goes into APM mode. Most of the time it'll come up fine, but occasionally it'll lockup tight and I have to power-cycle the box. This *is* a problem, but unless someone dives in (not me) and figures it out it will continue to to crop up in FreeBSD. Nate From owner-freebsd-hardware Tue Apr 2 10:29:28 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13508 for hardware-outgoing; Tue, 2 Apr 1996 10:29:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA13487 Tue, 2 Apr 1996 10:29:21 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA16657; Tue, 2 Apr 1996 11:23:05 -0700 From: Terry Lambert Message-Id: <199604021823.LAA16657@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Tue, 2 Apr 1996 11:23:05 -0700 (MST) Cc: terry@lambert.org, freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <9603018284.AA828414922@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 08:12:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > OK. I agree. There should be an ioctl to issue a controller command > > for WD controllers -- we have one for SCSI. > > Easy to do, since there's already an "issue a controller command" function > called wdcommand(). What are the conventions for ioctl numbering, > structs passed to ioctls, etc. in FreeBSD? If you're experienced at > hacking this kernel, it shouldn't take more than 15 minutes of coding to > add the new command. Well, then there he goes -- send the 0xFB out that way -- does the 0xFB have to go out at the start, or could we, for instance, send it after initialization? It seems to me the best place for disabling "green" mode would be in a user hack to the /etc/rc.local. > > I would prefer to have a reschedulable one-shot than to directly use > > the timer interrupt. > > > The distinction is that the interrupt can be scheduled as a one shot > > down to the hardware resoloution instead of being limited to the clock > > frequency. > > Either kind of timer would probably suffice. High frequencies and super > resolutions wouldn't be necessary, since disk I/O is a somewhat slow > process. A period of 10-20 milliseconds -- about the same as a typical > disk seek time -- would be sufficient. I was thinking in terms of floppy tapes that: 1) Are not on a FIFO'ed chip 2) Have a 200uS window before they lose resynchronization. The window can be stretched by haveing two buffers in the kernel and alternating them while repositioning the tape, but even the 10ms window that results is unreliable, since you would require either very high priority or no other qunatum use while using the tape. Think "network backup" and you'll realize that it's impossible to have a useful floppy tape driver without the ability to interrupt whatever is going on and hande it within 200uS, without regard to other processes on the machine. Ade's FT driver for BSDI is a good example of how to push out all the possible windows, but 30% of the CPU spent in DELAY() is a bad thing. At the very least, given some IDE or cheap net card overhead (ie: the kind of hardware that is owned by the kind of people who buy floppy tapes), it means the tape can never stream. > > The win here is that I can have a hardware interrupt to cause timed > > service routines in the kernel without giving up RT. > > > This lets you replace recurrening events with rescheduling the > > oneshot, and replace DELAY() with a one-shot scheduling. > > This would certainly work. But the advantage of the timer is that it would > be sharable; the one-shot wouldn't be. Not true. This is why it would have to be a reschedulable one-shot. You would maintain a btree with a link increment delta in a time ordered list. This would allow you to reschedule the one-shot to the smallest remaining delta each time, and subtract the delta from any remaining list elements. This means you couldn't have 5000 of them going at once and still get 200uS, but you wouldn't use it for normal timer things, you'd use it for deadlining (ie: device probes, floppy tape, serial port paritally full FIFO polling, etc.). > In any event, how much would the scheduler and vm modules have to change > -- if at all -- to allow unaffected processes to continue during swapper > I/O? Not at all. That's the beauty of using a real timer interrupt to handle the event. Interrupt processing is handled seperately from the scheduler. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Tue Apr 2 12:06:04 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA21906 for hardware-outgoing; Tue, 2 Apr 1996 12:06:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21901 Tue, 2 Apr 1996 12:06:02 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA16874; Tue, 2 Apr 1996 13:00:48 -0700 From: Terry Lambert Message-Id: <199604022000.NAA16874@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: bde@zeta.org.au (Bruce Evans) Date: Tue, 2 Apr 1996 13:00:47 -0700 (MST) Cc: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <199604020723.RAA01028@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 05:23:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Note that long waits (> 10 usec) usually only occur in initialization and > panic dump code when it can't even use timeouts. Most waits occur at > interrupt time when it can't use tsleep. Hence my suggestion to event schedule. It would have to be coupled with a queue abstraction of interrupt handling; specifically, a SVR4/WindowsNT style top/bottom handler division, where the point of the service routine is to queu the interrupt as an event and allow further interrupts. This has the negative side effective of increasing latency, and the positive side effect of increasing concurrency (ie: it can be set to take another interrupt from the same device right after the event has be queued instead of at service time). FreeBSD's interrupt code is close to this anyway, especially with some of the recent changes. The timer interrupt is an event trigger. For long duration events which can take place "after so much time has elapsed" instead of "when so much time has elapsed", hooking the standard timer interrupt with a function callback is perfectly acceptable. > >Of course, pausing 30 seconds in the kernel could be catastrophic for some > >applications, > > Perhaps more importantly, pausing 30 seconds outside the kernel may be > catastrophic :-). There is probably little difference where the wait > occurs except on multi-disk-controller systems where the IDE controller > is little used. This is not an issue if the quantum period times the number of ready-to-run processes does not exceed the maximum allowable delay period (which is why the timer is unacceptable for moving "ft" functionality into the floppy tape driver in the kernel). > >so implementing some of those proprietary commands is still > >useful. The modification I sent in covers Seagate's. > > It can't be used in the standard driver because its operation is unknown. > It might format the drives... Yes, I agree. It should be a standalone command using the wdcontrol() interface that the user must specify, with knowledge of the potential consequences, instead of a config option that a user might say "this looks like what I need -- I'll try it". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Tue Apr 2 12:17:37 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22885 for hardware-outgoing; Tue, 2 Apr 1996 12:17:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22880 Tue, 2 Apr 1996 12:17:33 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA16910; Tue, 2 Apr 1996 13:11:45 -0700 From: Terry Lambert Message-Id: <199604022011.NAA16910@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: bde@zeta.org.au (Bruce Evans) Date: Tue, 2 Apr 1996 13:11:45 -0700 (MST) Cc: Brett_Glass@ccgate.infoworld.com, terry@lambert.org, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <199604021358.XAA26252@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 11:58:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> This lets you replace recurrening events with rescheduling the > >> oneshot, and replace DELAY() with a one-shot scheduling. > > >This would certainly work. But the advantage of the timer is that it would > >be sharable; the one-shot wouldn't be. > > You haven't seen Terry's one-shot timers :-). Neither have I, but I > expect they would be shareable. E.g., if the next interrupt is > scheduled after 75 usec and something wants one after 22 usec, then the > timer would be reprogrammed to schedule the next interrupt after 22 usec > nsec and again later to schedule the original interrupt. Of course, it > might take 5-20 usec to reprogram the timer (20 usec on a 386/20) and > another 5-20 usec to switch contexts, not to mention 5-20 usec to accept > the interrupt and 5-20 usec to handle it, so one-shots are probably not > viable for such small timeouts. I think they will be viable for timeouts > a few hundred usec when the system becomes more real-time. See another > discussion about bugs that cause clock latencies of > 10000 usec. Reminds me of Bill Cosby playing the devil... "You haven't seen our bats". 8-). Bruce is right about the design. He's also right about the programming latency. He's also right about the clock latencies (which would have to be corrected by kicking the one-shot priority higher than everything but actual non-FIFO'ed I/O). Within the latency period, the timer is useful; outside it isn't. A DELAY(10) would not be replaced by a timer call, but a DELAY(200) would. > >In any event, how much would the scheduler and vm modules have to change > >-- if at all -- to allow unaffected processes to continue during swapper > >I/O? > > Not at all, I think. Large changes would probably be required to give > enough (if any) unaffected processes. Again, Bruce is right. Probably the largest change would be interrupt virtualization -- and if you've been watching the PCI and PCMCIA commits, this is real close: no major architectural changes required for most code, just some drivers. And they can be converted incrementally, it doesn't have to be wholesale. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Tue Apr 2 13:00:23 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA25756 for hardware-outgoing; Tue, 2 Apr 1996 13:00:23 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA25746 Tue, 2 Apr 1996 13:00:18 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4DYe-000wuRC; Tue, 2 Apr 96 13:24 PST Received: from cc:Mail by ccgate.infoworld.com id AA828478763; Tue, 02 Apr 96 13:53:41 PST Date: Tue, 02 Apr 96 13:53:41 PST From: "Brett Glass" Message-Id: <9603028284.AA828478763@ccgate.infoworld.com> To: Terry Lambert , bde@zeta.org.au Cc: bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > It should be a standalone command using the wdcontrol() > interface This would prevent any user with a disk like the ST5660A from being able to install FreeBSD. Inactivity timeouts need to be turned off early, before the drive can spin down. A kernel config option can do this, but a user command might be executed too late (and wouldn't be executed during an install). --Brett From owner-freebsd-hardware Tue Apr 2 13:23:52 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA27565 for hardware-outgoing; Tue, 2 Apr 1996 13:23:52 -0800 (PST) Received: from horst.bfd.com ([204.160.242.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA27540 Tue, 2 Apr 1996 13:23:45 -0800 (PST) Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.2]) by horst.bfd.com (8.7.3/8.7.3) with SMTP id NAA19539; Tue, 2 Apr 1996 13:23:55 -0800 (PST) Date: Tue, 2 Apr 1996 13:23:40 -0800 (PST) From: "Eric J. Schwertfeger" To: Terry Lambert cc: Brett Glass , terry@lambert.org, freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode In-Reply-To: <199604021823.LAA16657@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 2 Apr 1996, Terry Lambert wrote: > Well, then there he goes -- send the 0xFB out that way -- does the 0xFB > have to go out at the start, or could we, for instance, send it after > initialization? > > It seems to me the best place for disabling "green" mode would be in > a user hack to the /etc/rc.local. Exactly. hdparm (8) does this for Linux, and that is how it is usually set up. Call the command in rc.local, no kernel hacking other than the interface to allow root processes to send commands to the drive (not sure hdparm is a generic ioctl interface or not). From owner-freebsd-hardware Tue Apr 2 13:47:15 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29259 for hardware-outgoing; Tue, 2 Apr 1996 13:47:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA29248 Tue, 2 Apr 1996 13:47:11 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17274; Tue, 2 Apr 1996 14:41:09 -0700 From: Terry Lambert Message-Id: <199604022141.OAA17274@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Tue, 2 Apr 1996 14:41:09 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <9603028284.AA828478763@ccgate.infoworld.com> from "Brett Glass" at Apr 2, 96 01:53:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It should be a standalone command using the wdcontrol() > > interface > > This would prevent any user with a disk like the ST5660A from being able to > install FreeBSD. Inactivity timeouts need to be turned off early, before > the drive can spin down. A kernel config option can do this, but a user > command might be executed too late (and wouldn't be executed during an > install). It could be executed by the user early on. But it probably wouldn't be. We aren't talking about "fixing" the problem, we're talking about providing an option. It just so happens that the option is a kludge fix for some systems. Actually "fixing" the problem requires making the driver aware of drive spin downs and making it deal with it transparently instead of screwing up by passing an error to higher level code. Disabling the spindown is not what I'd call "making the code 'green aware'"... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Tue Apr 2 16:20:33 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA16893 for hardware-outgoing; Tue, 2 Apr 1996 16:20:33 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA16881 for ; Tue, 2 Apr 1996 16:20:26 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA16695; Wed, 3 Apr 1996 10:12:11 +0930 From: Michael Smith Message-Id: <199604030042.KAA16695@genesis.atrad.adelaide.edu.au> Subject: Re: Parity Errors To: dave@persprog.com (David Alderman) Date: Wed, 3 Apr 1996 10:12:10 +0930 (CST) Cc: freebsd-hardware@FreeBSD.ORG, cschuber@orca.gov.bc.ca In-Reply-To: <76BBE93DA1@novell.persprog.com> from "David Alderman" at Apr 2, 96 11:25:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Alderman stands accused of saying: > > > > FreeBSD can't generate NMI signals; it's your motherboard hardware that's > > doing that. It wouldn't surprise me if Linux just ignored them 8) > > > I've seen NMI's come out of motherboards from problems other than > main RAM. Sometimes noise or other problems can cause NMI's with > poor motherboard designs. I seem to remember stray DMA requests can > sometimes trigger an NMI. Yup, yup and it wouldn't surprise me 8) > Has anyone seen parity on the cache? Not on a PC motherboard... > It's probably not FreeBSD to blame - it is more likely FreeBSD is > revealing a latent weakness in your system. > Does anyone remember if NMI is brought out to the ISA bus? This > would open up all kinds of possibilities. No; according to Solari it isn't, but IOCHCHK is just as bad (one of the spurious-NMI boards I have generates these too - I think it must just be bored...) > Dave Alderman -- dave@persprog.com -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Tue Apr 2 16:42:17 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA19131 for hardware-outgoing; Tue, 2 Apr 1996 16:42:17 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA19125 for ; Tue, 2 Apr 1996 16:42:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.5/8.6.10) with SMTP id QAA04463 for freebsd-hardware@FreeBSD.ORG; Tue, 2 Apr 1996 16:42:10 -0800 (PST) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199604030042.QAA04463@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: freebsd-hardware@FreeBSD.ORG Subject: Parity Errors 2 Date: Tue, 02 Apr 96 16:42:09 -0800 X-Mts: smtp Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've managed dig up more information about the parity errors I've been getting. I've had the machine looked at and according to the repairman I need to increase my wait states from zero to one for memory reads and writes. His rule of thumb is that 486DX33 requires at least one wait state with 70ns simms (120MHz Pentiums require 5 while 486SX25's can get by with zero wait states). He also warned me that setting too many wait states will also cause parity errors and under Windows, general protection faults. DMA timeout, e.g. DMA transfers that reach/exceed the limit of 7.8 microseconds, and flakey sram chips were also mentioned as causes of NMI signals. Secondly, the last kernel dump I've got shows that port 0x61 has both high ordered bits being zero (actually all bits are zero). Apparently the high order bit (bit 7) indicates a parity error on the motherboard while bit 6 indicates an IOCHCHK. Either way I'll try the box out with one wait state. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-hardware Tue Apr 2 19:10:41 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA01014 for hardware-outgoing; Tue, 2 Apr 1996 19:10:41 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA00987 for ; Tue, 2 Apr 1996 19:10:32 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA18024; Wed, 3 Apr 1996 12:59:21 +0930 From: Michael Smith Message-Id: <199604030329.MAA18024@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Wed, 3 Apr 1996 12:59:21 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603028284.AA828461240@ccgate.infoworld.com> from "Brett Glass" at Apr 2, 96 08:30:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > > Timeouts should default to off, in order to deal with problems like > > yours. > > I'm not so sure. Pity the poor laptop owner whose drive spins up relatively > quickly (so that turning off the timeout isn't absolutely necessary). He > installs FreeBSD, and suddenly finds his batteries completely discharged! > The mailing lists receive dozens of complaints, and FreeBSD becomes known > as a notebook power hog. *shrug* The alternative is complaints like yours, where FreeBSD becomes known as a pedant for on-the-spec behaviour. The difference is that what I'm talking about is identifying _specific_ drives that behave in unfriendly fashions, and dealing with them to solve the _specific_ problems that they cause. > > The rogues table would also be able to indicate to ioctl code > > that wanted to reenable power-saving modes that the disk required special > > handling. > > In other words, you'd want to create a "power saving" ioctl? I'd suggest an ioctl that controlled the power mode of the drive. The spec implies that it should be possible to punt the drive into and out of various modes; the rogues table would allow for drives which required nonstandard methods for this process. > > The flagspace is too small. > > In this case, it's easy to enlarge. Just expose per-drive flags as well as > per-controller flags. That's not possible; the drives aren't visible until after they're probed, and userconfig already knows too much about the innards of the system. > > That's not so crash hot. Use a table with a list of drive ID responses > > and flags which define quirks; it's not just at attach time that oddities > > may have to be worked around. > > A table would not cover all the contingencies. Each manufacturer has its > own way of creating model numbers for products. Some put letters at the > beginning; some at the end. Some have, over time, switched the letters from > the end to the beginning or vice versa. (Maxtor, for example, moved the > letters from the end to the beginning, then added more at the end again.) > Some have hyphens in the model numbers (or have added or removed them over > time). A simple wildcard matching routine would handle this sort of thing. > Some have dozens of models that act similarly; there's no need to > bloat the table by adding every one. Some have even changed their > numbering systems during mergers and acquisitions. A cascade of routines > that both recognize ID strings and act on the relevant devices is, in my > experience, the most efficient and elegant solution. If one tries to > implement a table, one winds up having to include recognition code anyway; > the table becomes a waste of space. The excess of functions duplicating essentially the same functionality makes it very difficult to see, at a glance, what is being searched for. A table summarises everything in one place, and avoids the common case where total duplication occurs because the new patch isn't immediately recognised as doing the same thing as another that's been overlooked. I guess I'm pointing at prior art (all of the SCSI rogue detection code I've ever seen in operating systems), and saying "this works. They're probably smarter than either me or you, so let's do it the same way" 8) > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Tue Apr 2 23:16:03 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA29345 for hardware-outgoing; Tue, 2 Apr 1996 23:16:03 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA29258 for ; Tue, 2 Apr 1996 23:15:50 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA04935; Tue, 2 Apr 1996 23:13:58 -0800 From: "Rodney W. Grimes" Message-Id: <199604030713.XAA04935@GndRsh.aac.dev.com> Subject: Re: Parity Errors To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 2 Apr 1996 23:13:58 -0800 (PST) Cc: dave@persprog.com, freebsd-hardware@freebsd.org, cschuber@orca.gov.bc.ca In-Reply-To: <199604030042.KAA16695@genesis.atrad.adelaide.edu.au> from Michael Smith at "Apr 3, 96 10:12:10 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > David Alderman stands accused of saying: > > > > > > > FreeBSD can't generate NMI signals; it's your motherboard hardware that's > > > doing that. It wouldn't surprise me if Linux just ignored them 8) > > > > > I've seen NMI's come out of motherboards from problems other than > > main RAM. Sometimes noise or other problems can cause NMI's with > > poor motherboard designs. I seem to remember stray DMA requests can > > sometimes trigger an NMI. > > Yup, yup and it wouldn't surprise me 8) > > > Has anyone seen parity on the cache? > > Not on a PC motherboard... > > > It's probably not FreeBSD to blame - it is more likely FreeBSD is > > revealing a latent weakness in your system. > > Does anyone remember if NMI is brought out to the ISA bus? This > > would open up all kinds of possibilities. > > No; according to Solari it isn't, but IOCHCHK is just as bad (one of the > spurious-NMI boards I have generates these too - I think it must just be > bored...) ~IOCHCK (ISA bus signal, pin A1) is one source of NMI, if this is the source of an NMI it is noted in bit 6 of port 0x61. See src/sys/i386/isa/isa.c at or near lines 807 and 826 (grep for NMI_IOCHAN). And I just noticed a major boo boo in isa_nmi(), we should really print the the ``NMI ISA %x, EISA %x'' with a bit field interpretation, and then call panic with a string like ``NMI, likely hardware failure''. As it is currently written it will flag one of the sources, but more than one of them may be set for broken hardware (I have seen hardware that sets the PARITY bit along with the IOCHCK bit :-(). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-hardware Tue Apr 2 23:21:17 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA00335 for hardware-outgoing; Tue, 2 Apr 1996 23:21:17 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA00324 Tue, 2 Apr 1996 23:21:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id XAA28615; Tue, 2 Apr 1996 23:19:16 -0800 (PST) To: "Brett Glass" cc: Michael Smith , gibbs@freefall.freebsd.org, jkh@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Cannot boot after install In-reply-to: Your message of "Mon, 01 Apr 1996 10:12:04 PST." <9603018283.AA828379330@ccgate.infoworld.com> Date: Tue, 02 Apr 1996 23:19:16 -0800 Message-ID: <28613.828515956@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The reference to FreeBSD's configuration routines (as an example of > what other OSes should do!) will appear in the April 8 InfoWorld. It'll be Gosh, that's my birthday. Intentional? :-) You might send out a brief reminder when it's up - we have short memories around here, something that probably stems from the 500-600 emails a day we get.. :) Jordan P.S. Yeah yeah, I'll be 33. Don't remind me! :-) From owner-freebsd-hardware Wed Apr 3 07:43:54 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02990 for hardware-outgoing; Wed, 3 Apr 1996 07:43:54 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02982 Wed, 3 Apr 1996 07:43:51 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4V6m-000wujC; Wed, 3 Apr 96 08:08 PST Received: from cc:Mail by ccgate.infoworld.com id AA828546177; Tue, 02 Apr 96 15:43:16 PST Date: Tue, 02 Apr 96 15:43:16 PST From: "Brett Glass" Message-Id: <9603038285.AA828546177@ccgate.infoworld.com> To: Terry Lambert Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Actually "fixing" the problem requires making the driver aware of drive > spin downs and making it deal with it transparently instead of screwing > up by passing an error to higher level code. This is one way to solve the problem. However, disabling spindowns is also a viable solution. Why not offer both? > Disabling the spindown is not what I'd call "making the code 'green > aware'"... No, but it is both a performance enhancement and a way to ensure that things work. That's why I'd propose using config flags -- so that the system will be able to perform adequately during installation and immediately thereafter -- AND a utility that could change the setting later on. Both could be based on some of the kernel hacking I've already done here. --Brett From owner-freebsd-hardware Wed Apr 3 09:04:15 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07824 for hardware-outgoing; Wed, 3 Apr 1996 09:04:15 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA07803 Wed, 3 Apr 1996 09:04:11 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4WMU-000ww8C; Wed, 3 Apr 96 09:28 PST Received: from cc:Mail by ccgate.infoworld.com id AA828550942; Wed, 03 Apr 96 09:09:06 PST Date: Wed, 03 Apr 96 09:09:06 PST From: "Brett Glass" Message-Id: <9603038285.AA828550942@ccgate.infoworld.com> To: "Eric J. Schwertfeger" , terry@lambert.org Cc: terry@lambert.org, freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> It seems to me the best place for disabling "green" mode would be in >> a user hack to the /etc/rc.local. > Exactly. hdparm (8) does this for Linux, and that is how it is usually > set up. Call the command in rc.local, no kernel hacking other than the > interface to allow root processes to send commands to the drive (not sure > hdparm is a generic ioctl interface or not). This would not work for installation. I couldn't get FreeBSD *installed* before I added the hard disk code to the kernel. --Brett From owner-freebsd-hardware Wed Apr 3 09:04:24 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07844 for hardware-outgoing; Wed, 3 Apr 1996 09:04:24 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA07839 for ; Wed, 3 Apr 1996 09:04:22 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4WMi-000ww8C; Wed, 3 Apr 96 09:29 PST Received: from cc:Mail by ccgate.infoworld.com id AA828550952; Wed, 03 Apr 96 09:29:25 PST Date: Wed, 03 Apr 96 09:29:25 PST From: "Brett Glass" Message-Id: <9603038285.AA828550952@ccgate.infoworld.com> To: Michael Smith Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> In this case, it's easy to enlarge. Just expose per-drive flags as well >> as per-controller flags. > That's not possible; the drives aren't visible until after they're > probed, Controllers are visible before they're probed. Why not drives? We know that an IDE interface can have at most two. > A simple wildcard matching routine would handle this sort of thing. The patterns would require some complex matching. > The excess of functions duplicating essentially the same functionality > makes it very difficult to see, at a glance, what is being searched for. Different things will be searched for in different cases. It's easy to break this out into functions that search for the right thing in each case. > I guess I'm pointing at prior art (all of the SCSI rogue detection code > I've ever seen in operating systems), and saying "this works. They're > probably smarter than either me or you, so let's do it the same way" 8) I've seen the SCSI rogue detection code. The difference is that SCSI IDs are much more constrained by standards than IDE/ATA IDs. And here, we're not really talking about "rogues;" we need to know the right thing to do for EVERY drive we handle. This makes the table much bigger than if it only handles exceptional cases. --Brett From owner-freebsd-hardware Wed Apr 3 10:07:25 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11689 for hardware-outgoing; Wed, 3 Apr 1996 10:07:25 -0800 (PST) Received: from psiint.com (vv.psiint.com [204.189.53.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA11683 for ; Wed, 3 Apr 1996 10:07:22 -0800 (PST) Received: by psiint.com (8.6.12/4.03) id KAA64713; Wed, 3 Apr 1996 10:03:45 -0800 Date: Wed, 3 Apr 1996 10:03:45 -0800 (PST) From: Dave Walton To: "Andrew V. Stesin" cc: hardware@FreeBSD.ORG Subject: Re: Strange lockup problem In-Reply-To: <199603210830.KAA27764@office.elvisti.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 21 Mar 1996, Andrew V. Stesin wrote: > # Switching from one vty to another frequently causes a lockup. It can > > If you still can do telnet to your box (or come into it > via modem port), that's a situation I've seen several > times before -- lockup (or better to say synchronization > problem) of onboard kbd controller, or keyboard itself. > Sometimes re-plugging of kbd jack cures it (dangerous!) > or a command kbdcontrol -r fast < /dev/ttyv0 (issued > after coming into the box via telnet). In case you come across this problem again, I solved it by adding options ASYNCH to my kernel. Dave ========================================================================== David Walton Unix Programmer PSI INTERNATIONAL, Inc. email: dwalton@psiint.com 190 South Orchard #C200 Fax :(707)451-6484 Vacaville, CA 95688 Phone:(707)451-3503 ========================================================================== From owner-freebsd-hardware Wed Apr 3 10:09:52 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11892 for hardware-outgoing; Wed, 3 Apr 1996 10:09:52 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA11887 Wed, 3 Apr 1996 10:09:50 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA19519; Wed, 3 Apr 1996 11:02:50 -0700 From: Terry Lambert Message-Id: <199604031802.LAA19519@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Wed, 3 Apr 1996 11:02:50 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <9603038285.AA828546177@ccgate.infoworld.com> from "Brett Glass" at Apr 2, 96 03:43:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Actually "fixing" the problem requires making the driver aware of drive > > spin downs and making it deal with it transparently instead of screwing > > up by passing an error to higher level code. > > This is one way to solve the problem. However, disabling spindowns is also > a viable solution. Why not offer both? Uh... because it's impossible to offer the spindown disabling safely in a drive/controller independent fashion? The 0xFB for the Seagate is not the same as is used by all other "green" hard disks, if they even support it in the first place... > > Disabling the spindown is not what I'd call "making the code 'green > > aware'"... > > No, but it is both a performance enhancement and a way to ensure that > things work. That's the problem... it can't ensure this because you can't send the command reliably. But you can reliably recover from a spin-down, if your disk driver has been written correctly. So the generic soloution must be to recover from spindown, not to disable it. > That's why I'd propose using config flags -- so that the system will be > able to perform adequately during installation and immediately thereafter > -- AND a utility that could change the setting later on. Both could be > based on some of the kernel hacking I've already done here. This works for Seagates for people who have multiple systems so that they can build kernels. This *is* better than the situation before, but it effectively leaves a lot of wires sticking out of the case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Wed Apr 3 10:15:20 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA12288 for hardware-outgoing; Wed, 3 Apr 1996 10:15:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA12270 Wed, 3 Apr 1996 10:15:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA19546; Wed, 3 Apr 1996 11:07:26 -0700 From: Terry Lambert Message-Id: <199604031807.LAA19546@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Wed, 3 Apr 1996 11:07:26 -0700 (MST) Cc: ejs@bfd.com, terry@lambert.org, freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: <9603038285.AA828550942@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 09:09:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> It seems to me the best place for disabling "green" mode would be in > >> a user hack to the /etc/rc.local. > > > Exactly. hdparm (8) does this for Linux, and that is how it is usually > > set up. Call the command in rc.local, no kernel hacking other than the > > interface to allow root processes to send commands to the drive (not sure > > hdparm is a generic ioctl interface or not). > > This would not work for installation. I couldn't get FreeBSD *installed* > before I added the hard disk code to the kernel. And you can't add the code if it isn't installed somewhere to let you build a kernel. And you can't add the code by default because it's specific to a single hardware manufacturer, and may in fact damage or otherwise render uninstallable hardware from other manufacturers because private command values are allowed to be assigned on a per-vendor basis. 8-(. The code should go in, and be replaced later by an optional hardware specific user space command, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Wed Apr 3 11:13:58 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA16292 for hardware-outgoing; Wed, 3 Apr 1996 11:13:58 -0800 (PST) Received: from cicerone.uunet.ca (cicerone.uunet.ca [142.77.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA16287 for ; Wed, 3 Apr 1996 11:13:54 -0800 (PST) Received: from garou.uunet.ca ([142.77.1.81]) by cicerone.uunet.ca with SMTP id <170860-5>; Wed, 3 Apr 1996 14:11:39 -0500 X-Sender: user.mkerr@pop.uunet.ca X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-hardware@FreeBSD.ORG From: Mike Kerr Subject: Hardware Compatibility Message-Id: <96Apr3.141139est.170860-5@cicerone.uunet.ca> Date: Wed, 3 Apr 1996 14:11:39 -0500 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi all, I've searched through the FreeBSD web site and looked at the release notes for 2.0.5 regarding hardware compatibility, but haven't found the answer I'm looking for. I have an Intel system and want to use a Creative CDROM drive to install freeBSD. I've seen mixed results from those notes, so I thought this would be the list to post to. I need a definite answer, otherwise I'll have to consider other options for installing it, so if someone can give me a "yes, no, more or less" that my Creative CDROM will work through the install, I would REALLY appreciate it! Thanks! Mike. ============================================================================ Michael E. Kerr mkerr@mail.net Network Control Centre Specialist +1 416 368 6621 UUNET Canada, Inc. http://www.uunet.ca/ From owner-freebsd-hardware Wed Apr 3 11:26:20 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA16878 for hardware-outgoing; Wed, 3 Apr 1996 11:26:20 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA16867 Wed, 3 Apr 1996 11:26:18 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4YaA-000wuRC; Wed, 3 Apr 96 11:51 PST Received: from cc:Mail by ccgate.infoworld.com id AA828559516; Wed, 03 Apr 96 12:11:13 PST Date: Wed, 03 Apr 96 12:11:13 PST From: "Brett Glass" Message-Id: <9603038285.AA828559516@ccgate.infoworld.com> To: Terry Lambert Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Uh... because it's impossible to offer the spindown disabling safely > in a drive/controller independent fashion? Why is this impossible? If the flag is set and the drive is not positively identified as one we know how to deal with, the code can simply print a message and continue. > The 0xFB for the Seagate is not the same as is used by all other "green" > hard disks, if they even support it in the first place... True. That's why the command should be issued only in the case where the drive has been identified. > That's the problem... it can't ensure this because you can't send the > command reliably. Why not? Again, the above approach would handle the odd cases. > But you can reliably recover from a spin-down, if your disk driver > has been written correctly. Perhaps. But it may still be desirable (in fact, necessary!) to disable spindowns to get adequate performance. Therefore, FreeBSD should offer this option. > So the generic soloution must be to recover from spindown, not to > disable it. I half agree. Recovery from spindown is important for laptops and other situations where one might like to conserve power. Turning off spindown is important to allow reasonable performance on the desktop and in multi-user situations -- and is ABSOLUTELY NECESSARY until graceful recovery from spindown is possible. BOTH should be implemented. I'd be glad to do work on recognition code that makes the latter safe and adaptable to many brands of drives. --Brett From owner-freebsd-hardware Wed Apr 3 11:26:28 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA16919 for hardware-outgoing; Wed, 3 Apr 1996 11:26:28 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA16871 Wed, 3 Apr 1996 11:26:19 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4YaB-000wuTC; Wed, 3 Apr 96 11:51 PST Received: from cc:Mail by ccgate.infoworld.com id AA828559519; Wed, 03 Apr 96 12:17:46 PST Date: Wed, 03 Apr 96 12:17:46 PST From: "Brett Glass" Message-Id: <9603038285.AA828559519@ccgate.infoworld.com> To: Terry Lambert Cc: ejs@bfd.com, terry@lambert.org, freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > And you can't add the code by default because it's specific to a > single hardware manufacturer, It is now. But it's trivial to make the code issue the command only for drives the comand works on. And to make it adapt to any new drive on which we know how to disable spindowns. Also, there's extra protection because the user has to turn on the config flag intentionally. So I think we're OK here. So we can add it with confidence. --Brett From owner-freebsd-hardware Wed Apr 3 11:50:03 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17997 for hardware-outgoing; Wed, 3 Apr 1996 11:50:03 -0800 (PST) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA17962 for ; Wed, 3 Apr 1996 11:49:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-1) with SMTP id TAA08873 ; Wed, 3 Apr 1996 19:07:29 +0100 (BST) To: "Jordan K. Hubbard" cc: freebsd-hardware@FreeBSD.ORG Reply-To: freebsd-chat@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Cannot boot after install In-reply-to: Your message of "Tue, 02 Apr 1996 23:19:16 -0800." <28613.828515956@time.cdrom.com> Date: Wed, 03 Apr 1996 19:07:28 +0100 Message-ID: <8870.828554848@palmer.demon.co.uk> Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote in message ID <28613.828515956@time.cdrom.com>: > Gosh, that's my birthday. Intentional? :-) > P.S. Yeah yeah, I'll be 33. Don't remind me! :-) Jordan, You'll be 33 in a few days. Okay? Better now? :-) :-) Gary From owner-freebsd-hardware Wed Apr 3 12:23:23 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA19574 for hardware-outgoing; Wed, 3 Apr 1996 12:23:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA19568 Wed, 3 Apr 1996 12:23:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA19795; Wed, 3 Apr 1996 13:13:32 -0700 From: Terry Lambert Message-Id: <199604032013.NAA19795@phaeton.artisoft.com> Subject: It isn't easy being "green"... To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Wed, 3 Apr 1996 13:13:32 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <9603038285.AA828559516@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 12:11:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Uh... because it's impossible to offer the spindown disabling safely > > in a drive/controller independent fashion? > > Why is this impossible? If the flag is set and the drive is not positively > identified as one we know how to deal with, the code can simply print a > message and continue. That's *not* "a drive/controller independent fashion". That's a "massive rogues list and embedded p-code for each supported drive fashion". If the "disable green mode" is settable at "boot -c", you can only install drives in the "rogues list". Green drives not in the list still can't be installed. On the other hand, if the controller driver "gracefully handles spindown", you can install all green drives, period, regardless of whether or not they are "known rogues". Which is to say, "disable green mode" is a nice post-install option, but it's not the way to generically fix the install. And since the usefulness of disabling the mode is limited to people with a burning need to run down the batteries in their laptops as quickly as possible, it seems to me that it has a limited audience (or an audience of laptop owners running on other-than-battery or people with "green desktop machines" that they really didn't want to be green. I'd actually like to see this rolled into the standard APM code being written by Nate and the Nomads (good name for a band 8-)). > > But you can reliably recover from a spin-down, if your disk driver > > has been written correctly. > > Perhaps. But it may still be desirable (in fact, necessary!) to disable > spindowns to get adequate performance. Therefore, FreeBSD should offer this > option. Agree. I think it is a post-install tuning option. > > So the generic soloution must be to recover from spindown, not to > > disable it. > > I half agree. Recovery from spindown is important for laptops and other > situations where one might like to conserve power. Turning off spindown is > important to allow reasonable performance on the desktop and in multi-user > situations -- and is ABSOLUTELY NECESSARY until graceful recovery from > spindown is possible. BOTH should be implemented. I'd be glad to do work > on recognition code that makes the latter safe and adaptable to many brands > of drives. I think graceful recovery from spindown is absolutely necessary, and ability to disable features that you have to go out of your way to find in a computer (so presumably you wanted them to work instead of being disabled) ought to be a controllable option. In the name of the controllable option, the code ought to go ahead. But it ought to be a user space utility where most of the code lives... I think the primary use is for employees of companies trying to get the EPA tax incentive for energy conservation by putting unreasonably performant green machines on their employees desks. 8-). As a workaround to making the drivers robust (which is something I strongly think should *not* be worked around to incent a real fix), you might be able to convince Jordan to call the utility as part of the install. This should be sufficient to kludge around the bad driver code, which is the problem that originally bit you in the first place, without making it "standard practice". After you install (or maybe as part of the install, checking the return code of the utility), you could add the command to the rc.local. I'd hate for this to happen without making someone actively edit the script, since I don't think it should be the default. I think it's in the same category as the TCP/IP extensions (which default to on, even though they cause a lot of support problems that wouldn't be there if they didn't). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Wed Apr 3 12:47:19 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA21070 for hardware-outgoing; Wed, 3 Apr 1996 12:47:19 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21065 Wed, 3 Apr 1996 12:47:17 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4Zqc-000wupC; Wed, 3 Apr 96 13:12 PST Received: from cc:Mail by ccgate.infoworld.com id AA828564378; Wed, 03 Apr 96 13:40:51 PST Date: Wed, 03 Apr 96 13:40:51 PST From: "Brett Glass" Message-Id: <9603038285.AA828564378@ccgate.infoworld.com> To: Terry Lambert , jkh@freebsd.org Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: It isn't easy being "green"... Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > And since the usefulness of disabling the mode is limited to people > with a burning need to run down the batteries in their laptops as > quickly as possible, > or people with "green desktop machines" that they really didn't want to > be green. There are a lot in the latter category! The machine on which I am installing is *not* a laptop. It's a perfectly ordinary Zeos Pantera 486DX/100 desktop. More than a hundred thousand of this make and model alone were sold. Right after the EPA announced its "Energy Star" program, MANY vendors incorporated these drives into desktop machines. And did not provide any way of turning off the "green" features -- on purpose, so that employees of corporations that purchased the machines couldn't do it on their own. By the way, "Nate and the Nomads" is a cool name. What is the status on their APM code? > I think graceful recovery from spindown is absolutely necessary, Agree 100%. > and ability to disable features that you have to go out of your way to > find in a computer (so presumably you wanted them to work instead of > being disabled) ought to be a controllable option. Again, for about a year, you almost couldn't avoid getting these "features," especially if you bought from certain big mail-order houses. > I think the primary use is for employees of companies trying to get > the EPA tax incentive for energy conservation by putting unreasonably > performant green machines on their employees desks. 8-). Yep. > As a workaround to making the drivers robust (which is something I > strongly think should *not* be worked around to incent a real fix), > you might be able to convince Jordan to call the utility as part of > the install. This should be sufficient to kludge around the bad > driver code, which is the problem that originally bit you in the > first place, without making it "standard practice". This would require three things. First, the ioctl to issue arbitrary ATA commands would need to be added to the disk driver. (This is not hard.) Second, the "disable spindown" utility would need to be called for each IDE drive during the install (it would gracefully exit if it did not recognize the hard drive). Finally, if a drive WAS found that the code worked on (the installation could determine this via an exit code), the command would need to go into rc.local during install. Jordan, would you be willing to add this logic to the install? I'd be glad to add the ioctl, just so someone checked my work to make sure I wasn't unknowingly stepping on anything. --Brett From owner-freebsd-hardware Wed Apr 3 13:25:20 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23453 for hardware-outgoing; Wed, 3 Apr 1996 13:25:20 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA23448 for ; Wed, 3 Apr 1996 13:25:15 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA15011; Wed, 3 Apr 1996 14:23:55 -0700 Date: Wed, 3 Apr 1996 14:23:55 -0700 From: Nate Williams Message-Id: <199604032123.OAA15011@rocky.sri.MT.net> To: "Brett Glass" Cc: Terry Lambert , freebsd-hardware@freebsd.org Subject: Re: It isn't easy being "green"... In-Reply-To: <9603038285.AA828564378@ccgate.infoworld.com> References: <9603038285.AA828564378@ccgate.infoworld.com> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Reduced the CC list to -hardware ] > > By the way, "Nate and the Nomads" is a cool name. What is the status on > their APM code? APM suspend/resume works on some machines in both -stable and -current. However, folks are having a difficult time getting updated to -stable and -current because of instabilities and other problems, so it's difficult to know which machines work and which don't. I've got a pretty significant change I want to make to the statclock() code to get suspend/resume working on my box, but it affects some library routines and how the machines does scheduling and other resource accounting, so I'm not yet sure how to proceed. None of the code has dealt with the issue of spindown/spinup of the harddisk, which still tends to lockup my machine randomly due to missing interrupts when it tries to resume, but for now I'm ignoring the issue. The new 'freebsd-mobile' list has been setup (but not used as of yet) to discuss these issues, but I have been on a 2 week business trip and I haven't had any time to mess with either the code or the documentations like I had hoped. Finally, my .02 on the issue of the 'disable' spindown code is that we shouldn't spend our time on it. It woudl be better to provide the correct solution and fix the WD to handle timeouts better. The work required to do turn-off green mode will mean constant maintenance and will help but a few machines, while fixing the WD driver will work reliably on all machines. Nate From owner-freebsd-hardware Wed Apr 3 14:22:05 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA27529 for hardware-outgoing; Wed, 3 Apr 1996 14:22:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA27518 Wed, 3 Apr 1996 14:21:50 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA20146; Wed, 3 Apr 1996 15:15:40 -0700 From: Terry Lambert Message-Id: <199604032215.PAA20146@phaeton.artisoft.com> Subject: Re: It isn't easy being "green"... To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Wed, 3 Apr 1996 15:15:40 -0700 (MST) Cc: terry@lambert.org, jkh@freebsd.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <9603038285.AA828564378@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 01:40:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > And since the usefulness of disabling the mode is limited to people > > with a burning need to run down the batteries in their laptops as > > quickly as possible, > > > or people with "green desktop machines" that they really didn't want to > > be green. > > There are a lot in the latter category! 8-). It's *illegal* in the US to tamper with this if you are getting the tax break for the green-ness hardware (it's called "tax evasion"). I'd much prefer FreeBSD be a "green-OK" OS, and leave the disable as an option instead of something mandatory for an install. > The machine on which I am installing is *not* a laptop. It's a perfectly > ordinary Zeos Pantera 486DX/100 desktop. More than a hundred thousand of > this make and model alone were sold. Right after the EPA announced its > "Energy Star" program, MANY vendors incorporated these drives into desktop > machines. And did not provide any way of turning off the "green" features > -- on purpose, so that employees of corporations that purchased the > machines couldn't do it on their own. Exactly. The OS's you run on these things are supposed to be "green-OK" or they are supposed to fail to operate. FreeBSD fails to operate, which is bad. > By the way, "Nate and the Nomads" is a cool name. What is the status on > their APM code? I think Nate answered this one already (privately? I was CC'ed). [ ... ] > > and ability to disable features that you have to go out of your way to > > find in a computer (so presumably you wanted them to work instead of > > being disabled) ought to be a controllable option. > > Again, for about a year, you almost couldn't avoid getting these > "features," especially if you bought from certain big mail-order houses. Well, it was either support the "bullet item of the day" or actually make better machines... guess which was cheaper to do? 8-). I think we both agree that FreeBSD should "just work" on these boxes. > > I think the primary use is for employees of companies trying to get > > the EPA tax incentive for energy conservation by putting unreasonably > > performant green machines on their employees desks. 8-). > > Yep. Hope you aren't audited -- does the EPA read this list? 8-). > > As a workaround to making the drivers robust (which is something I > > strongly think should *not* be worked around to incent a real fix), > > you might be able to convince Jordan to call the utility as part of > > the install. This should be sufficient to kludge around the bad > > driver code, which is the problem that originally bit you in the > > first place, without making it "standard practice". > > This would require three things. First, the ioctl to issue arbitrary ATA > commands would need to be added to the disk driver. (This is not hard.) > Second, the "disable spindown" utility would need to be called > for each IDE drive during the install (it would gracefully exit if it > did not recognize the hard drive). Finally, if a drive WAS found that the > code worked on (the installation could determine this via an exit code), > the command would need to go into rc.local during install. I agree with everything but the "finally". I think, like the TTCP extensions, by default there should be an incentive to fix the broken code, and there should be support requests from the people trying to use it to harrass the coders into doing the fix ASAP. If you fix it this way, there won't be any complaints (and there should be). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Wed Apr 3 14:41:26 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA29349 for hardware-outgoing; Wed, 3 Apr 1996 14:41:26 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA29317 for ; Wed, 3 Apr 1996 14:40:20 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA05970; Wed, 3 Apr 1996 14:39:25 -0800 From: "Rodney W. Grimes" Message-Id: <199604032239.OAA05970@GndRsh.aac.dev.com> Subject: Re: ASUS ncr scsi controller question To: heric@aug.com (Eric Hinson) Date: Wed, 3 Apr 1996 14:39:25 -0800 (PST) Cc: freebsd-hardware@freebsd.org In-Reply-To: <199603300817.DAA14363@rocoto.aug.com> from Eric Hinson at "Mar 30, 96 03:17:16 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi, > > I set up a drive with FreeBSD on an Adaptec 1542cf (on another system) and > would like to put the drive in a system with the NCR PCI-SC200. I have > done this before successfully with no difficulty. > > However, when I tried it with this new system, it works fine with > an Adaptec 1542cf (even with 32 megs of ram), but gives me a > 'missing operating system' message when I try to boot the same drive > with the NCR based controller. > > I encountered this same error with the adaptec before I turned off > the > 1gig translation option in the Adaptec 1542cf BIOS. After that, it > came up without incident. > > I have moved drives from the Adaptec 1542cf based systems to the NCR PCI > based systems in the past without problems. > > Any help you can provide would be greatly appreciated. Thanks. The problem you are experincing is due to disk drive geometry translation, for disks < 1G byte the 1542 and the NCR use a 64 head/32 sector translation, for drives > 1G the 1542 uses either 64/32 or 255/63 under your control, the NCR does some really strange things above 1G and you have no control over what it picks. You did not have problems in the past because you moved drives <1G around or just plain outright got lucky, OR you installed FreeBSD using the _whole_ disk offset by 0 sectors (which I do manually so that I can move disks around at will). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-hardware Wed Apr 3 16:37:22 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA07592 for hardware-outgoing; Wed, 3 Apr 1996 16:37:22 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA07576 Wed, 3 Apr 1996 16:37:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id QAA02446; Wed, 3 Apr 1996 16:36:34 -0800 (PST) To: "Brett Glass" cc: Terry Lambert , jkh@freebsd.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: It isn't easy being "green"... In-reply-to: Your message of "Wed, 03 Apr 1996 13:40:51 PST." <9603038285.AA828564378@ccgate.infoworld.com> Date: Wed, 03 Apr 1996 16:36:34 -0800 Message-ID: <2443.828578194@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Jordan, would you be willing to add this logic to the install? I'd be glad > to add the ioctl, just so someone checked my work to make sure I wasn't > unknowingly stepping on anything. Welp, I'd like to see more concensus on this list first about the right approach - shall we bash it around for another week? :-) Jordan From owner-freebsd-hardware Wed Apr 3 17:44:12 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA12787 for hardware-outgoing; Wed, 3 Apr 1996 17:44:12 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA12782 for ; Wed, 3 Apr 1996 17:44:06 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA23103; Thu, 4 Apr 1996 11:35:39 +0930 From: Michael Smith Message-Id: <199604040205.LAA23103@genesis.atrad.adelaide.edu.au> Subject: Re: It isn't easy being "green"... To: nate@sri.MT.net (Nate Williams) Date: Thu, 4 Apr 1996 11:35:39 +0930 (CST) Cc: Brett_Glass@ccgate.infoworld.com, terry@lambert.org, freebsd-hardware@freebsd.org In-Reply-To: <199604032123.OAA15011@rocky.sri.MT.net> from "Nate Williams" at Apr 3, 96 02:23:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams stands accused of saying: > > APM suspend/resume works on some machines in both -stable and -current. > However, folks are having a difficult time getting updated to -stable > and -current because of instabilities and other problems, so it's > difficult to know which machines work and which don't. I find the comment about upgrading totally bizarre. I've bootstrapped machines to both -stable and -current over the last couple of weeks, and never had anything that couldn't directly be tracked to a bad sup. > Finally, my .02 on the issue of the 'disable' spindown code is that we > shouldn't spend our time on it. It woudl be better to provide the > correct solution and fix the WD to handle timeouts better. The work > required to do turn-off green mode will mean constant maintenance and > will help but a few machines, while fixing the WD driver will work > reliably on all machines. *mumble* I still think that a rogues list would help... (gropes for justification) - ah, of course, for IDE CDroms! (*laugh*) > Nate -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Wed Apr 3 17:49:32 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA13102 for hardware-outgoing; Wed, 3 Apr 1996 17:49:32 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA13097 for ; Wed, 3 Apr 1996 17:49:29 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA15500; Wed, 3 Apr 1996 18:49:10 -0700 Date: Wed, 3 Apr 1996 18:49:10 -0700 From: Nate Williams Message-Id: <199604040149.SAA15500@rocky.sri.MT.net> To: Michael Smith Cc: nate@sri.MT.net (Nate Williams), freebsd-hardware@freebsd.org Subject: Re: It isn't easy being "green"... In-Reply-To: <199604040205.LAA23103@genesis.atrad.adelaide.edu.au> References: <199604032123.OAA15011@rocky.sri.MT.net> <199604040205.LAA23103@genesis.atrad.adelaide.edu.au> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > APM suspend/resume works on some machines in both -stable and -current. > > However, folks are having a difficult time getting updated to -stable > > and -current because of instabilities and other problems, so it's > > difficult to know which machines work and which don't. > > I find the comment about upgrading totally bizarre. I've bootstrapped > machines to both -stable and -current over the last couple of weeks, > and never had anything that couldn't directly be tracked to a bad sup. But you have some expertise that others don't have. Also, they are experiencing instabilities of 2.1R, and 2.1R + PCCARD patches that are affecting the upgrade to -stable. I suspect some of the instabilities are due to the PC-CARD patches, but unfortunately they are unable/unwilling to give up that functionality in order to test out the APM code -stable/-current. Nate From owner-freebsd-hardware Wed Apr 3 18:00:59 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA13743 for hardware-outgoing; Wed, 3 Apr 1996 18:00:59 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA13735 for ; Wed, 3 Apr 1996 18:00:55 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id TAA15535; Wed, 3 Apr 1996 19:00:54 -0700 Date: Wed, 3 Apr 1996 19:00:54 -0700 From: Nate Williams Message-Id: <199604040200.TAA15535@rocky.sri.MT.net> To: freebsd-hardware@FreeBSD.org Subject: Fdisk questions? Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I've had this happen twice to me in the last week, and both machines were laptops so it may have something to do with that, but this problem is driving me crazy. I'm trying to partition a co-worker's machine to run FreeBSD. He has the *exact* same laptop I have, except that he completely wiped his out from scratch and re-installed Win95 on it. Now, I'm tasked to re-install FreeBSD on it. Easy, huh? The problem is that I'm unable to get fdisk under *ANY* OS to 'take'. The original installer created a 300MB DOS partition, and a second 500MB DOS partition that we're going to use for FreeBSD. So, my job is pretty easy. Boot the FreeBSD install floppy, delete the extended partition, create a new FreeBSD partition, and go from there. The problem is that this doesn't work. Once you create the new partition, you should reboot to make it 'take', and once I reboot the original setup is there. Aha, so let's fake it out and do this under DOS. Same deal. I can't even delete the partition. Basically I call fdisk, delete the extended partition, reboot and it re-appears. OS-BS also has a problem installing itself. I can re-run it right after I've installed it and it will appear to have never been installed. Any attempts to write to the partition table and/or the MBR are completely un-successful, and I have no idea. Nothing in the BIOS allows me disable/enable writing the MBR or partition table, so it's not a BIOS thing AFAIK. Also, I can see where fdisk writes to the hard-disk (the disk indicator flashes), so something is being written. I also tried 'pfdisk' to no avail, which gives the same symptoms of OS-BS and the normal DOS/Win95 fdisk programs. Does anyone have a clue on why this isn't working? Is there some magic incantation I must do to get this to work. On my PC, I simply fdisk away with no cause for concern, so I'm not sure why it's such a pain on my co-workers box. The only difference is that on my box I'm still using the original 'NEC' installed hard-disk, while my co-worker's has been wiped and started over clean. Even WAG are appreciated at this stage. Nate From owner-freebsd-hardware Wed Apr 3 19:32:48 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA18341 for hardware-outgoing; Wed, 3 Apr 1996 19:32:48 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA18336 for ; Wed, 3 Apr 1996 19:32:43 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA24350; Thu, 4 Apr 1996 13:26:28 +0930 From: Michael Smith Message-Id: <199604040356.NAA24350@genesis.atrad.adelaide.edu.au> Subject: Re: Fdisk questions? To: nate@sri.MT.net (Nate Williams) Date: Thu, 4 Apr 1996 13:26:28 +0930 (CST) Cc: freebsd-hardware@FreeBSD.org In-Reply-To: <199604040200.TAA15535@rocky.sri.MT.net> from "Nate Williams" at Apr 3, 96 07:00:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams stands accused of saying: > > Any attempts to write to the partition table and/or the MBR are > completely un-successful, and I have no idea. Nothing in the BIOS > allows me disable/enable writing the MBR or partition table, so it's not > a BIOS thing AFAIK. Also, I can see where fdisk writes to the hard-disk This includes "Virus protection" stuff in the BIOS? > (the disk indicator flashes), so something is being written. I also > tried 'pfdisk' to no avail, which gives the same symptoms of OS-BS and > the normal DOS/Win95 fdisk programs. Biiizarre. Remind me not to buy one of these 8( > On my PC, I simply fdisk away with no cause for concern, so I'm not sure > why it's such a pain on my co-workers box. The only difference is that > on my box I'm still using the original 'NEC' installed hard-disk, while > my co-worker's has been wiped and started over clean. What happens if you boot the FBSD install disk, use the slice editor there, hit 'write' and then reboot? Does it still not 'take'? > Nate -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Wed Apr 3 20:10:16 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA20799 for hardware-outgoing; Wed, 3 Apr 1996 20:10:16 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA20790 Wed, 3 Apr 1996 20:10:12 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4glb-000wwAC; Wed, 3 Apr 96 20:35 PST Received: from cc:Mail by ccgate.infoworld.com id AA828590959; Wed, 03 Apr 96 20:55:53 PST Date: Wed, 03 Apr 96 20:55:53 PST From: "Brett Glass" Message-Id: <9603038285.AA828590959@ccgate.infoworld.com> To: Terry Lambert Cc: terry@lambert.org, jkh@freebsd.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: It isn't easy being "green"... Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 8-). It's *illegal* in the US to tamper with this if you are getting > the tax break for the green-ness hardware (it's called "tax evasion"). Nope. The tax break only requires a certain percentage of machines to be "green." And "green" machines are only supposed to save energy while inactive. Clearly, if you're installing an OS on the machine or using it to run tasks constantly or frequently (as UNIX does), it's legitimate (in fact, essential) to keep the hard drive spun up. > Hope you aren't audited -- does the EPA read this list? 8-). I'm really scared. (Especially since I -- like most owners of these machines -- am not big enough to get the tax break in the first place.) From owner-freebsd-hardware Wed Apr 3 20:15:16 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA21170 for hardware-outgoing; Wed, 3 Apr 1996 20:15:16 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA21164 for ; Wed, 3 Apr 1996 20:15:12 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4gqR-000wvNC; Wed, 3 Apr 96 20:40 PST Received: from cc:Mail by ccgate.infoworld.com id AA828591260; Wed, 03 Apr 96 21:05:15 PST Date: Wed, 03 Apr 96 21:05:15 PST From: "Brett Glass" Message-Id: <9603038285.AA828591260@ccgate.infoworld.com> To: Nate Williams , freebsd-hardware@FreeBSD.ORG Subject: Fdisk questions? Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Does anyone have a clue on why this isn't working? Is there some magic > incantation I must do to get this to work. Check the BIOS for an innocuous-looking setting called "virus protection." If this fails, do a low-level format (assuming it's a SCSI disk). --Brett From owner-freebsd-hardware Wed Apr 3 21:41:22 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA27814 for hardware-outgoing; Wed, 3 Apr 1996 21:41:22 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA27674 for ; Wed, 3 Apr 1996 21:40:41 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA25320; Thu, 4 Apr 1996 15:32:38 +0930 From: Michael Smith Message-Id: <199604040602.PAA25320@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Thu, 4 Apr 1996 15:32:37 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603038285.AA828550952@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 09:29:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > >> In this case, it's easy to enlarge. Just expose per-drive flags as well > >> as per-controller flags. > > > That's not possible; the drives aren't visible until after they're > > probed, > > Controllers are visible before they're probed. Why not drives? We know that > an IDE interface can have at most two. *sigh* The whole point is that _nothing_ other than the 'wd' driver should know this; it needs (and for the most part has) no special-case code. Adding such code would be bogus in the extreme. > > A simple wildcard matching routine would handle this sort of thing. > > The patterns would require some complex matching. You want to be able to match a vendor string and a model number. If the textual content changes, you duplicate the entry in the table. It's nice and easy, and right where you can see it. > > The excess of functions duplicating essentially the same functionality > > makes it very difficult to see, at a glance, what is being searched for. > > Different things will be searched for in different cases. It's easy to > break this out into functions that search for the right thing in each case. Huh? You can "search for" the contents of the ID string. > I've seen the SCSI rogue detection code. The difference is that SCSI IDs > are much more constrained by standards than IDE/ATA IDs. And here, we're > not really talking about "rogues;" we need to know the right thing to do > for EVERY drive we handle. This makes the table much bigger than if it only > handles exceptional cases. No, egregious monsterism aside, the majority of drives still follow the spec. All you want is a list of drives that behave outside the envelope that's required for conformance with the driver. This is not 'all drives', as is demonstrated by the lack of such a table to date. > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Wed Apr 3 21:44:09 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA28341 for hardware-outgoing; Wed, 3 Apr 1996 21:44:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA28327 Wed, 3 Apr 1996 21:44:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA20986; Wed, 3 Apr 1996 22:37:52 -0700 From: Terry Lambert Message-Id: <199604040537.WAA20986@phaeton.artisoft.com> Subject: Re: It isn't easy being "green"... To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Wed, 3 Apr 1996 22:37:52 -0700 (MST) Cc: terry@lambert.org, jkh@freebsd.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <9603038285.AA828590959@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 08:55:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 8-). It's *illegal* in the US to tamper with this if you are getting > > the tax break for the green-ness hardware (it's called "tax evasion"). > > Nope. The tax break only requires a certain percentage of machines to be > "green." And "green" machines are only supposed to save energy while > inactive. Clearly, if you're installing an OS on the machine or using it > to run tasks constantly or frequently (as UNIX does), it's legitimate (in > fact, essential) to keep the hard drive spun up. Yeah, but given "what idiot would leave it on for a desktop?", you could quickly drop below the required percentage. 8-) 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Wed Apr 3 21:48:25 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA28896 for hardware-outgoing; Wed, 3 Apr 1996 21:48:25 -0800 (PST) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA28890 for ; Wed, 3 Apr 1996 21:48:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-1) with SMTP id GAA00503 ; Thu, 4 Apr 1996 06:47:37 +0100 (BST) To: Nate Williams cc: freebsd-hardware@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Fdisk questions? In-reply-to: Your message of "Wed, 03 Apr 1996 19:00:54 PDT." <199604040200.TAA15535@rocky.sri.MT.net> Date: Thu, 04 Apr 1996 06:47:37 +0100 Message-ID: <501.828596857@palmer.demon.co.uk> Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams wrote in message ID <199604040200.TAA15535@rocky.sri.MT.net>: > I've had this happen twice to me in the last week, and both machines > were laptops so it may have something to do with that, but this problem > is driving me crazy. I saw something similar whilst I was out at W.C. ``Bob'' got himself a new machine with an IDE hard drive, and ``fips'' refused to reduce the size of the DOS partition 'cos it's checksum failed when checking the MBR it read in. Seems it was somehow pulling the MBR from the WRONG place on the disk. This machine ONLY had Win95 on it. Anyone see a link? Does Win95 somehow mess up something to do with the MBR? Gary From owner-freebsd-hardware Wed Apr 3 22:45:28 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA02852 for hardware-outgoing; Wed, 3 Apr 1996 22:45:28 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA02842 Wed, 3 Apr 1996 22:45:24 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4jBu-000wvdC; Wed, 3 Apr 96 23:10 PST Received: from cc:Mail by ccgate.infoworld.com id AA828600271; Wed, 03 Apr 96 23:38:49 PST Date: Wed, 03 Apr 96 23:38:49 PST From: "Brett Glass" Message-Id: <9603038286.AA828600271@ccgate.infoworld.com> To: Terry Lambert Cc: terry@lambert.org, jkh@freebsd.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: It isn't easy being "green"... Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Yeah, but given "what idiot would leave it on for a desktop?", you > could quickly drop below the required percentage. 8-) 8-). There are lots of such "idiots." Under Windows, users are used to waiting so long for results that they barely notice the spinup time. ;-) -BG From owner-freebsd-hardware Wed Apr 3 22:45:53 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA02915 for hardware-outgoing; Wed, 3 Apr 1996 22:45:53 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA02910 for ; Wed, 3 Apr 1996 22:45:51 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4jBv-000wwAC; Wed, 3 Apr 96 23:10 PST Received: from cc:Mail by ccgate.infoworld.com id AA828600274; Wed, 03 Apr 96 23:40:32 PST Date: Wed, 03 Apr 96 23:40:32 PST From: "Brett Glass" Message-Id: <9603038286.AA828600274@ccgate.infoworld.com> To: Michael Smith Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > *sigh* The whole point is that _nothing_ other than the 'wd' driver > should know this; Why not? When a tape drive or CD-ROM is attached to a SCSI interface, there are exposed flags for both the SCSI adapter and the drive. This isn't "special case" code. > You want to be able to match a vendor string and a model number. If the > textual content changes, you duplicate the entry in the table. Thus making the table larger than intelligent recognition code. Even wildcards aren't enough to solve the problem. (Regular expressions WOULD be, but I don't think there's much justification for adding a regular expression matcher to the kernel!) >> Different things will be searched for in different cases. It's easy to >> break this out into functions that search for the right thing in each >>case. > Huh? You can "search for" the contents of the ID string. The contents of the ID string may need to be parsed further. At which point, one will need code anyway. > No, egregious monsterism aside, the majority of drives still follow the > spec. All you want is a list of drives that behave outside the envelope > that's required for conformance with the driver. This is not 'all > drives', as is demonstrated by the lack of such a table to date. The lack of such a table to date only indicates that the problem has not been addressed.... --Brett From owner-freebsd-hardware Wed Apr 3 23:42:09 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA05929 for hardware-outgoing; Wed, 3 Apr 1996 23:42:09 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA05916 Wed, 3 Apr 1996 23:42:02 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA32491; Thu, 4 Apr 1996 17:40:10 +1000 Date: Thu, 4 Apr 1996 17:40:10 +1000 From: Bruce Evans Message-Id: <199604040740.RAA32491@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, jkh@time.cdrom.com Subject: Re: It isn't easy being "green"... Cc: bde@zeta.org.au, freebsd-hackers@FreeBSD.org, freebsd-hardware@FreeBSD.org, jkh@FreeBSD.org, terry@lambert.org Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Welp, I'd like to see more concensus on this list first about the >right approach - shall we bash it around for another week? :-) I'm sure there's enough material here for discussing on a new mailing list for another year :-). I might even read the list, but I don't want 3 copies of it. Bruce From owner-freebsd-hardware Wed Apr 3 23:56:24 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA06802 for hardware-outgoing; Wed, 3 Apr 1996 23:56:24 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA06779 for ; Wed, 3 Apr 1996 23:56:15 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA00290; Thu, 4 Apr 1996 17:53:12 +1000 Date: Thu, 4 Apr 1996 17:53:12 +1000 From: Bruce Evans Message-Id: <199604040753.RAA00290@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, msmith@atrad.adelaide.edu.au Subject: Re: Some solutions to disk problems.... I think. Cc: hardware@FreeBSD.org, jkh@time.cdrom.com Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> *sigh* The whole point is that _nothing_ other than the 'wd' driver >> should know this; >Why not? When a tape drive or CD-ROM is attached to a SCSI interface, there >are exposed flags for both the SCSI adapter and the drive. This isn't >"special case" code. There are no per-drive flags for SCSI devices. There are at most per- controller flags for ISA SCSI controllers. Even those are unavailable for PCI SCSI controllers. The per-drive wd flags are side effects of hacks for ISA configuration. Bruce From owner-freebsd-hardware Thu Apr 4 00:00:16 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA07052 for hardware-outgoing; Thu, 4 Apr 1996 00:00:16 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA07013 for ; Thu, 4 Apr 1996 00:00:03 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id RAA26522; Thu, 4 Apr 1996 17:52:34 +0930 From: Michael Smith Message-Id: <199604040822.RAA26522@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Thu, 4 Apr 1996 17:52:34 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603038286.AA828600274@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 11:40:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > > *sigh* The whole point is that _nothing_ other than the 'wd' driver > > should know this; > > Why not? When a tape drive or CD-ROM is attached to a SCSI interface, there > are exposed flags for both the SCSI adapter and the drive. This isn't > "special case" code. Er, no there aren't any exposed flags for the device. SCSI devices are dynamically allocated at probe time, much too late for something like userconfig() to be of use. > Thus making the table larger than intelligent recognition code. Even > wildcards aren't enough to solve the problem. (Regular expressions WOULD > be, but I don't think there's much justification for adding a regular > expression matcher to the kernel!) Here's a suggestion. Write a function that performs simple string matching using a table of ten IDs. Write ten functions which each parse for these ID's. Compare the size of the two. Repeat the process for twenty, and so on. You may be unpleasantly surprised. Note that your functions will have to have the relevant text embedded _anyway_, so there's no way you can win 8) > The contents of the ID string may need to be parsed further. At which > point, one will need code anyway. For what? It matches, or it doesn't. If it matches, it has the noted behaviour. If it doesn't, it doesn't. KISS. > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Thu Apr 4 02:27:13 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA19292 for hardware-outgoing; Thu, 4 Apr 1996 02:27:13 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA19284 Thu, 4 Apr 1996 02:27:06 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id LAA15129; Thu, 4 Apr 1996 11:24:59 +0100 Received: from tees by snowdon with SMTP (PP); Thu, 4 Apr 1996 11:18:35 +0100 Received: (from dpr@localhost) by tees (SMI-8.6/8.6.12) id LAA03334; Thu, 4 Apr 1996 11:25:03 +0100 From: Paul Richards Message-Id: <199604041025.LAA03334@tees> Subject: Re: Fdisk questions? To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Thu, 4 Apr 1996 11:25:03 +0100 (BST) Cc: nate@sri.MT.net, freebsd-hardware@FreeBSD.ORG In-Reply-To: <501.828596857@palmer.demon.co.uk> from "Gary Palmer" at Apr 4, 96 06:47:37 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Gary Palmer who said > > Nate Williams wrote in message ID > <199604040200.TAA15535@rocky.sri.MT.net>: > > I've had this happen twice to me in the last week, and both machines > > were laptops so it may have something to do with that, but this problem > > is driving me crazy. > > I saw something similar whilst I was out at W.C. ``Bob'' got himself a > new machine with an IDE hard drive, and ``fips'' refused to reduce the > size of the DOS partition 'cos it's checksum failed when checking the > MBR it read in. Seems it was somehow pulling the MBR from the WRONG > place on the disk. This machine ONLY had Win95 on it. > > Anyone see a link? Does Win95 somehow mess up something to do with the > MBR? I've seen this as well but it was due to a deframgenter failing to move a couple of blocks. They were immutable as far as it was concerne and I never worked out why. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155 From owner-freebsd-hardware Thu Apr 4 05:31:35 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA27560 for hardware-outgoing; Thu, 4 Apr 1996 05:31:35 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA27552 for ; Thu, 4 Apr 1996 05:31:31 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id XAA14205; Thu, 4 Apr 1996 23:26:17 +1000 Date: Thu, 4 Apr 1996 23:26:17 +1000 From: Bruce Evans Message-Id: <199604041326.XAA14205@godzilla.zeta.org.au> To: freebsd-hardware@freebsd.org, ishort@pcm.co.za Subject: Re: sio2: 65 events for device with no tp Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >What is this message? >I have just compiled a kernel with support for an ARNET 8 port serial >card with 8 16450 ports in it. The device interrupted (although device interrupts are supposed to be disabled) before any of the ports were opened. Probably after they were configured. The message should go away after the ports have been opened at least ones. The driver won't know what to do with the interrupts, but it will know they aren't for it, and it will quietly ignore them. Try dummy opens (stty -f /dev/ttyd[0-9]). >After having removed the reference to IRQ 7 on the lpt line I am >getting lots of stray IRQ7 messages. Does this mean that the card is >generatingIRQ's even with nothing connected to it and the OS does not >know what to do with them? This can be caused by garbage signals on any IRQ line. Perhaps it is caused by the same things as the extra serial interrupts. Using IRQ7 for the lpt hides the problem. Bruce From owner-freebsd-hardware Thu Apr 4 06:41:17 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA00830 for hardware-outgoing; Thu, 4 Apr 1996 06:41:17 -0800 (PST) Received: from iaehv.IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA00824 for ; Thu, 4 Apr 1996 06:41:12 -0800 (PST) Received: by iaehv.IAEhv.nl (8.6.13/1.63) id QAA03857; Thu, 4 Apr 1996 16:41:09 +0200 From: wjw@IAEhv.nl (Willem Jan Withagen) Message-Id: <199604041441.QAA03857@iaehv.IAEhv.nl> Subject: Using micropolis 3243 with NCR810 To: hardware@freebsd.org Date: Thu, 4 Apr 1996 16:41:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, We're running into this strange problem where our /home gets lost once in a while. It just stops working, just like it has disconnected itself. Even a reboot of the system does no do the job of getting the disk back. No, the disk has to be power-cycled, and then the system needs to reboot. This happens every once in a while, and way to often for our purpose. Does anybody have similar problems or knows what to do about it. Our config is at the end, but major elements: FreeBSD 2.0.5 P90 Asus SP54P4 64Mb + 256Kb cache NCR 810 Micropolis 3243 Thanx, Willem Jan Withagen FreeBSD 2.0.5-RELEASE #1: Tue Apr 2 09:59:31 MET DST 1996 graaf@hades.IAEhv.nl:/usr/src/sys/compile/IAEHV CPU: 90-MHz Pentium 735\\90 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 66715648 (16288 pages) avail memory = 64204800 (15675 pages) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x280-0x29f irq 5 maddr 0xd8000 msize 16384 on isa ed0: address 00:00:c0:29:31:a5, type WD8013EPC (16 bit) bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x278-0x27f on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface Probing for devices on the pci0 bus: configuration mode 1 allows 32 devices. pci0:0: vendor=0x1039, device=0x406, class=multimedia [not supported] map(10): mem32(80000010) map(14): mem64(80000010) map(18): mem32(80000018) map(1c): mem64(80000018) map(20): mem32(80000020) map(24): mem64(80000020) pci0:1: vendor=0x1039, device=0x8, class=old [not supported] ncr0 rev 2 int a irq 10 on pci0:12 reg20: virtual=0xf60fc000 physical=0xfbfff000 size=0x100 ncr0: restart (scsi reset). ncr0 scanning for targets 0..6 (V2 pl21 95/03/21) (ncr0:0:0): "CONNER CFP1060S 1.05GB 2135" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1013MB (2074880 512 byte sectors) sd0(ncr0:0:0): with 2756 cyls, 8 heads, and an average 94 sectors/track (ncr0:1:0): "MICROP 2217-15MQ1001901 HQ30" type 0 fixed SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1685MB (3450902 512 byte sectors) sd1(ncr0:1:0): with 2372 cyls, 15 heads, and an average 96 sectors/track (ncr0:3:0): "MICROP 2217-15MQ1001901 HQ30" type 0 fixed SCSI 2 sd2(ncr0:3:0): Direct-Access sd2(ncr0:3:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1685MB (3450902 512 byte sectors) sd2(ncr0:3:0): with 2372 cyls, 15 heads, and an average 96 sectors/track (ncr0:4:0): "MICROP 3243-19MZ Q4D HT02" type 0 fixed SCSI 2 sd3(ncr0:4:0): Direct-Access sd3(ncr0:4:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 4095MB (8388315 512 byte sectors) sd3(ncr0:4:0): with 3956 cyls, 19 heads, and an average 111 sectors/track pci0:13: vendor=0x1095, device=0x640, class=storage [not supported] pci0: uses 256 bytes of memory from fbfff000 upto fbfff0ff. pci0: uses 256 bytes of I/O space from e800 upto e8ff. bpf: lo0 attached -- Internet Access Eindhoven BV., voice: +31-40-2438330, data: +31-40-2439436 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. From owner-freebsd-hardware Thu Apr 4 07:47:16 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA04977 for hardware-outgoing; Thu, 4 Apr 1996 07:47:16 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA04970 for ; Thu, 4 Apr 1996 07:47:12 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id WAA10627; Wed, 3 Apr 1996 22:12:50 -0800 (PST) Message-Id: <199604040612.WAA10627@ref.tfs.com> Subject: Re: Some solutions to disk problems.... I think. To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 3 Apr 1996 22:12:50 -0800 (PST) From: "JULIAN Elischer" Cc: Brett_Glass@ccgate.infoworld.com, msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@FreeBSD.org In-Reply-To: <199604040602.PAA25320@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 4, 96 03:32:37 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Brett Glass stands accused of saying: > > You want to be able to match a vendor string and a model number. If the > textual content changes, you duplicate the entry in the table. It's > nice and easy, and right where you can see it. the scsi rogue gallery matching functions now contain some RUDIMENTARY pattern matching.. ? matches anything * matches to teh end of the string I got tired of adding new table entries every time the manufacturers incremented the last decimal place in the model number. > From owner-freebsd-hardware Thu Apr 4 08:35:58 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA08901 for hardware-outgoing; Thu, 4 Apr 1996 08:35:58 -0800 (PST) Received: from ecstasy.ksu.ru (ecstasy.ksu.ras.ru [147.45.20.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA08749 Thu, 4 Apr 1996 08:34:37 -0800 (PST) X-Pass-Through: Kazan State University network Received: (from uucp@localhost) by ecstasy.ksu.ru (8.6.12/8.6.12) id TAA19870; Thu, 4 Apr 1996 19:33:17 +0300 >Received: by ugai.kcn.ru (UUPC/@ v6.10alpha, 22Oct94); id AA32122 Thu, 4 Apr 1996 20:35:32 +0100 To: hardware@freebsd.org Cc: hackers@freebsd.org, questions@freebsd.org Message-Id: Organization: Road Police of Tatarstan From: "Marat M. Khairullin" Date: Thu, 4 Apr 96 20:35:32 +0000 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Subject: How can i run Eicon X.25 card with FreeBSD? Lines: 0 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Received: from ugai by ecstasy.ksu.ru; Thu, 4 Apr 1996 20:33 MSD Received: by ugai.kcn.ru (UUPC/@ v6.10alpha, 22Oct94); id AA32122 Thu, 4 Apr 1996 20:35:32 +0100 Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-hardware Thu Apr 4 09:00:03 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10295 for hardware-outgoing; Thu, 4 Apr 1996 09:00:03 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA10243 for ; Thu, 4 Apr 1996 08:59:59 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA16747; Thu, 4 Apr 1996 09:58:40 -0700 Date: Thu, 4 Apr 1996 09:58:40 -0700 From: Nate Williams Message-Id: <199604041658.JAA16747@rocky.sri.MT.net> To: "Brett Glass" Cc: Nate Williams , freebsd-hardware@FreeBSD.ORG Subject: Re: Fdisk questions? In-Reply-To: <9603038285.AA828591260@ccgate.infoworld.com> References: <9603038285.AA828591260@ccgate.infoworld.com> Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Does anyone have a clue on why this isn't working? Is there some magic > > incantation I must do to get this to work. > > Check the BIOS for an innocuous-looking setting called "virus protection." > If this fails, do a low-level format (assuming it's a SCSI disk). No virus protection settings to be found, and the reason it doesn't work now is because it had a high-level format done to it and then Win95 installed. I suspect Win95 did something to the disk, although I don't know what. Nate From owner-freebsd-hardware Thu Apr 4 09:19:03 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA11760 for hardware-outgoing; Thu, 4 Apr 1996 09:19:03 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA11753 for ; Thu, 4 Apr 1996 09:19:01 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4sgk-000wyLC; Thu, 4 Apr 96 09:19 PST Received: from cc:Mail by ccgate.infoworld.com id AA828638251; Thu, 04 Apr 96 09:47:49 PST Date: Thu, 04 Apr 96 09:47:49 PST From: "Brett Glass" Message-Id: <9603048286.AA828638251@ccgate.infoworld.com> To: Bruce Evans , msmith@atrad.adelaide.edu.au Cc: hardware@FreeBSD.org, jkh@time.cdrom.com Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The per-drive wd flags are side effects of > hacks for ISA configuration. There are no exposed, per-drive wd flags. --Brett From owner-freebsd-hardware Thu Apr 4 09:19:06 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA11784 for hardware-outgoing; Thu, 4 Apr 1996 09:19:06 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA11762 for ; Thu, 4 Apr 1996 09:19:03 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4sgl-000wyKC; Thu, 4 Apr 96 09:19 PST Received: from cc:Mail by ccgate.infoworld.com id AA828638254; Thu, 04 Apr 96 09:56:08 PST Date: Thu, 04 Apr 96 09:56:08 PST From: "Brett Glass" Message-Id: <9603048286.AA828638254@ccgate.infoworld.com> To: Michael Smith Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Here's a suggestion. Write a function that performs simple string > matching using a table of ten IDs. Write ten functions which each parse > for these ID's. Compare the size of the two. Repeat the process for > twenty, and so on. I hope you are jesting! Only the most abysmal programmer would have to write ten functions to replace ten table entries. As the number of drives increases, code gains a greater and greater advantage as it is able to parse prefixes, suffixes, and partial model numbers for groups of drives. If the SCSI code really has to use a wildcard parser, it might actually be WORTH considering doing a shared regular expression parser (wildcards are a bit weak for the task). Regular expressions are, in a sense, programs. Seagate alone has several HUNDRED model numbers. In my hard disk guide, they go on for PAGES in fine print. And that's just one brand. Recognizing substrings of different lengths, and knowing when to look for suffixes as well as the corresponding CDC and Conner model numbers, will be key to identifying drives efficiently. --Brett From owner-freebsd-hardware Thu Apr 4 09:41:32 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA13756 for hardware-outgoing; Thu, 4 Apr 1996 09:41:32 -0800 (PST) Received: from Lapkin.RoSprint.ru (root@Lapkin.RoSprint.ru [193.232.88.20]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA13717 Thu, 4 Apr 1996 09:41:21 -0800 (PST) Received: from Lapkin.RoSprint.ru (sandy@localhost [127.0.0.1]) by Lapkin.RoSprint.ru (8.7.4/8.6.9) with SMTP id VAA01905; Thu, 4 Apr 1996 21:25:28 +0400 (MSD) Message-ID: <31640601.2781E494@lapkin.rosprint.ru> Date: Thu, 04 Apr 1996 17:25:21 +0000 From: Sandy Kovshov Organization: RoSprint Moscow X-Mailer: Mozilla 3.0b2 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Marat M. Khairullin" CC: hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Marat M. Khairullin wrote: No way. Because FreeBSD doesn't have CCITT anymore. -- --- Sandy E-mail: Internet: sandy@dream.demos.su sandy@www.RoSprint.ru X.400: (C:USSR,A:SOVMAIL,O:SNUSSR,UN:A.KOVSHOV) X.400: (C:USA,A:TELEMAIL,O:SPRINTINTL,UN:A.KOVSHOV) From owner-freebsd-hardware Thu Apr 4 09:56:28 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA15006 for hardware-outgoing; Thu, 4 Apr 1996 09:56:28 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA14993 for ; Thu, 4 Apr 1996 09:56:24 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id DAA24070; Fri, 5 Apr 1996 03:53:20 +1000 Date: Fri, 5 Apr 1996 03:53:20 +1000 From: Bruce Evans Message-Id: <199604041753.DAA24070@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au, msmith@atrad.adelaide.edu.au Subject: Re: Some solutions to disk problems.... I think. Cc: hardware@FreeBSD.org, jkh@time.cdrom.com Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> The per-drive wd flags are side effects of >> hacks for ISA configuration. >There are no exposed, per-drive wd flags. They're there but not exposed by userconfig. This must be why the controller flags are abused to hold the drive flags. The final flags are: drive 0: 32 bits of compile-time configurable drive flags | 16 low bits of configurable controller flags drive 1: 32 bits of compile-time configurable drive flags | (16 high bits of configurable controller flags >> 16) Bruce From owner-freebsd-hardware Thu Apr 4 10:16:46 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA16674 for hardware-outgoing; Thu, 4 Apr 1996 10:16:46 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA16636 Thu, 4 Apr 1996 10:16:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id KAA20171; Thu, 4 Apr 1996 10:13:12 -0800 (PST) To: Sandy Kovshov cc: "Marat M. Khairullin" , hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? In-reply-to: Your message of "Thu, 04 Apr 1996 17:25:21 GMT." <31640601.2781E494@lapkin.rosprint.ru> Date: Thu, 04 Apr 1996 10:13:12 -0800 Message-ID: <20169.828641592@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Uh, Sandy, there was no way anyway since we don't have any *drivers* for the EICON X.25 card! The CCITT code is the least of Marat's worries (and I just happen to be familiar with this card, having a friend who worked for EICON - it's a bear to program!). Bringing CCITT back would be fairly easy, if someone had the urge. Writing an X.25 driver for the card would be the hard part. If you're going to point fingers, at least make sure you point them in the right direction! :-) Jordan > Marat M. Khairullin wrote: > > No way. > > Because FreeBSD doesn't have CCITT anymore. > > -- > --- > Sandy > E-mail: Internet: sandy@dream.demos.su sandy@www.RoSprint.ru > X.400: (C:USSR,A:SOVMAIL,O:SNUSSR,UN:A.KOVSHOV) > X.400: (C:USA,A:TELEMAIL,O:SPRINTINTL,UN:A.KOVSHOV) > From owner-freebsd-hardware Thu Apr 4 10:35:43 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA18257 for hardware-outgoing; Thu, 4 Apr 1996 10:35:43 -0800 (PST) Received: from longstreet.larc.nasa.gov (longstreet.larc.nasa.gov [128.155.25.82]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA18214 Thu, 4 Apr 1996 10:35:29 -0800 (PST) Received: (from branson@localhost) by longstreet.larc.nasa.gov (8.6.11/8.6.11) id NAA19302; Thu, 4 Apr 1996 13:36:40 -0500 From: Branson Matheson Message-Id: <199604041836.NAA19302@longstreet.larc.nasa.gov> Subject: Re: How can i run Eicon X.25 card with FreeBSD? To: sandy@lapkin.rosprint.ru (Sandy Kovshov) Date: Thu, 4 Apr 1996 13:36:39 -0500 (EST) Cc: xmm@ugai.kcn.ru, hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org In-Reply-To: <31640601.2781E494@lapkin.rosprint.ru> from "Sandy Kovshov" at Apr 4, 96 05:25:21 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > No way. > Because FreeBSD doesn't have CCITT anymore. Darn.. and I was hoping that this could be enabled.. we are working here on X.25 for alot of our stuff... would be nice to have a direct interface. Don;t suppose there is a way to re-incorperate this? -branson -- ======================================================================== branson matheson | branson@widomaker.com Ferguson SysAdmin | http://widomaker.com/~branson From owner-freebsd-hardware Thu Apr 4 10:52:17 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA19901 for hardware-outgoing; Thu, 4 Apr 1996 10:52:17 -0800 (PST) Received: from vanguard.symtec.com (symtec.com [199.34.36.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA19896 for ; Thu, 4 Apr 1996 10:52:13 -0800 (PST) Received: from mars (mars [192.12.214.34]) by vanguard.symtec.com (8.6.12/8.6.12) with ESMTP id NAA04679 for ; Thu, 4 Apr 1996 13:46:32 -0500 Received: (from ted@localhost) by mars (8.6.8.1/8.6.6) id NAA02899 for hardware@FreeBSD.org; Thu, 4 Apr 1996 13:46:25 -0500 From: "Ted K." Message-Id: <199604041846.NAA02899@mars> Subject: PCI 100mb ether To: hardware@FreeBSD.org Date: Thu, 4 Apr 1996 13:46:24 -0500 (EST) Content-Type: text Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Sorry for the wasted bandiwdth.. But has anyone hacked Intel's ETherExpress PRO/100 100 mb pci ether card to freebsd. Does freebsd support any other 100 mb pci ethers besides DEC's?? -ted +--------------------------------------------------------------+ | Ted S. Krivoruchka Voice: 703-834-1800 | | Symmetrical Technologies Fax: 703-478-6690 | | 600 Herndon Parkway Email: ted@symtec.com | | Herndon, VA 22070 Web: http://www.symtec.com | +--------------------------------------------------------------+ From owner-freebsd-hardware Thu Apr 4 10:57:32 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA20360 for hardware-outgoing; Thu, 4 Apr 1996 10:57:32 -0800 (PST) Received: from Lapkin.RoSprint.ru (root@Lapkin.RoSprint.ru [193.232.88.20]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA20301 Thu, 4 Apr 1996 10:57:20 -0800 (PST) Received: from Lapkin.RoSprint.ru (sandy@localhost [127.0.0.1]) by Lapkin.RoSprint.ru (8.7.4/8.6.9) with SMTP id WAA02199; Thu, 4 Apr 1996 22:43:27 +0400 (MSD) Message-ID: <31641848.446B9B3D@lapkin.rosprint.ru> Date: Thu, 04 Apr 1996 18:43:20 +0000 From: Sandy Kovshov Organization: RoSprint Moscow X-Mailer: Mozilla 3.0b2 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: "Marat M. Khairullin" , hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? References: <20169.828641592@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > Uh, Sandy, there was no way anyway since we don't have any *drivers* > for the EICON X.25 card! The CCITT code is the least of Marat's > worries (and I just happen to be familiar with this card, having a > friend who worked for EICON - it's a bear to program!). Really. I think you must look at FreeBSD-current/src/share/doc/iso/wisc/eicon.nr I hope, that is true, what is written in this document and driver for EICON really exist. But it's really difficult to use it without support in kernel ;) > > Bringing CCITT back would be fairly easy, if someone had the urge. > Writing an X.25 driver for the card would be the hard part. If you're > going to point fingers, at least make sure you point them in the right > direction! :-) I hope that was right direction. :) I'll cut my fingers if it was not. :) -- --- Sandy E-mail: Internet: sandy@dream.demos.su sandy@www.RoSprint.ru X.400: (C:USSR,A:SOVMAIL,O:SNUSSR,UN:A.KOVSHOV) X.400: (C:USA,A:TELEMAIL,O:SPRINTINTL,UN:A.KOVSHOV) From owner-freebsd-hardware Thu Apr 4 11:19:13 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21648 for hardware-outgoing; Thu, 4 Apr 1996 11:19:13 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA21642 for ; Thu, 4 Apr 1996 11:19:09 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA24731; Thu, 4 Apr 1996 14:19:03 -0500 Date: Thu, 4 Apr 1996 14:19:03 -0500 From: Garrett Wollman Message-Id: <9604041919.AA24731@halloran-eldar.lcs.mit.edu> To: Branson Matheson Cc: hardware@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? In-Reply-To: <199604041836.NAA19302@longstreet.larc.nasa.gov> References: <31640601.2781E494@lapkin.rosprint.ru> <199604041836.NAA19302@longstreet.larc.nasa.gov> Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [Bogus CCs trimmed.] < said: > Darn.. and I was hoping that this could be enabled.. we are working > here on X.25 for alot of our stuff... would be nice to have a direct > interface. Don;t suppose there is a way to re-incorperate this? Sure there is. You have to make it work, compile without warnings, provide some sample applications, and then agree to maintain it. Just a Small Matter of Programming. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-hardware Thu Apr 4 11:52:09 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA24435 for hardware-outgoing; Thu, 4 Apr 1996 11:52:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA24285 Thu, 4 Apr 1996 11:51:58 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA22341; Thu, 4 Apr 1996 12:45:06 -0700 From: Terry Lambert Message-Id: <199604041945.MAA22341@phaeton.artisoft.com> Subject: Re: How can i run Eicon X.25 card with FreeBSD? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 4 Apr 1996 12:45:05 -0700 (MST) Cc: sandy@lapkin.rosprint.ru, xmm@ugai.kcn.ru, hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org In-Reply-To: <20169.828641592@time.cdrom.com> from "Jordan K. Hubbard" at Apr 4, 96 10:13:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Uh, Sandy, there was no way anyway since we don't have any *drivers* > for the EICON X.25 card! The CCITT code is the least of Marat's > worries (and I just happen to be familiar with this card, having a > friend who worked for EICON - it's a bear to program!). Hey! That's the X.25 card that we wrote the X.29 pad services for for the French Ministry of Defense! Not under BSD, and many years ago... > Bringing CCITT back would be fairly easy, if someone had the urge. > Writing an X.25 driver for the card would be the hard part. If you're > going to point fingers, at least make sure you point them in the right > direction! :-) If anyone plans to bring it back, there are a number of library and kernel interface issues that have historically kludged which I hope you would clean up while you were at it... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hardware Thu Apr 4 12:06:19 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA25498 for hardware-outgoing; Thu, 4 Apr 1996 12:06:19 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA25478 Thu, 4 Apr 1996 12:06:13 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u4vIE-0003vqC; Thu, 4 Apr 96 12:06 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id UAA00291; Thu, 4 Apr 1996 20:05:54 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Branson Matheson cc: sandy@lapkin.rosprint.ru (Sandy Kovshov), xmm@ugai.kcn.ru, hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? In-reply-to: Your message of "Thu, 04 Apr 1996 13:36:39 EST." <199604041836.NAA19302@longstreet.larc.nasa.gov> Date: Thu, 04 Apr 1996 20:05:52 +0000 Message-ID: <289.828648352@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > No way. > > Because FreeBSD doesn't have CCITT anymore. > > > Darn.. and I was hoping that this could be enabled.. we are working > here on X.25 for alot of our stuff... would be nice to have a direct > interface. Don;t suppose there is a way to re-incorperate this? If somebody promises to maintain the stuff, yes. Otherwise: no. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hardware Thu Apr 4 14:09:01 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA07549 for hardware-outgoing; Thu, 4 Apr 1996 14:09:01 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA07538 for ; Thu, 4 Apr 1996 14:08:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id OAA19770; Thu, 4 Apr 1996 14:06:43 -0800 (PST) Message-Id: <199604042206.OAA19770@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: "Ted K." cc: hardware@FreeBSD.org Subject: Re: PCI 100mb ether In-reply-to: Your message of "Thu, 04 Apr 1996 13:46:24 EST." <199604041846.NAA02899@mars> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 04 Apr 1996 14:06:43 -0800 Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >But has anyone hacked Intel's ETherExpress PRO/100 100 mb pci >ether card to freebsd. Someone is working on that. >Does freebsd support any other 100 mb pci ethers besides DEC's?? We have support for the Intel Pro/100B in 2.1-stable (not in the release code). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hardware Thu Apr 4 14:14:43 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA07881 for hardware-outgoing; Thu, 4 Apr 1996 14:14:43 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA07876 for ; Thu, 4 Apr 1996 14:14:40 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4xJ5-000wrGC; Thu, 4 Apr 96 14:15 PST Received: from cc:Mail by ccgate.infoworld.com id AA828655946; Thu, 04 Apr 96 14:49:50 PST Date: Thu, 04 Apr 96 14:49:50 PST From: "Brett Glass" Message-Id: <9603048286.AA828655946@ccgate.infoworld.com> To: Michael Smith Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Why not? When a tape drive or CD-ROM is attached to a SCSI interface, >> there are exposed flags for both the SCSI adapter and the drive. This >> isn't "special case" code. > Er, no there aren't any exposed flags for the device. SCSI devices > are dynamically allocated at probe time, much too late for something > like userconfig() to be of use. Then what are the configuration flags for devices such as cd0, etc.? Chopped liver? ;-) From owner-freebsd-hardware Thu Apr 4 14:14:55 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA07914 for hardware-outgoing; Thu, 4 Apr 1996 14:14:55 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA07904 for ; Thu, 4 Apr 1996 14:14:52 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4xJI-000wrGC; Thu, 4 Apr 96 14:15 PST Received: from cc:Mail by ccgate.infoworld.com id AA828655952; Thu, 04 Apr 96 14:52:50 PST Date: Thu, 04 Apr 96 14:52:50 PST From: "Brett Glass" Message-Id: <9603048286.AA828655952@ccgate.infoworld.com> To: Bruce Evans , bde@zeta.org.au, msmith@atrad.adelaide.edu.au Cc: hardware@FreeBSD.org, jkh@time.cdrom.com Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > They're there but not exposed by userconfig. This must be why the > controller flags are abused to hold the drive flags. The final > flags are: > drive 0: 32 bits of compile-time configurable drive flags > | 16 low bits of configurable controller flags > drive 1: 32 bits of compile-time configurable drive flags > | (16 high bits of configurable controller flags >> 16) Exactly. I found these while browsing through the code. My changes to wd.c use two controller flags to indicate the desire to turn off inactivity timeouts, and one flag in each drive's hidden drive word to indicate success (so that status can be checked and/or reported later). It'd be nice to use just the drive flags, but there has to be a way for the user to set or clear the option on a per-drive basis. --Brett From owner-freebsd-hardware Thu Apr 4 14:17:26 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA08170 for hardware-outgoing; Thu, 4 Apr 1996 14:17:26 -0800 (PST) Received: from dada.kaizen.net (dada.kaizen.net [206.27.236.38]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA08165 for ; Thu, 4 Apr 1996 14:17:21 -0800 (PST) Received: from localhost by dada.kaizen.net via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id RAA05572; Thu, 4 Apr 1996 17:16:16 -0500 Date: Thu, 4 Apr 1996 17:16:12 -0500 (EST) From: Michael Newell To: "Ted K." cc: hardware@FreeBSD.org Subject: Re: PCI 100mb ether In-Reply-To: <199604041846.NAA02899@mars> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I've got an SMC Ether that says it's a 10/100; FBSD recognizes it as a DEC board though. Mike On Thu, 4 Apr 1996, Ted K. wrote: > > > Sorry for the wasted bandiwdth.. > > > But has anyone hacked Intel's ETherExpress PRO/100 100 mb pci > ether card to freebsd. > > > Does freebsd support any other 100 mb pci ethers besides DEC's?? > > -ted > > > +--------------------------------------------------------------+ > | Ted S. Krivoruchka Voice: 703-834-1800 | > | Symmetrical Technologies Fax: 703-478-6690 | > | 600 Herndon Parkway Email: ted@symtec.com | > | Herndon, VA 22070 Web: http://www.symtec.com | > +--------------------------------------------------------------+ > From owner-freebsd-hardware Thu Apr 4 14:36:09 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA09727 for hardware-outgoing; Thu, 4 Apr 1996 14:36:09 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA09654 Thu, 4 Apr 1996 14:35:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id OAA21068; Thu, 4 Apr 1996 14:34:22 -0800 (PST) To: Branson Matheson cc: sandy@lapkin.rosprint.ru (Sandy Kovshov), xmm@ugai.kcn.ru, hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? In-reply-to: Your message of "Thu, 04 Apr 1996 13:36:39 EST." <199604041836.NAA19302@longstreet.larc.nasa.gov> Date: Thu, 04 Apr 1996 14:34:22 -0800 Message-ID: <21066.828657262@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Darn.. and I was hoping that this could be enabled.. we are working > here on X.25 for alot of our stuff... would be nice to have a direct > interface. Don;t suppose there is a way to re-incorperate this? As we said at the time - if anyone were to "adopt" this code, and not just for a day but for a couple of years at the minimum, also getting it _working_ again since it's rotted terribly over the years, then by all means it could come back. Jordan From owner-freebsd-hardware Thu Apr 4 14:37:56 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA10008 for hardware-outgoing; Thu, 4 Apr 1996 14:37:56 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA10000 for ; Thu, 4 Apr 1996 14:37:53 -0800 (PST) Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id OAA28516 for ; Thu, 4 Apr 1996 14:37:29 -0800 Received: from fluky.mitre.org (fluky.mitre.org [128.29.113.24]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id RAA25973; Thu, 4 Apr 1996 17:36:05 -0500 Received: from gita.mitre.org by fluky.mitre.org (4.1/SMI-4.0) id AA27363; Thu, 4 Apr 96 17:37:29 EST Date: Thu, 4 Apr 96 17:37:29 EST From: scott@fluky.mitre.org (Dallas Scott) Message-Id: <9604042237.AA27363@fluky.mitre.org> To: branson@longstreet.larc.nasa.gov, wollman@lcs.mit.edu Subject: Re: How can i run Eicon X.25 card with FreeBSD? Cc: hardware@FreeBSD.org Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk We have been running the netccitt code for many years now on BSDI using ADAX cards. We use it essentially exclusively for the OSI protocols. We made two wrongs a right ;-) D. Scott dscott@mitre.org ----- Begin Included Message ----- >From owner-freebsd-hardware@freefall.freebsd.org Thu Apr 4 14:49:15 1996 To: Branson Matheson Cc: hardware@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Content-Length: 833 X-Lines: 19 [Bogus CCs trimmed.] < said: > Darn.. and I was hoping that this could be enabled.. we are working > here on X.25 for alot of our stuff... would be nice to have a direct > interface. Don;t suppose there is a way to re-incorperate this? Sure there is. You have to make it work, compile without warnings, provide some sample applications, and then agree to maintain it. Just a Small Matter of Programming. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant ----- End Included Message ----- From owner-freebsd-hardware Thu Apr 4 19:07:09 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA05617 for hardware-outgoing; Thu, 4 Apr 1996 19:07:09 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA05605 for ; Thu, 4 Apr 1996 19:07:02 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA13354; Fri, 5 Apr 1996 13:03:18 +1000 Date: Fri, 5 Apr 1996 13:03:18 +1000 From: Bruce Evans Message-Id: <199604050303.NAA13354@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, msmith@atrad.adelaide.edu.au Subject: Re: Some solutions to disk problems.... I think. Cc: hardware@FreeBSD.org, jkh@time.cdrom.com Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Here's a suggestion. Write a function that performs simple string >> matching using a table of ten IDs. Write ten functions which each parse >> for these ID's. Compare the size of the two. Repeat the process for >> twenty, and so on. >I hope you are jesting! Only the most abysmal programmer would have to >write ten functions to replace ten table entries. You'll need the 10 entries at least in comments for checking. >Seagate alone has several HUNDRED model numbers. In my hard disk guide, >they go on for PAGES in fine print. And that's just one brand. Recognizing >substrings of different lengths, and knowing when to look for suffixes as >well as the corresponding CDC and Conner model numbers, will be key to >identifying drives efficiently. An interesting problem! :-) Given a telephone book sized list of model numbers, write an is_in_telephone_book(char const *s) function that is significantly smaller than the strings for the model numbers. If you don't want to simply use a (compressed) table of the entries, then you'd better start by writing test code to prove that there are no false positive or false negative matches. Bruce From owner-freebsd-hardware Thu Apr 4 21:58:48 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA20849 for hardware-outgoing; Thu, 4 Apr 1996 21:58:48 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA20787 for ; Thu, 4 Apr 1996 21:58:24 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id PAA20528; Fri, 5 Apr 1996 15:50:45 +1000 Date: Fri, 5 Apr 1996 15:50:45 +1000 From: Bruce Evans Message-Id: <199604050550.PAA20528@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, msmith@atrad.adelaide.edu.au Subject: Re: Some solutions to disk problems.... I think. Cc: hardware@freebsd.org, jkh@time.cdrom.com Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Er, no there aren't any exposed flags for the device. SCSI devices >> are dynamically allocated at probe time, much too late for something >> like userconfig() to be of use. >Then what are the configuration flags for devices such as cd0, etc.? >Chopped liver? ;-) They don't exist. Using `flags 1234' in the config file is a syntax error for non-isa devices. Bruce From owner-freebsd-hardware Thu Apr 4 22:26:46 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA23611 for hardware-outgoing; Thu, 4 Apr 1996 22:26:46 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA23601 Thu, 4 Apr 1996 22:26:27 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA21988; Fri, 5 Apr 1996 16:23:28 +1000 Date: Fri, 5 Apr 1996 16:23:28 +1000 From: Bruce Evans Message-Id: <199604050623.QAA21988@godzilla.zeta.org.au> To: hackers@FreeBSD.ORG, jagnew@vtaix.cc.vt.edu Subject: Re: EIDE controler Cc: hardware@FreeBSD.ORG Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I have the CMD640b chip as my eide controller! There is a bug in this and a few >other chips. You can read in detail about it at >http://www.yahoo.com/pci/faq.html >it explains about a bug with true multi tasking OS's. The chips that are >bad is RZ-1000, and the CMD640(x) chips, and most likely the SMC set! The above URL doesn't exist, but I read the Intel web page about the rz1000 bug. FreeBSD doesn't have the bug because FreeBSD masks IDE and floppy interrupts while transferring the IDE sector buffer. In fact, it masks all disk interrupts (those in bio_imask). This is partly from good programming practice (don't allow yourself to be interrupted) and partly from being too stupid to handle disk interrupts independently. The bug has very little to do with multi-tasking. It has to do with reentrant interrupt handlers. I guess that very few IDE interrupt handlers allow themself to be interrupted, but many systems allow floppy interrupts while IDE interrupts are being handled. These systems get bitten by a another wart in the IDE design (if they start IDE and floppy i/o's concurrently): the digital input registers for the first IDE and floppy controllers have the same address (0x3F7), and reading this address in the floppy interrupt handler sometimes clobber IDE input. Anyway, FreeBSD is too stupid to use this register. It should be used by the floppy driver to determine if the media has changed. Bruce From owner-freebsd-hardware Thu Apr 4 23:27:38 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA00548 for hardware-outgoing; Thu, 4 Apr 1996 23:27:38 -0800 (PST) Received: from aztec.co.za (aztec.co.za [196.7.70.131]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA00541 for ; Thu, 4 Apr 1996 23:27:33 -0800 (PST) Received: from pcmgate.pcm.co.za [196.3.254.241] by aztec.co.za with smtp (Smail3.1.29.1 #2) id m0u55uU-000apSC; Fri, 5 Apr 96 09:26 EET Received: (from ishort@localhost) by pcmgate.pcm.co.za (8.6.12/8.6.12) id JAA03470; Fri, 5 Apr 1996 09:19:10 +0200 Date: Fri, 5 Apr 1996 09:19:10 +0200 (SAT) From: Irvine Short To: Bruce Evans cc: freebsd-hardware@freebsd.org Subject: Re: sio2: 65 events for device with no tp In-Reply-To: <199604041326.XAA14205@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 4 Apr 1996, Bruce Evans wrote: Bruce, Thanks for the reply below. It explains my problem, but what is the tp that my device is without? Regarding the bit about IRQ7, could I now safely put a network card or whatever on it, or should I first find a lpt port that does not cause bogus interrupts? > >What is this message? > > >I have just compiled a kernel with support for an ARNET 8 port serial > >card with 8 16450 ports in it. > > The device interrupted (although device interrupts are supposed to be > disabled) before any of the ports were opened. Probably after they > were configured. The message should go away after the ports have > been opened at least ones. The driver won't know what to do with the > interrupts, but it will know they aren't for it, and it will quietly > ignore them. Try dummy opens (stty -f /dev/ttyd[0-9]). From owner-freebsd-hardware Fri Apr 5 06:09:35 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA17350 for hardware-outgoing; Fri, 5 Apr 1996 06:09:35 -0800 (PST) Received: from pancake.remcomp.fr (root@pancake.remcomp.fr [194.51.30.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA17306 Fri, 5 Apr 1996 06:09:13 -0800 (PST) Received: from panoramix.omnix.fr.org (panoramix.omnix.fr.org [128.127.10.4]) by zapata.omnix.fr.org (8.6.12/8.6.9) with SMTP id PAA16840; Fri, 5 Apr 1996 15:15:35 +0200 Message-ID: <31651C95.65BD@omnix.fr.org> Date: Fri, 05 Apr 1996 14:13:57 +0100 From: Didier Derny Organization: OMNIX X-Mailer: Mozilla 2.01 (Win95; I) MIME-Version: 1.0 To: "Marat M. Khairullin" CC: hardware@FreeBSD.org, hackers@FreeBSD.org, questions@FreeBSD.org Subject: Re: How can i run Eicon X.25 card with FreeBSD? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Marat M. Khairullin wrote: if it is acceptable for you to access directly the x25 lines you can connect an ASM box on a serial port or on a terminal server. I'm using 6x19200bds X25 lines connected to a terminal serveer (emulex) OST asm boxes are ok but you can also use NAMTEL or FIET boxes OST is the provider for the french telecom. From owner-freebsd-hardware Fri Apr 5 06:09:40 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA17375 for hardware-outgoing; Fri, 5 Apr 1996 06:09:40 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA17341 for ; Fri, 5 Apr 1996 06:09:34 -0800 (PST) Received: from uucp3.UU.NET by relay5.UU.NET with SMTP id QQakdc08979; Fri, 5 Apr 1996 09:09:38 -0500 (EST) Received: from uanet.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 5 Apr 1996 09:09:24 -0500 Received: by crocodil.monolit.kiev.ua; Fri, 5 Apr 96 17:06:38 +0300 Received: from bee.cs.kiev.ua (bee.cs.kiev.ua [193.124.54.45]) by clipper.cs.kiev.ua (8.6.4) with ESMTP id RAA01341 for ; Fri, 5 Apr 1996 17:01:10 +0300 Received: (from daemon@localhost) by bee.cs.kiev.ua (8.6.12/8.6.9) id RAA23216 for hardware@freebsd.org; Fri, 5 Apr 1996 17:01:09 +0300 Date: Fri, 5 Apr 1996 17:01:09 +0300 From: System Daemon Message-Id: <199604051401.RAA23216@bee.cs.kiev.ua> Apparently-To: hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi All! I have Alaris Mother PCI Board with NexGen P90 processor and FreeBSD 2.1 CD ( 4.4 BSD OS) BSD fails when boot up ( on stage detecting PCI Chip Set start working wery slowly) Please Help! Please replay via News Group Articles. From owner-freebsd-hardware Fri Apr 5 06:09:42 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA17384 for hardware-outgoing; Fri, 5 Apr 1996 06:09:42 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA17323 for ; Fri, 5 Apr 1996 06:09:32 -0800 (PST) Received: from uucp3.UU.NET by relay5.UU.NET with SMTP id QQakdc08963; Fri, 5 Apr 1996 09:09:36 -0500 (EST) Received: from uanet.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 5 Apr 1996 09:09:21 -0500 Received: by crocodil.monolit.kiev.ua; Fri, 5 Apr 96 17:06:26 +0300 Received: from bee.cs.kiev.ua (bee.cs.kiev.ua [193.124.54.45]) by clipper.cs.kiev.ua (8.6.4) with ESMTP id QAA01232 for ; Fri, 5 Apr 1996 16:57:26 +0300 Received: (from daemon@localhost) by bee.cs.kiev.ua (8.6.12/8.6.9) id QAA22876 for hardware@freebsd.org; Fri, 5 Apr 1996 16:57:25 +0300 Date: Fri, 5 Apr 1996 16:57:25 +0300 From: System Daemon Message-Id: <199604051357.QAA22876@bee.cs.kiev.ua> Apparently-To: hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi All! A have Intel Atlantis Mother Board(integrated ATI Mash64CT) and FreeBSD 2.1 CD ( 4.4 BSD OS) If I configue BSD to use COM ports then video system fails on boot. Please Help! Please replay via News Group Articles. From owner-freebsd-hardware Fri Apr 5 06:57:41 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA19032 for hardware-outgoing; Fri, 5 Apr 1996 06:57:41 -0800 (PST) Received: from server.id.net (root@server.id.net [199.125.1.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA19025 for ; Fri, 5 Apr 1996 06:57:39 -0800 (PST) Received: (from rls@localhost) by server.id.net (8.7.3/8.7.3) id JAA26661; Fri, 5 Apr 1996 09:59:59 -0500 (EST) From: Robert Shady Message-Id: <199604051459.JAA26661@server.id.net> Subject: Re: PCI 100mb ether To: mnewell@kaizen.net (Michael Newell) Date: Fri, 5 Apr 1996 09:59:58 -0500 (EST) Cc: ted@Symtec.com, hardware@freebsd.org In-Reply-To: from "Michael Newell" at Apr 4, 96 05:16:12 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Sorry for the wasted bandiwdth.. > > > > But has anyone hacked Intel's ETherExpress PRO/100 100 mb pci > > ether card to freebsd. > > > > > > Does freebsd support any other 100 mb pci ethers besides DEC's?? > > I've got an SMC Ether that says it's a 10/100; FBSD recognizes > it as a DEC board though. The new snap of FreeBSD does support Intel Etherexpress/100's. -- Rob === _/_/_/_/_/ _/_/_/_/ _/_/ _/ _/_/_/_/_/ _/_/_/_/_/ _/ _/ _/ _/_/_/ _/ _/ _/ _/_/_/_/ _/ _/_/_/_/_/ _/_/_/_/ _/ _/ _/_/_/_/_/ _/ Innovative Data Services Serving South-Eastern Michigan Internet Service Provider / Hardware Sales / Consulting Services Voice: (810)855-0404 / Fax: (810)855-3268 / Web: http://www.id.net From owner-freebsd-hardware Fri Apr 5 07:35:54 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA21096 for hardware-outgoing; Fri, 5 Apr 1996 07:35:54 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA21088 for ; Fri, 5 Apr 1996 07:35:50 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u5DZO-000wyhC; Fri, 5 Apr 96 07:37 PST Received: from cc:Mail by ccgate.infoworld.com id AA828718491; Fri, 05 Apr 96 07:28:00 PST Date: Fri, 05 Apr 96 07:28:00 PST From: "Brett Glass" Message-Id: <9603058287.AA828718491@ccgate.infoworld.com> To: Bruce Evans , msmith@atrad.adelaide.edu.au Cc: hardware@freebsd.org, jkh@time.cdrom.com Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>Then what are the configuration flags for devices such as cd0, etc.? > >Chopped liver? ;-) > They don't exist. Using `flags 1234' in the config file is a syntax > error for non-isa devices. Interesting. If it's an error in "syntax," are you sure that the problem is that the flags do not exist? Or is it that the number should be in hex (i.e. 0x1234)? The configuration editor does show flags as available. Whether or not any flags are used, the mechanism is there. From owner-freebsd-hardware Fri Apr 5 07:35:54 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA21095 for hardware-outgoing; Fri, 5 Apr 1996 07:35:54 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA21081 for ; Fri, 5 Apr 1996 07:35:48 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u5DZN-000wygC; Fri, 5 Apr 96 07:37 PST Received: from cc:Mail by ccgate.infoworld.com id AA828718488; Fri, 05 Apr 96 07:18:56 PST Date: Fri, 05 Apr 96 07:18:56 PST From: "Brett Glass" Message-Id: <9603058287.AA828718488@ccgate.infoworld.com> To: Bruce Evans , msmith@atrad.adelaide.edu.au Cc: hardware@FreeBSD.ORG, jkh@time.cdrom.com Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>I hope you are jesting! Only the most abysmal programmer would have to > >write ten functions to replace ten table entries. > You'll need the 10 entries at least in comments for checking. In that case, there will be more comments than there are in the rest of the driver! This is a good thing. > An interesting problem! :-) Given a telephone book sized list of model > numbers, write an is_in_telephone_book(char const *s) function that is > significantly smaller than the strings for the model numbers. That's very easy to do. The model numbers, unlike the telephone book, are logically arranged. --Brett From owner-freebsd-hardware Fri Apr 5 07:47:20 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA22020 for hardware-outgoing; Fri, 5 Apr 1996 07:47:20 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA21999 for ; Fri, 5 Apr 1996 07:47:14 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id MAA11882; Thu, 4 Apr 1996 12:22:15 -0800 (PST) Message-Id: <199604042022.MAA11882@ref.tfs.com> Subject: Re: How can i run Eicon X.25 card with FreeBSD? To: wollman@lcs.mit.edu (Garrett Wollman) Date: Thu, 4 Apr 1996 12:22:14 -0800 (PST) From: "JULIAN Elischer" Cc: branson@longstreet.larc.nasa.gov, hardware@freebsd.org In-Reply-To: <9604041919.AA24731@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Apr 4, 96 02:19:03 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > [Bogus CCs trimmed.] > > < said: > > > Darn.. and I was hoping that this could be enabled.. we are working > > here on X.25 for alot of our stuff... would be nice to have a direct > > interface. Don;t suppose there is a way to re-incorperate this? > > Sure there is. You have to make it work, compile without warnings, > provide some sample applications, and then agree to maintain it. Just > a Small Matter of Programming. As Garret and others have said.. the code is stillin the source repository, but it was getting 'stale' as no-one was keeping it up to date... if anyone volunteers to keep it running and compiling cleanly, then it will appear again in the 'distributed' version of the tree. I personally think htere should be the ISO directory in the sys tree with a single README stating this and how to get the code.. > > -GAWollman > > -- > Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... > wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. > Opinions not those of| It is a bond more powerful than absence. We like people > MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant > From owner-freebsd-hardware Fri Apr 5 08:02:36 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA22654 for hardware-outgoing; Fri, 5 Apr 1996 08:02:36 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA22649 for ; Fri, 5 Apr 1996 08:02:32 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA13163; Sat, 6 Apr 1996 01:59:15 +1000 Date: Sat, 6 Apr 1996 01:59:15 +1000 From: Bruce Evans Message-Id: <199604051559.BAA13163@godzilla.zeta.org.au> To: bde@zeta.org.au, ishort@pcm.co.za Subject: Re: sio2: 65 events for device with no tp Cc: freebsd-hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Thanks for the reply below. It explains my problem, but what is the tp >that my device is without? Tty Pointer. Tty data structures are allocated at open time, so they can't be used if an interrupt occurs before open. It is supposed to be impossible for interrupts to occur before open, but it happened before for another reason. >Regarding the bit about IRQ7, could I now safely put a network card or >whatever on it, or should I first find a lpt port that does not cause >bogus interrupts? Try to use IRQ7 for something unimportant like lpt or something that won't mind the extra interrupts (like lpt again). Bruce From owner-freebsd-hardware Fri Apr 5 09:15:19 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA26608 for hardware-outgoing; Fri, 5 Apr 1996 09:15:19 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA26601 for ; Fri, 5 Apr 1996 09:15:16 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u5F7m-000wuNC; Fri, 5 Apr 96 09:16 PST Received: from cc:Mail by ccgate.infoworld.com id AA828724452; Fri, 05 Apr 96 09:06:28 PST Date: Fri, 05 Apr 96 09:06:28 PST From: "Brett Glass" Message-Id: <9603058287.AA828724452@ccgate.infoworld.com> To: Robert Shady , mnewell@kaizen.net Cc: ted@Symtec.com, hardware@freebsd.org Subject: Re: PCI 100mb ether Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The reason the SMC is recognized as a DEC board is that DEC makes the chip. From owner-freebsd-hardware Fri Apr 5 12:20:21 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA08782 for hardware-outgoing; Fri, 5 Apr 1996 12:20:21 -0800 (PST) Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA08724 Fri, 5 Apr 1996 12:20:11 -0800 (PST) Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id FAA22216; Sat, 6 Apr 1996 05:20:02 +0900 Date: Sat, 6 Apr 1996 05:20:02 +0900 Message-Id: <199604052020.FAA22216@frig.mt.cs.keio.ac.jp> To: hackers@freebsd.org, mobile@freebsd.org, hardware@freebsd.org Reply-To: mobile@freebsd.org Subject: [PCMCIA] Do you have these PCMCIA Ethernet cards? From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Reply-to: mobile@freebsd.org I'm prepareing the next release of PC-card (PCMCIA) package for FreeBSD. I wrote many "experimental" entries in /etc/pccard.conf of Ethernet cards supported by Linux PCMCIA package. I don't know these entries are correct, but I believe that some of these entries work. These cards are, Accton EN2216 EtherCard, Allied Telesis Ethernet Card, CNet CN30BC Ethernet Card, CNet CN40BC Ethernet Card, DataTrek NetCard, Digital DEPCM-BA Ethernet, D-Link DE-650 Ethernet Card, Edimax Ethernet Combo, EP-210 Ethernet Card, Epson EEN10B Ethernet Card, Grey Cell GCS2220 Ethernet Card, GVC NIC-2000P Ethernet Card, National Semiconductor InfoMover 4100, Katron PE-520 Ethernet Card, Kingston KNE-PCM/x Ethernet, Linksys Ethernet Card, Maxtech PCN2000 Ethernet, NDC Instant-Link, NE2000 Compatible Ethernet Card, PreMax PE-200 Ethernet Card, RPTI EP400 Ethernet Card, SCM Ethernet Combo, and Socket EA LAN Adapter. If you have (or your friend has :-) ) any cards listed here, please e-mail me about it (my address is hosokawa@mt.cs.keio.ac.jp). I'll write correct /etc/pccard.conf entries if you can send me the result of FreeBSD's "pccardc dumpcis" or Linux's "dump_tuples". I need your help! -- HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html Department of Computer Science, Keio University, Yokohama, Japan From owner-freebsd-hardware Fri Apr 5 14:26:38 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA17138 for hardware-outgoing; Fri, 5 Apr 1996 14:26:38 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA17131 for ; Fri, 5 Apr 1996 14:26:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA26485; Sat, 6 Apr 1996 08:23:36 +1000 Date: Sat, 6 Apr 1996 08:23:36 +1000 From: Bruce Evans Message-Id: <199604052223.IAA26485@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au, msmith@atrad.adelaide.edu.au Subject: Re: Some solutions to disk problems.... I think. Cc: hardware@FreeBSD.org, jkh@time.cdrom.com Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> They don't exist. Using `flags 1234' in the config file is a syntax >> error for non-isa devices. >Interesting. If it's an error in "syntax," are you sure that the problem is >that the flags do not exist? Or is it that the number should be in hex >(i.e. 0x1234)? It's an error because the grammar only supports flags for isa devices (same as it only supports irq for isa devices...). >The configuration editor does show flags as available. Whether or not any >flags are used, the mechanism is there. cd0 doesn't even appear in the config editor. The config editor essentially only handles the arrays of isa devices, and cd0 isn't there. Bruce From owner-freebsd-hardware Fri Apr 5 16:31:12 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA23576 for hardware-outgoing; Fri, 5 Apr 1996 16:31:12 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA23565 for ; Fri, 5 Apr 1996 16:31:07 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u5Lvq-000wv5C; Fri, 5 Apr 96 16:32 PST Received: from cc:Mail by ccgate.infoworld.com id AA828750604; Fri, 05 Apr 96 16:19:32 PST Date: Fri, 05 Apr 96 16:19:32 PST From: "Brett Glass" Message-Id: <9603058287.AA828750604@ccgate.infoworld.com> To: Bruce Evans , bde@zeta.org.au, msmith@atrad.adelaide.edu.au Cc: hardware@FreeBSD.org, jkh@time.cdrom.com Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > cd0 doesn't even appear in the config editor. Ah... Actually, it was the Sony CD that did. From owner-freebsd-hardware Fri Apr 5 18:55:18 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA00300 for hardware-outgoing; Fri, 5 Apr 1996 18:55:18 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA00295 for ; Fri, 5 Apr 1996 18:55:14 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA02827; Sat, 6 Apr 1996 12:49:04 +0930 From: Michael Smith Message-Id: <199604060319.MAA02827@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sat, 6 Apr 1996 12:49:03 +0930 (CST) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hardware@FreeBSD.org, jkh@time.cdrom.com In-Reply-To: <9603048286.AA828638251@ccgate.infoworld.com> from "Brett Glass" at Apr 4, 96 09:47:49 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > > The per-drive wd flags are side effects of > > hacks for ISA configuration. > > There are no exposed, per-drive wd flags. The low and high words of the 'wdc' flags are implicitly exposed per-drive 'wd' flags. > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Fri Apr 5 19:02:51 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA00589 for hardware-outgoing; Fri, 5 Apr 1996 19:02:51 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA00584 for ; Fri, 5 Apr 1996 19:02:47 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA02845; Sat, 6 Apr 1996 12:56:29 +0930 From: Michael Smith Message-Id: <199604060326.MAA02845@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sat, 6 Apr 1996 12:56:28 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603048286.AA828638254@ccgate.infoworld.com> from "Brett Glass" at Apr 4, 96 09:56:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > > Here's a suggestion. Write a function that performs simple string > > matching using a table of ten IDs. Write ten functions which each parse > > for these ID's. Compare the size of the two. Repeat the process for > > twenty, and so on. > > I hope you are jesting! Only the most abysmal programmer would have to > write ten functions to replace ten table entries. If there are ten different quirks, then there are ten different functions to manage those quirks. I think what you're failing to see is that with a table-based approach, the table grows linearly with the number of drives recognised, and the function space grows with the number of quirks managed. Lookup time remains short and linear, and there is a clear, central reference to the drives and quirks recognised. With your approach, every single 'quirk management' function has to be called, and the ID string from the drive is parsed again, and again, and again. This is _inefficient_, difficult to follow, difficult to understand, and because you reinvent the parsing wheel again and again and again, you bloat even faster. > Seagate alone has several HUNDRED model numbers. In my hard disk guide, > they go on for PAGES in fine print. And that's just one brand. Recognizing > substrings of different lengths, and knowing when to look for suffixes as > well as the corresponding CDC and Conner model numbers, will be key to > identifying drives efficiently. I've never disputed this. I think you're just looking at doing it from the wrong direction. (Bear in mind that most of the drives that you're looking at there require _no_ special handling...) > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Fri Apr 5 19:14:38 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA00974 for hardware-outgoing; Fri, 5 Apr 1996 19:14:38 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA00968 for ; Fri, 5 Apr 1996 19:14:29 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA02863; Sat, 6 Apr 1996 13:08:16 +0930 From: Michael Smith Message-Id: <199604060338.NAA02863@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sat, 6 Apr 1996 13:08:16 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603048286.AA828655946@ccgate.infoworld.com> from "Brett Glass" at Apr 4, 96 02:49:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > are dynamically allocated at probe time, much too late for something > > like userconfig() to be of use. > > Then what are the configuration flags for devices such as cd0, etc.? > Chopped liver? ;-) There are no configuration flags for the SCSI devices. The collection : device st0 device sd0 device cd0 provides for an unlimited number of tape, disk and CDrom devices. Because the devices are created _at_probe_time_, there are no exposed flags. The devices don't exist beforehand, ergo they cannot possibly have flags to expose. Whilst one could, concievably, specify a 'flags' argument to a hardwired SCSI device, the value isn't consulted, so it doesn't count as exposed 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Sat Apr 6 01:32:39 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17470 for hardware-outgoing; Sat, 6 Apr 1996 01:32:39 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA17462 for ; Sat, 6 Apr 1996 01:32:35 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA03525; Sat, 6 Apr 1996 19:26:27 +0930 From: Michael Smith Message-Id: <199604060956.TAA03525@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sat, 6 Apr 1996 19:26:27 +0930 (CST) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hardware@freebsd.org, jkh@time.cdrom.com In-Reply-To: <9603058287.AA828718491@ccgate.infoworld.com> from "Brett Glass" at Apr 5, 96 07:28:00 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > >>Then what are the configuration flags for devices such as cd0, etc.? > > >Chopped liver? ;-) > > > They don't exist. Using `flags 1234' in the config file is a syntax > > error for non-isa devices. > > Interesting. If it's an error in "syntax," are you sure that the problem is > that the flags do not exist? Or is it that the number should be in hex > (i.e. 0x1234)? > > The configuration editor does show flags as available. Whether or not any > flags are used, the mechanism is there. Look again. The flags are there for the _controllers_, not for the devices. (Don't argue, I wrote half of it 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Sat Apr 6 11:25:35 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA11662 for hardware-outgoing; Sat, 6 Apr 1996 11:25:35 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA11651 for ; Sat, 6 Apr 1996 11:25:33 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u5deK-000wuuC; Sat, 6 Apr 96 11:27 PST Received: from cc:Mail by ccgate.infoworld.com id AA828818652; Sat, 06 Apr 96 09:50:04 PST Date: Sat, 06 Apr 96 09:50:04 PST From: "Brett Glass" Message-Id: <9603068288.AA828818652@ccgate.infoworld.com> To: Michael Smith Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hardware@FreeBSD.org, jkh@time.cdrom.com Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The low and high words of the 'wdc' flags are implicitly exposed > per-drive 'wd' flags. I don't think so. It appears that there are 16 bits per controller (exposed) and then 8 bits per drive (stored in a different struct and unexposed). They're shifted and OR'ed together within the driver, but they seem to go into a local variable that's not preserved. --Brett From owner-freebsd-hardware Sat Apr 6 11:36:39 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA12118 for hardware-outgoing; Sat, 6 Apr 1996 11:36:39 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA12113 for ; Sat, 6 Apr 1996 11:36:36 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA07446; Sun, 7 Apr 1996 05:31:35 +1000 Date: Sun, 7 Apr 1996 05:31:35 +1000 From: Bruce Evans Message-Id: <199604061931.FAA07446@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, msmith@atrad.adelaide.edu.au Subject: Re: Some solutions to disk problems.... I think. Cc: bde@zeta.org.au, hardware@freebsd.org, jkh@time.cdrom.com Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> The low and high words of the 'wdc' flags are implicitly exposed >> per-drive 'wd' flags. >I don't think so. It appears that there are 16 bits per controller >(exposed) and then 8 bits per drive (stored in a different struct and >unexposed). They're shifted and OR'ed together within the driver, but they >seem to go into a local variable that's not preserved. That's in the visual config. The local variable is initialized to 0 and isn't passed on to the driver and isn't preserved. The command line config works. Bruce From owner-freebsd-hardware Sat Apr 6 16:06:46 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA24624 for hardware-outgoing; Sat, 6 Apr 1996 16:06:46 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA24609 for ; Sat, 6 Apr 1996 16:06:42 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA05251; Sun, 7 Apr 1996 10:01:08 +0930 From: Michael Smith Message-Id: <199604070031.KAA05251@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sun, 7 Apr 1996 10:01:08 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603068288.AA828818656@ccgate.infoworld.com> from "Brett Glass" at Apr 6, 96 10:18:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > I've never disputed this. I think you're just looking at doing it > > from the wrong direction. > > The principles I am applying I'm simple: ... Enough! I give in to your superior wisdom as evinced by your ability to produce more vague and irrelevant verbiage on the topic. (Note that contradicting me is fine, but nay-saying bde requires serious conviction on your part 8) Now back it up with some research on the topics (ie the compilation of a rogue list), and implmentation of your Grand Plan. Owners of quirky IDE disks the world over will be your friends! 8) > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Sat Apr 6 16:33:53 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA25931 for hardware-outgoing; Sat, 6 Apr 1996 16:33:53 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA25926 for ; Sat, 6 Apr 1996 16:33:51 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u5iT5-000wthC; Sat, 6 Apr 96 16:36 PST Received: from cc:Mail by ccgate.infoworld.com id AA828837176; Sat, 06 Apr 96 16:26:30 PST Date: Sat, 06 Apr 96 16:26:30 PST From: "Brett Glass" Message-Id: <9603068288.AA828837176@ccgate.infoworld.com> To: Michael Smith Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > (Note that contradicting me is fine, but nay-saying bde requires serious > conviction on your part 8) I'm not "nay-saying" anybody. This is what's called a discussion. ;-) However, I *have* had 20 years of experience implementing real-time OSes (whose performance criteria are much stricter than those for UNIces), so I'm willing to contend that I know *something* about how to implement such things. --Brett