From owner-freebsd-current Wed Jul 1 14:17:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24071 for freebsd-current-outgoing; Wed, 1 Jul 1998 14:17:02 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dragonfly.rain.com (methane.dragonfly.rain.com [206.163.85.177]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24066 for ; Wed, 1 Jul 1998 14:16:56 -0700 (PDT) (envelope-from mason@methane.dragonfly.rain.com) Received: (from mason@localhost) by dragonfly.rain.com (8.8.7/8.8.7) id OAA27090; Wed, 1 Jul 1998 14:16:41 -0700 (PDT) From: mason@methane.dragonfly.rain.com Message-Id: <199807012116.OAA27090@dragonfly.rain.com> Subject: LBA support problems To: freebsd-current@FreeBSD.ORG Date: Wed, 1 Jul 1998 14:16:41 -0700 (PDT) Cc: mason@methane.dragonfly.rain.com () X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello all, I've posted this to -current because while we're running FreeBSD 2.2.6-RELEASE (mostly) this really deals with the LBA support (which isn't a feature in a pure 2.2.6-RELEASE system). I'm seeing some strange behaviour on our system with the LBA support that's been added to wd.c We've got an ASUS P2L97-S/233 system with IDE drives as follows: primary master WDC AC35100L 4.9 Gig, normal mode primary slave Maxtor 91152D8 11G, LBA mode secondary master Maxtor 91152D8 11G, (normal mode, 8G avail) secondary slave empty We're running FreeBSD 2.2.6-RELEASE + the LBA patches that where posted some time back (I got them through deja news). wd.c and wdreg.h are the *only* two files we've changed in the kernel. We want to run both 11G disks in LBA mode so we can use ccd or vinum and make them look like a single 22G disk (that we NFS export to our other machines). The problem has been with accessing the disk on the seconday controller in LBA mode. If I enable LBA mode on the secondary controller, the disk is properly identified: Jun 10 15:58:57 sinkhole /kernel: wdc0 at 0x1f0-0x1f7 irq 14 on isa Jun 10 15:58:57 sinkhole /kernel: wdc0: unit 0 (wd0): Jun 10 15:58:57 sinkhole /kernel: wd0: 4924MB (10085040 sectors), 10672 cyls, 15 heads, 63 S/T, 512 B/S Jun 10 15:58:57 sinkhole /kernel: wdc0: unit 1 (wd1): , LBA, 32-bit, multi-block-16 Jun 10 15:58:57 sinkhole /kernel: wd1: 10991MB (22510656 sectors), 1401 cyls, 255 heads, 63 S/T, 512 B/S Jun 10 15:58:57 sinkhole /kernel: wdc1 at 0x170-0x177 irq 15 on isa Jun 10 15:58:57 sinkhole /kernel: wdc1: unit 0 (wd2): , LBA, 32-bit, multi-block-16 Jun 10 15:58:57 sinkhole /kernel: wd2: 10991MB (22510656 sectors), 1401 cyls, 255 heads, 63 S/T, 512 B/S However when we try to access the secondary disk (trying to write a disklabel, or any other operation) the system freezes for several seconds and then we get a bunch of errors like the following: Jun 10 16:00:04 sinkhole /kernel: wd2: wdcontrol: recal failed reading fsbn 0wd2: status 0 error 0 Jun 10 16:00:04 sinkhole /kernel: wd2: wdsetctlr failed: Jun 10 16:00:04 sinkhole /kernel: wd2: status 0 error 0 Jun 10 16:00:04 sinkhole /kernel: wd2: wdcontrol: recal failed reading fsbn 0wd2: status 0 error 0 Jun 10 16:00:04 sinkhole /kernel: wd2: wdsetctlr failed: Jun 10 16:00:04 sinkhole /kernel: wd2: status 0 error 0 I've tried swaping the two 11G disks, no change (the disk hooked up to the secondary controller still fails) so it doesn't seem to be the disk itself. We've also tried moving the disk on the seconday contoller to the slave position (no luck - hey it was the only thing I could think of). The disk on the secondary controller works fine if we disable LBA mode. We've also seen the same problems if we disable 32-bit access on the secondary controller: Jun 10 16:35:46 sinkhole /kernel: wdc0 at 0x1f0-0x1f7 irq 14 on isa Jun 10 16:35:46 sinkhole /kernel: wdc0: unit 0 (wd0): Jun 10 16:35:46 sinkhole /kernel: wd0: 4924MB (10085040 sectors), 10672 cyls, 15 heads, 63 S/T, 512 B/S Jun 10 16:35:46 sinkhole /kernel: wdc0: unit 1 (wd1): , LBA, 32-bit, multi-block-16 Jun 10 16:35:46 sinkhole /kernel: wd1: 10991MB (22510656 sectors), 1401 cyls, 255 heads, 63 S/T, 512 B/S Jun 10 16:35:46 sinkhole /kernel: wdc1 at 0x170-0x177 irq 15 on isa Jun 10 16:35:46 sinkhole /kernel: wdc1: unit 0 (wd2): , LBA, multi-block-16 Jun 10 16:35:46 sinkhole /kernel: wd2: 10991MB (22510656 sectors), 1401 cyls, 255 heads, 63 S/T, 512 B/S And if we also disable multi-block access: Jun 10 17:01:56 sinkhole /kernel: wdc0 at 0x1f0-0x1f7 irq 14 on isa Jun 10 17:01:56 sinkhole /kernel: wdc0: unit 0 (wd0): Jun 10 17:01:56 sinkhole /kernel: wd0: 4924MB (10085040 sectors), 10672 cyls, 15 heads, 63 S/T, 512 B/S Jun 10 17:01:56 sinkhole /kernel: wdc0: unit 1 (wd1): , LBA, 32-bit, multi-block-16 Jun 10 17:01:56 sinkhole /kernel: wd1: 10991MB (22510656 sectors), 1401 cyls, 255 heads, 63 S/T, 512 B/S Jun 10 17:01:56 sinkhole /kernel: wdc1 at 0x170-0x177 irq 15 on isa Jun 10 17:01:56 sinkhole /kernel: wdc1: unit 0 (wd2): , LBA Jun 10 17:01:56 sinkhole /kernel: wd2: 10991MB (22510656 sectors), 1401 cyls, 255 heads, 63 S/T, 512 B/S Other interesting configuration info: Jun 10 17:01:56 sinkhole /kernel: CPU: Pentium Pro (233.86-MHz 686-class CPU) Jun 10 17:01:56 sinkhole /kernel: Origin = "GenuineIntel" Id = 0x634 Stepping=4 Jun 10 17:01:56 sinkhole /kernel: Features=0x80f9ff Jun 10 17:01:56 sinkhole /kernel: real memory = 134217728 (131072K bytes) Jun 10 17:01:56 sinkhole /kernel: avail memory = 128958464 (125936K bytes) Jun 10 17:01:56 sinkhole /kernel: Probing for devices on PCI bus 0: Jun 10 17:01:56 sinkhole /kernel: chip0 rev 3 on pci0:0:0 Jun 10 17:01:56 sinkhole /kernel: chip1 rev 3 on pci0:1:0 Jun 10 17:01:56 sinkhole /kernel: chip2 rev 1 on pci0:4:0 Jun 10 17:01:56 sinkhole /kernel: chip3 rev 1 on pci0:4:1 Jun 10 17:01:56 sinkhole /kernel: chip4 rev 1 int d irq 9 on pci0:4:2 Jun 10 17:01:56 sinkhole /kernel: chip5 rev 1 on pci0:4:3 Any ideas anyone? Thanks in advance, Mark _______________________________________________________________________________ Mark Mason Dragonfly Software Consulting Company. mason@dragonfly.rain.com 503-641-3440 (office) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message