From owner-freebsd-questions@FreeBSD.ORG Wed Mar 2 13:02:43 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A45E16A4CE for ; Wed, 2 Mar 2005 13:02:43 +0000 (GMT) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D64743D2D for ; Wed, 2 Mar 2005 13:02:42 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from tedwin2k (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) j22D2kb27033 for ; Wed, 2 Mar 2005 05:02:47 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: Date: Wed, 2 Mar 2005 05:02:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 In-Reply-To: <9810408603.20050302055304@wanadoo.fr> Importance: Normal Subject: RE: Installation instructions for Firefox somewhere? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 13:02:43 -0000 > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Anthony > Atkielski > Sent: Tuesday, March 01, 2005 8:53 PM > To: freebsd-questions@freebsd.org > Subject: Re: Installation instructions for Firefox somewhere? > > > Ted Mittelstaedt writes: > > > It appears you have a narrow-SCSI max 10MB sync disk drive and a > > ultra -3 20MB sync disk drive on the same adapter card. > > Such a combination is iffy at best. > > The configuration was the one recommended by HP. I bought the second > drive from HP directly. They both have the same type of SCSI > interface, > approved by HP. > HP didn't manufacture either of the drives nor the SCSI controller so why would you think that they know what they are talking about? HP does the same thing Compaq does (now really the same since they are the same company) they buy off-the-shelf parts from other manufacturers and bundle them together into systems that they sell. Dell, Gateway and all the rest of them do the same thing. A very few of their products (like the Vectra XU 6/200 that you have) they do design the motherboards, but that's it. And of course they design the sheetmetal. But for the motherboards in most of their stuff they get OEMs to make them for them. And despite all the testing on occasion they screw up and release patches that patch around hardware problems. > I'm tired of hearing why it's not FreeBSD's fault. When you > can tell me > exactly what theses messages mean, instead of guessing, let me know. Ok here goes: Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Retrying Command Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Request Requeued Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Retrying Command This happens when the SCSI target disk0 stop answering commands from the SCSI adapter. Feb 26 20:09:26 contactdish kernel: (da1:ahc0:0:2:0): Retrying Command Feb 26 20:09:26 contactdish kernel: (da1:ahc0:0:2:0): Queue Full Feb 26 20:09:26 contactdish kernel: (da1:ahc0:0:2:0): Retrying Command Same thing as above just with the second disk. The usual problem is bad termination that causes this, because what happens with bad termination is that electrical noise causes one or more targets on the bus to receive a command that is garbage, that target shuts down and goes out of sync with the other initiators and targets on the bus, as soon as that happens all targets shut down. But it can also be caused by a device that isn't totally compliant with the standard interfering with another device on the bus (although this is rare) And it can also be caused by the adapter card driver sending a command to a target that the target doesen't understand or does not process properly, this can happen when during the probe on boot, a target responds saying it supports something, then really doesen't. IDE devices are infamous for this, claiming to support UDMA, PIO mode 4, and such when they really don't support them properly. Sometimes if the bus is left quiet, the devices can resync and things go on. Mostly though it almost always leads to the next thing that you have, here: eb 25 20:09:29 contactdish kernel: ahc0: Recovery Initiated Feb 25 20:09:29 contactdish kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins The driver for the SCSI adapter has finally given up trying to send commands to the adapter card your disks are tied to and has decided to just reset the card entirely, which resets the bus and all devices on it, which reestablishes sync. All the rest of the data that follows is a dump of the state of the card and the commands sent, and what queue entries are trashed so the operating system can pick up where it left off if the card comes back online. Feb 25 20:09:29 contactdish kernel: (da1:ahc0:0:2:0): SCB 0x49 - timed out Feb 25 20:09:29 contactdish kernel: sg[0] - Addr 0x1309b000 : Length 2048 Feb 25 20:09:29 contactdish kernel: (da1:ahc0:0:2:0): Queuing a BDR SCB Feb 25 20:09:29 contactdish kernel: ahc0: Timedout SCBs already complete. Interrupts may not be functioning. This is a bit significant, after the bus reset, the second disk (the Quantum) isn't answering. But it looks like it later on started responding since otherwise your system would probably have paniced. None of this though is any help here. You know what the problem is you just don't know what is causing it. The idea that a SCSI command sent to a disk by the adapter card causing this is unlikely, unless either the Seagate or Quantum models that you have are known rogues (and I didn't find that they are) it is much more likely a conflict on the SCSI bus. > I'm not going to plug and unplug hardware all day based on your > speculations, particularly since I know this hardware configuration > works, and has worked for eight years. > Well first of all I already told you to run your BIOS config and set the adapter to limit sync negotiation on the Quantum to 10Mb and see if that fixed it. That would not involve you removing stuff. Secondly, you don't know how NT setup the disks and such on your system. It is quite possible that the NT driver saw the mismatch and simply reprogrammed the SCSI adapter card to limit both disks to 10Mbt transfers. Or possibly the NT driver decided not to send writes to both disks at the same time. So, comparisons like "it worked with NT so the hardware must be good" are almost useless. But the most important thing, and I think why your having so much trouble here, is that you are trying to approach this problem as though you paid $9,000 for this server, yesterday. If your Vectra was a brand new prototype in an HP test lab, or even if it was 10 days old from HP and you ran into this problem, you might have engineers with SCSI analyzers from HP's server build department all over you. But it's not - this is a server that has a production life that is OVER. I know you don't like Ebay and you probably think that everything on it is junk, but people are selling HP servers on it right now that are more powerful than yours and younger than it for under a hundred bucks - see: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=0&item=5754427891& rd=1 The fact of the matter is that ANY life you can get out of this server today is found money - it's a freebie. HP, 8 or 10 years ago when they designed this server would have told you THEN that they wern't expecting it to be in service today. Now to be honest I have a soft spot for older hardware, the gateway router system that this very message is passing though just happens to be a dual Pentium Pro with 128MB of ram and a 4GB SCSI disk on an Adaptec controller, here's it's dmesg: $ dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.11-RELEASE #0: Mon Feb 21 04:13:14 PST 2005 root@nat-rtr.freebsd-corp-net-guide.com:/usr/src/sys/compile/NATRTR Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 134217728 (131072K bytes) avail memory = 126894080 (123920K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc03a9000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 17 -> irq 16 IOAPIC #0 intpin 18 -> irq 17 IOAPIC #0 intpin 19 -> irq 18 pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 17.0 irq 2 de0: port 0x9100-0x917f mem 0xe0800000-0xe080007f irq 16 at device 18.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:40:05:43:ce:5f ed0: port 0x9200-0x921f irq 17 at device 19.0 on pci0 ed0: address 52:54:05:f2:ab:67, type NE2000 (16 bit) ahc0: port 0x9300-0x93ff mem 0xe0801000-0xe0801fff irq 18 at device 20.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs orm0: