From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:13:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4648106566B; Tue, 9 Nov 2010 17:13:25 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E77AF8FC21; Tue, 9 Nov 2010 17:13:24 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA28662; Tue, 09 Nov 2010 19:13:20 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD98130.6020705@freebsd.org> Date: Tue, 09 Nov 2010 19:13:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alexander Motin References: <4CD97F04.6010009@FreeBSD.org> In-Reply-To: <4CD97F04.6010009@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: ATA: driver bug: Unable to set devclass X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 17:13:25 -0000 on 09/11/2010 19:04 Alexander Motin said the following: > Andriy Gapon wrote: >> Since one of the recent updates (not sure which revision though) I started to get >> "Unable to set devclass" messages in boot dmesg. I'd say that I see the message >> every other boot, i.e. not always. >> >> I added some more debug code there and here's a tack trace: >> >> driver bug: Unable to set devclass (child = 0xffffff00070d0100, devname: (null)) >> #0 0xffffffff803ae127 at device_probe_child+0x127 >> #1 0xffffffff803ae40c at device_probe+0x7c >> #2 0xffffffff803ae4a1 at device_probe_and_attach+0x11 >> #3 0xffffffff803ae56a at bus_generic_attach+0x1a >> #4 0xffffffff801df93c at ata_identify+0x2ec >> #5 0xffffffff801dfcdb at ata_boot_attach+0x6b >> #6 0xffffffff803a8577 at run_interrupt_driven_config_hooks+0xf7 >> #7 0xffffffff803a8993 at boot_run_interrupt_driven_config_hooks+0x23 >> #8 0xffffffff8032f227 at mi_startup+0xc7 >> #9 0xffffffff801719cc at btext+0x2c >> >> >From kgdb: >> (kgdb) p *(device_t)0xffffff00070d0100 >> $1 = {ops = 0xffffff0001b07000, link = {tqe_next = 0xffffff0001a65100, tqe_prev = >> 0xffffff0006eb0130}, devlink = {tqe_next = 0xffffff0001a65100, tqe_prev = >> 0xffffff000706e318}, >> parent = 0xffffff0006eb0100, children = {tqh_first = 0xffffff0001a5b200, >> tqh_last = 0xffffff0001a5b208}, driver = 0xffffffff8079bc80, devclass = >> 0xffffff0001add080, unit = 0, >> nameunit = 0xffffff00070931a0 "ad0", desc = 0xffffff000711e7c0 >> "ST3320620A/3.AAF", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89, order >> = 0, ivars = 0xffffff000711e5e0, >> softc = 0xffffff000706a400, sysctl_ctx = {tqh_first = 0xffffff000711e600, >> tqh_last = 0xffffff000711e708}, sysctl_tree = 0xffffff00070f9500} >> >> Apparently sometimes something happens too soon? :-) > > What controller is there? Any other differences/interesting things in > verbose dmesg? Any new "CONNECT requested" messages or anything else? It's SB700 integrated controller (ATI IXP700/800 UDMA133 controller). This happens during boot, there are no other unusual ata-related messages. I have device ahci in kernel, but no ATA_CAM option, so PATA stuff works via "pure" ata code. -- Andriy Gapon