From owner-freebsd-bugs Mon May 20 16:20:15 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3417B37B406 for ; Mon, 20 May 2002 16:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g4KNK3802608; Mon, 20 May 2002 16:20:03 -0700 (PDT) (envelope-from gnats) Date: Mon, 20 May 2002 16:20:03 -0700 (PDT) Message-Id: <200205202320.g4KNK3802608@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Matthias Andree Subject: Re: kern/37060: kernel panic with hw.ata.tags=1 in ata-disk.c:710 Reply-To: Matthias Andree Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/37060; it has been noted by GNATS. From: Matthias Andree To: freebsd-gnats-submit@FreeBSD.org, ma@dt.e-technik.uni-dortmund.de, sos@freebsd.org, Andrew Gallatin Cc: Subject: Re: kern/37060: kernel panic with hw.ata.tags=1 in ata-disk.c:710 Date: Tue, 21 May 2002 01:17:27 +0200 I believe I know now what's going on. ata_raiddisk_attach in ata-disk.c:218 (ad_attach()) tries to read a RAID signature from the newly detected drive. In my case, that's ad1, the secondary master. At that time, ad0 (primary master) and ad1 are known, ad2 is not. 217 /* if this disk belongs to an ATA RAID dont print the probe */ 218 if (ata_raiddisk_attach(adp)) 219 adp->flags |=3D AD_F_RAID_SUBDISK; 220 else 221 ad_print(adp); 222 } now, ata_raiddisk_attach uses ar_rw, which calls upon ata_start, ata-all.c:= 661. 675 s =3D splbio(); 676 #if NATADISK > 0 677 /* find & call the responsible driver if anything on the ATA qu= eue * / 678 if (TAILQ_EMPTY(&ch->ata_queue)) { 679 if (ch->devices & (ATA_ATA_MASTER) && ch->device[MASTER].dr= iver) 680 ad_start(&ch->device[MASTER]); 681 if (ch->devices & (ATA_ATA_SLAVE) && ch->device[SLAVE].driv= er) 682 ad_start(&ch->device[SLAVE]); 683 } 684 if ((ad_request =3D TAILQ_FIRST(&ch->ata_queue))) { 685 TAILQ_REMOVE(&ch->ata_queue, ad_request, chain); 686 ch->active =3D ATA_ACTIVE_ATA; 687 ch->running =3D ad_request; 688 if (ad_transfer(ad_request) =3D=3D ATA_OP_CONTINUES) { 689 splx(s); 690 return; 691 } 692 } ata_start knows it has no driver for the slave yet (ad2, secondary slave, has not yet been probed). However, in l. 688, ad_transfer is called, which itself (ata-disk.c:495) calls ad_service: 469 if (adp->device->mode >=3D ATA_DMA && 470 !ata_dmasetup(adp->device->channel, adp->device->unit, 471 request->dmatab, request->data, request->= bytecount)) { 472 request->flags |=3D ADR_F_DMA_USED; 473 request->currentsize =3D request->bytecount; 474 =20 475 /* do we have tags enabled ? */ 476 if (adp->flags & AD_F_TAG_ENABLED) { =2E.. 491 /* if ATA bus RELEASE check for SERVICE */ 492 if (adp->flags & AD_F_TAG_ENABLED && 493 ATA_INB(adp->device->channel->r_io, ATA_IREASON= ) & 494 ATA_I_RELEASE) 495 return ad_service(adp, 1); ad_service now tries to figure the slave flags at lines 710-713 and failes because adp->device->channel->device[0] is uninitialized yet is. I'm not sure as to what the proper fix is, as I don't understand the "change" flag and its implications. However, I set a breakpoint at line #706, and on the first five hits, I issued "set change=3D0" and "c", and the drives probed fine. I then removed the breakpoint and checked what the system would do: it booted up fine. 702 int 703 ad_service(struct ad_softc *adp, int change) 704 { 705 /* do we have to check the other device on this channel ? */ 706 if (adp->device->channel->flags & ATA_QUEUED && change) { 707 int device =3D adp->device->unit; 708 =20 709 if (adp->device->unit =3D=3D ATA_MASTER) { 710 if (adp->device->channel->devices & ATA_ATA_SLAVE && 711 ((struct ad_softc *) 712 (adp->device->channel-> 713 device[ATA_DEV(ATA_SLAVE)].driver))->flags&AD_F_T= AG_EN ABLED) 714 device =3D ATA_SLAVE; =2E.. 732 adp->device->channel->status =3D 733 ATA_INB(adp->device->channel->r_altio, ATA_ALTSTAT); 734 =20 735 /* do we have a SERVICE request from the drive ? */ 736 if (adp->flags & AD_F_TAG_ENABLED && 737 adp->outstanding > 0 && =2E.. I'm not sure what the proper fix to this is, if it is to temporary disable Tagged Queueing until all drives are probed, fix ad_service to set change =3D 0 locally when the other drive is uninitialized, whatever. With the "set change =3D 0" gdb intervention, here's the ATA dmesg: atapci0: port 0xffa0-0xffaf at device 7.1 on = pci0 ata0: iobase=3D0x01f0 altiobase=3D0x03f6 bmaddr=3D0xffa0 ata0: mask=3D03 ostat0=3D50 ostat2=3D00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: mask=3D03 stat0=3D50 stat1=3D00 ata0-master: ATA 01 a5 ata0: devices=3D01 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=3D0x0170 altiobase=3D0x0376 bmaddr=3D0xffa8 ata1: mask=3D03 ostat0=3D50 ostat2=3D50 ata1-master: ATAPI 00 00 ata1-slave: ATAPI 00 00 ata1: mask=3D03 stat0=3D50 stat1=3D50 ata1-master: ATA 01 a5 ata1-slave: ATA 01 a5 ata1: devices=3D03 ata1: at 0x170 irq 15 on atapci0 =2E.. ad0: success setting UDMA4 on VIA chip Creating DISK ad0 ar: FreeBSD check1 failed ad0: ATA-6 disk at ata0-master ad0: 58610MB (120033900 sectors), 119081 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA66 ad0: piomode=3D4 dmamode=3D2 udmamode=3D5 cblid=3D1 ad1: success setting UDMA4 on VIA chip Creating DISK ad1 ar: FreeBSD check1 failed ad1: ATA-5 disk at ata1-master ad1: 43979MB (90069840 sectors), 89355 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 32 depth queue, tagged UDMA66 ad1: piomode=3D4 dmamode=3D2 udmamode=3D5 cblid=3D1 ad2: success setting UDMA4 on VIA chip Creating DISK ad2 ar: FreeBSD check1 failed ad2: ATA-4 disk at ata1-slave ad2: 19470MB (39876480 sectors), 39560 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, UDMA66 ad2: piomode=3D4 dmamode=3D2 udmamode=3D4 cblid=3D1 =2E.. [on with SCSI probes] Nothing is mounted from ad1, and I want an "OK" from S=F8ren before I try to use ad1 with the "set change=3D0" during the bootup to see if tagged queueing actually works. --=20 Matthias Andree To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message