From owner-freebsd-hardware@FreeBSD.ORG Mon Jan 14 11:06:47 2013 Return-Path: Delivered-To: freebsd-hardware@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4A8C24B0 for ; Mon, 14 Jan 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 23D8663C for ; Mon, 14 Jan 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0EB6ljl086389 for ; Mon, 14 Jan 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0EB6k86086387 for freebsd-hardware@FreeBSD.org; Mon, 14 Jan 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Jan 2013 11:06:46 GMT Message-Id: <201301141106.r0EB6k86086387@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-hardware@FreeBSD.org Subject: Current problem reports assigned to freebsd-hardware@FreeBSD.org X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/156241 hardware [mfi] 'zfs send' does not prevents disks to suspend if 1 problem total. From owner-freebsd-hardware@FreeBSD.ORG Mon Jan 14 20:50:29 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D168558D for ; Mon, 14 Jan 2013 20:50:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A8F56995 for ; Mon, 14 Jan 2013 20:50:29 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D743FB963; Mon, 14 Jan 2013 15:50:28 -0500 (EST) From: John Baldwin To: freebsd-hardware@freebsd.org Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Date: Mon, 14 Jan 2013 15:02:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130110074052.GA8922@bali> In-Reply-To: <20130110074052.GA8922@bali> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141502.58550.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 15:50:28 -0500 (EST) X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:50:29 -0000 On Thursday, January 10, 2013 2:40:52 am Andre Albsmeier wrote: > [Retrying here, maybe anyone can help...} > > I want my printer port back on 9.1 ;-( > > I have this card: > > puc0@pci0:4:1:0: class=0x078000 card=0x00121000 chip=0x98359710 rev=0x01 hdr=0x00 > vendor = 'NetMos Technology' > device = 'PCI 9835 Multi-I/O Controller' > class = simple comms > > It attached and worked under 7.4-STABLE (as long as I disabled > the interrupt using hint.ppc.0.irq=""): > > puc0: port 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > puc0: [FILTER] > uart0: on puc0 > uart0: [FILTER] > uart1: on puc0 > uart1: [FILTER] > ppc0: on puc0 > ppc0: Generic chipset (ECP/EPP/PS2/NIBBLE) in ECP+EPP mode (EPP 1.9) > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Polled port > > > Under 9.1 the card does not attach the ppc anymore. The hint entries > > hint.ppc.0.at=puc0 > hint.ppc.0.irq="" > hint.ppc.0.flags=0x2F > > get ignored and so it probes as ppc1 (failing due to the interrupt > problem as it was in 7.4 without hints): > > puc0: port 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > uart2: at port 1 on puc0 > uart3: <16550 or compatible> at port 2 on puc0 > ppc1: at port 3 on puc0 > ppc1: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppc1: failed to register interrupt handler: 6 > device_attach: ppc1 attach returned 6 > > Any ideas? How do I construct the hint entries under 9.1 so that > > 1. it does not want to use the interrupt (which made it attach under 7.4) > 2. it takes the flags 0x2F as it did before. > > I have also never understood if ppc itself needs to attach to > the irq as well (I thought this all would be handled by puc). Well, ppc wants to use puc's interrupt, and it should be finding puc's interrupt. Ah, I think I found the bug. Try this patch to sys/dev/puc/puc.c: Index: puc.c =================================================================== --- puc.c (revision 245225) +++ puc.c (working copy) @@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s if (cookiep == NULL || res != port->p_ires) return (EINVAL); /* We demand that serdev devices use filter_only interrupts. */ - if (ihand != NULL) + if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL) return (ENXIO); if (rman_get_device(port->p_ires) != originator) return (ENXIO); This should let your ppc device re-use IRQ 17 from your puc device. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Tue Jan 15 07:13:17 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6FD7BF42; Tue, 15 Jan 2013 07:13:17 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 09C7BE8; Tue, 15 Jan 2013 07:13:16 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r0F7DAk0023072; Tue, 15 Jan 2013 08:13:10 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r0F7DAc3011251; Tue, 15 Jan 2013 08:13:10 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.14.5/8.14.5) id r0F7DA0e054175; Date: Tue, 15 Jan 2013 08:13:09 +0100 From: Andre Albsmeier To: John Baldwin Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Message-ID: <20130115071309.GA1443@bali> References: <20130110074052.GA8922@bali> <201301141502.58550.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301141502.58550.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:13:17 -0000 On Mon, 14-Jan-2013 at 21:02:58 +0100, John Baldwin wrote: > On Thursday, January 10, 2013 2:40:52 am Andre Albsmeier wrote: > > [Retrying here, maybe anyone can help...} > > > > I want my printer port back on 9.1 ;-( > > > > I have this card: > > > > puc0@pci0:4:1:0: class=0x078000 card=0x00121000 chip=0x98359710 > rev=0x01 hdr=0x00 > > vendor = 'NetMos Technology' > > device = 'PCI 9835 Multi-I/O Controller' > > class = simple comms > > > > It attached and worked under 7.4-STABLE (as long as I disabled > > the interrupt using hint.ppc.0.irq=""): > > > > puc0: port > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > puc0: [FILTER] > > uart0: on puc0 > > uart0: [FILTER] > > uart1: on puc0 > > uart1: [FILTER] > > ppc0: on puc0 > > ppc0: Generic chipset (ECP/EPP/PS2/NIBBLE) in ECP+EPP mode (EPP 1.9) > > ppbus0: on ppc0 > > lpt0: on ppbus0 > > lpt0: Polled port > > > > > > Under 9.1 the card does not attach the ppc anymore. The hint entries > > > > hint.ppc.0.at=puc0 > > hint.ppc.0.irq="" > > hint.ppc.0.flags=0x2F > > > > get ignored and so it probes as ppc1 (failing due to the interrupt > > problem as it was in 7.4 without hints): > > > > puc0: port > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > uart2: at port 1 on puc0 > > uart3: <16550 or compatible> at port 2 on puc0 > > ppc1: at port 3 on puc0 > > ppc1: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > > ppc1: failed to register interrupt handler: 6 > > device_attach: ppc1 attach returned 6 > > > > Any ideas? How do I construct the hint entries under 9.1 so that > > > > 1. it does not want to use the interrupt (which made it attach under 7.4) > > 2. it takes the flags 0x2F as it did before. > > > > I have also never understood if ppc itself needs to attach to > > the irq as well (I thought this all would be handled by puc). > > Well, ppc wants to use puc's interrupt, and it should be finding puc's > interrupt. Ah, I think I found the bug. Try this patch to sys/dev/puc/puc.c: > > Index: puc.c > =================================================================== > --- puc.c (revision 245225) > +++ puc.c (working copy) > @@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s > if (cookiep == NULL || res != port->p_ires) > return (EINVAL); > /* We demand that serdev devices use filter_only interrupts. */ > - if (ihand != NULL) > + if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL) > return (ENXIO); > if (rman_get_device(port->p_ires) != originator) > return (ENXIO); > > This should let your ppc device re-use IRQ 17 from your puc device. John, thanks a lot for looking at this. I have stumbled over this line as well last weekend but wasn't sure if I can go this way. I will try your patch and report later... Thanks, -Andre > > -- > John Baldwin -- GNU is Not Unix / Linux Is Not UniX From owner-freebsd-hardware@FreeBSD.ORG Tue Jan 15 15:44:35 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5579394E; Tue, 15 Jan 2013 15:44:35 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id E0361DE; Tue, 15 Jan 2013 15:44:34 +0000 (UTC) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r0FFiXZ3013034; Tue, 15 Jan 2013 16:44:33 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id r0FFiXEg006205; Tue, 15 Jan 2013 16:44:33 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.14.5/8.14.5) id r0FFiX4l056050; Date: Tue, 15 Jan 2013 16:44:33 +0100 From: Andre Albsmeier To: John Baldwin Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Message-ID: <20130115154433.GA3459@bali> References: <20130110074052.GA8922@bali> <201301141502.58550.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301141502.58550.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:44:35 -0000 On Mon, 14-Jan-2013 at 21:02:58 +0100, John Baldwin wrote: > On Thursday, January 10, 2013 2:40:52 am Andre Albsmeier wrote: > > [Retrying here, maybe anyone can help...} > > > > I want my printer port back on 9.1 ;-( > > > > I have this card: > > > > puc0@pci0:4:1:0: class=0x078000 card=0x00121000 chip=0x98359710 > rev=0x01 hdr=0x00 > > vendor = 'NetMos Technology' > > device = 'PCI 9835 Multi-I/O Controller' > > class = simple comms > > > > It attached and worked under 7.4-STABLE (as long as I disabled > > the interrupt using hint.ppc.0.irq=""): > > > > puc0: port > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > puc0: [FILTER] > > uart0: on puc0 > > uart0: [FILTER] > > uart1: on puc0 > > uart1: [FILTER] > > ppc0: on puc0 > > ppc0: Generic chipset (ECP/EPP/PS2/NIBBLE) in ECP+EPP mode (EPP 1.9) > > ppbus0: on ppc0 > > lpt0: on ppbus0 > > lpt0: Polled port > > > > > > Under 9.1 the card does not attach the ppc anymore. The hint entries > > > > hint.ppc.0.at=puc0 > > hint.ppc.0.irq="" > > hint.ppc.0.flags=0x2F > > > > get ignored and so it probes as ppc1 (failing due to the interrupt > > problem as it was in 7.4 without hints): > > > > puc0: port > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > uart2: at port 1 on puc0 > > uart3: <16550 or compatible> at port 2 on puc0 > > ppc1: at port 3 on puc0 > > ppc1: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > > ppc1: failed to register interrupt handler: 6 > > device_attach: ppc1 attach returned 6 > > > > Any ideas? How do I construct the hint entries under 9.1 so that > > > > 1. it does not want to use the interrupt (which made it attach under 7.4) > > 2. it takes the flags 0x2F as it did before. > > > > I have also never understood if ppc itself needs to attach to > > the irq as well (I thought this all would be handled by puc). > > Well, ppc wants to use puc's interrupt, and it should be finding puc's > interrupt. Ah, I think I found the bug. Try this patch to sys/dev/puc/puc.c: > > Index: puc.c > =================================================================== > --- puc.c (revision 245225) > +++ puc.c (working copy) > @@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s > if (cookiep == NULL || res != port->p_ires) > return (EINVAL); > /* We demand that serdev devices use filter_only interrupts. */ > - if (ihand != NULL) > + if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL) > return (ENXIO); > if (rman_get_device(port->p_ires) != originator) > return (ENXIO); > > This should let your ppc device re-use IRQ 17 from your puc device. True, this really makes ppc use puc's interrupt: I removed my local hack (more on this later) which brought the lost hint.ppc.0.flags functionality back and applied the patch. Now ppc attaches to puc without errors and which also is confirmed by lpt: lpt0: on ppbus0 lpt0: Interrupt-driven port (And, yes, I even printed a page with it ;-)) I have no idea if this has ever worked before -- in FreeBSD-7 I also had to use the "do not use interrupt"-flag 0x20 in loader.conf or ppc wouldn't have attached... Which brings me back to the initial problem: Hints like hint.ppc.0.at=puc0 hint.ppc.0.irq="" hint.ppc.0.flags=0x2F seems to be ignored in 9.1. While the interrupt thing seems to be fixed now, one possibly still wants to used the other flags. I have helped myself with this (ugly) patch to ppc --- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100 +++ ppc.c 2013-01-12 18:07:24.000000000 +0100 @@ -1729,6 +1729,11 @@ ppc->ppc_base = rman_get_start(ppc->res_ioport); ppc->ppc_flags = device_get_flags(dev); + if( ppc->ppc_flags == 0 ) { + int tmp; + if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp) == 0 ) + ppc->ppc_flags = tmp; + } if (!(ppc->ppc_flags & 0x20)) { ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, in order to get at least the flags applied as it was the case before in FreeBSD-7. Unfortuantely, I have no idea how to fix that properly ;-(... Thanks, -Andre > > -- > John Baldwin -- Linux is no OS. It's a core dump which boots by accident. From owner-freebsd-hardware@FreeBSD.ORG Tue Jan 15 16:07:23 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6423D50F for ; Tue, 15 Jan 2013 16:07:23 +0000 (UTC) (envelope-from landsidel.allen@gmail.com) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by mx1.freebsd.org (Postfix) with ESMTP id 24ACD279 for ; Tue, 15 Jan 2013 16:07:22 +0000 (UTC) Received: by mail-vb0-f43.google.com with SMTP id fs19so275092vbb.16 for ; Tue, 15 Jan 2013 08:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type; bh=4yUtwzimCRFa4yWzbCaxBjCKtxIc1BJpz6BP+dXUTqQ=; b=bT4fVi0Ulhm9RkICHoh/nGDhTwaNQKyGluc7ecK21nsQPVVTRwIytDNfuRTxtfakx7 x7aeoD5RGEujXTbTrGkkifmMbMFOrSUK4OR7IMGiubaooyawb/ZFI4cveqLeTCfcu3n8 l71TKVXyh1U32dA40aEE6AbQ58E7Ztz+OaO+otA3GfSV5uh29H+3g8d97ebMBA/fTj8H 0vNsBs0Qe36iAZ3VGmqBOzNNQ8hBUoUkYpXPwTgcUBQs/JOkTpLB7LRjeTGlE6/GnkqL aftFHkuXQZUq9WOkXxhrPvnZJLZQCeVBxGTueoAoVwmxmPj4UIGqAhXpOW4xk/Z8RCfn MU7Q== X-Received: by 10.52.22.207 with SMTP id g15mr91632011vdf.61.1358266041996; Tue, 15 Jan 2013 08:07:21 -0800 (PST) Received: from [192.168.130.0] (c-66-30-48-132.hsd1.nh.comcast.net. [66.30.48.132]) by mx.google.com with ESMTPS id w4sm8745654vdj.21.2013.01.15.08.07.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 08:07:21 -0800 (PST) Message-ID: <50F57EB5.1060801@gmail.com> Date: Tue, 15 Jan 2013 11:07:17 -0500 From: Allen Landsidel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Subject: Fwd: Re: bin/166589: atacontrol(8) incorrectly treats RAID10 and 0+1 the same References: <50F57C0D.1010608@FreeBSD.org> In-Reply-To: <50F57C0D.1010608@FreeBSD.org> X-Forwarded-Message-Id: <50F57C0D.1010608@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:07:23 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=166589&cat= Can somebody else talk some sense into this guy? I'm losing my temper. -------- Original Message -------- Subject: Re: bin/166589: atacontrol(8) incorrectly treats RAID10 and 0+1 the same Date: Tue, 15 Jan 2013 17:55:57 +0200 From: Alexander Motin To: Allen Landsidel CC: bug-followup@FreeBSD.org Their on-disk formats are identical. Even if RAID BIOS supports RAID0+1, there is no problem to handle it as RAID10 at the OS level. That gives better reliability without any downsides. I think there is much higher chance that inexperienced user will choose RAID0+1 by mistake, then experienced wish do to it on intentionally. Do you know any reason why RAID0+1 can't be handled as RAID10? On 15.01.2013 17:28, Allen Landsidel wrote: > Most devices typically only support one level or the other, but not > both. I don't "Insist that it should exist", it *does* exist. Both > levels do, and they are not the same thing. > > As for why it should be "available" to the user, I think that's a pretty > silly question. If their hardware supports one or both levels, they > should be available to the user -- and called by their correct names. > > On 1/15/2013 03:12, Alexander Motin wrote: >> That is clear and I had guess you mean it, but why do you insist that >> such RAID0+1 variant should even exist if it has no benefits over >> RAID10, and why it should be explicitly available to user? >> >> On 15.01.2013 04:51, Allen Landsidel wrote: >>> They are not variants in terminology, they are different raid levels. >>> Raid0+1 is two RAID-0 arrays, mirrored into a RAID-1. if one of the >>> disks fails, that entire RAID-0 is offline and must be rebuilt, and all >>> redundancy is lost. A RAID-10 is composed of N raid-1 disks combined >>> into a RAID-0. If one disk fails, only that particular RAID-1 is >>> degraded, and the redundancy of the others is maintained. >>> >>> 0+1 cannot survive two failed disks no matter how many are in the >>> array. 10 can survive half the disks failing, if it's the right half. >>> >>> This is something people who've never used more than 4 disks fail to >>> grasp, but those of us with 6 (or many many more) know very well. >>> >>> On 1/14/2013 21:46, Alexander Motin wrote: >>>> There could be variants in terminology, but in fact for most of users >>>> they are the same. If you have opinion why they should be treated >>>> differently, please explain it. > -- Alexander Motin From owner-freebsd-hardware@FreeBSD.ORG Tue Jan 15 20:27:52 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53A8488C for ; Tue, 15 Jan 2013 20:27:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C9F563E for ; Tue, 15 Jan 2013 20:27:52 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8941BB953; Tue, 15 Jan 2013 15:27:51 -0500 (EST) From: John Baldwin To: freebsd-hardware@freebsd.org Subject: Re: Fwd: Re: bin/166589: atacontrol(8) incorrectly treats RAID10 and 0+1 the same Date: Tue, 15 Jan 2013 14:13:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <50F57C0D.1010608@FreeBSD.org> <50F57EB5.1060801@gmail.com> In-Reply-To: <50F57EB5.1060801@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301151413.22505.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:27:51 -0500 (EST) Cc: Allen Landsidel X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:27:52 -0000 On Tuesday, January 15, 2013 11:07:17 am Allen Landsidel wrote: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=166589&cat= > > Can somebody else talk some sense into this guy? I'm losing my temper. Well, is his last question correct? If the RAID BIOS writes the metadata the same way regardless, then is there a reason (beyond "pure correctness") to not just treat RAID0+1 as RAID10? > -------- Original Message -------- > Subject: Re: bin/166589: atacontrol(8) incorrectly treats RAID10 and > 0+1 the same > Date: Tue, 15 Jan 2013 17:55:57 +0200 > From: Alexander Motin > To: Allen Landsidel > CC: bug-followup@FreeBSD.org > > > > Their on-disk formats are identical. Even if RAID BIOS supports RAID0+1, > there is no problem to handle it as RAID10 at the OS level. That gives > better reliability without any downsides. I think there is much higher > chance that inexperienced user will choose RAID0+1 by mistake, then > experienced wish do to it on intentionally. Do you know any reason why > RAID0+1 can't be handled as RAID10? > > On 15.01.2013 17:28, Allen Landsidel wrote: > > Most devices typically only support one level or the other, but not > > both. I don't "Insist that it should exist", it *does* exist. Both > > levels do, and they are not the same thing. > > > > As for why it should be "available" to the user, I think that's a pretty > > silly question. If their hardware supports one or both levels, they > > should be available to the user -- and called by their correct names. > > > > On 1/15/2013 03:12, Alexander Motin wrote: > >> That is clear and I had guess you mean it, but why do you insist that > >> such RAID0+1 variant should even exist if it has no benefits over > >> RAID10, and why it should be explicitly available to user? > >> > >> On 15.01.2013 04:51, Allen Landsidel wrote: > >>> They are not variants in terminology, they are different raid levels. > >>> Raid0+1 is two RAID-0 arrays, mirrored into a RAID-1. if one of the > >>> disks fails, that entire RAID-0 is offline and must be rebuilt, and all > >>> redundancy is lost. A RAID-10 is composed of N raid-1 disks combined > >>> into a RAID-0. If one disk fails, only that particular RAID-1 is > >>> degraded, and the redundancy of the others is maintained. > >>> > >>> 0+1 cannot survive two failed disks no matter how many are in the > >>> array. 10 can survive half the disks failing, if it's the right half. > >>> > >>> This is something people who've never used more than 4 disks fail to > >>> grasp, but those of us with 6 (or many many more) know very well. > >>> > >>> On 1/14/2013 21:46, Alexander Motin wrote: > >>>> There could be variants in terminology, but in fact for most of users > >>>> they are the same. If you have opinion why they should be treated > >>>> differently, please explain it. > > > > > -- > Alexander Motin > > > > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Tue Jan 15 20:28:01 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B0BA8DC for ; Tue, 15 Jan 2013 20:28:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 623BC64B for ; Tue, 15 Jan 2013 20:28:01 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C6EDEB948; Tue, 15 Jan 2013 15:28:00 -0500 (EST) From: John Baldwin To: Andre Albsmeier Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Date: Tue, 15 Jan 2013 15:27:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130110074052.GA8922@bali> <201301141502.58550.jhb@freebsd.org> <20130115154433.GA3459@bali> In-Reply-To: <20130115154433.GA3459@bali> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301151527.07227.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:28:00 -0500 (EST) Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:28:01 -0000 On Tuesday, January 15, 2013 10:44:33 am Andre Albsmeier wrote: > On Mon, 14-Jan-2013 at 21:02:58 +0100, John Baldwin wrote: > > On Thursday, January 10, 2013 2:40:52 am Andre Albsmeier wrote: > > > [Retrying here, maybe anyone can help...} > > > > > > I want my printer port back on 9.1 ;-( > > > > > > I have this card: > > > > > > puc0@pci0:4:1:0: class=0x078000 card=0x00121000 chip=0x98359710 > > rev=0x01 hdr=0x00 > > > vendor = 'NetMos Technology' > > > device = 'PCI 9835 Multi-I/O Controller' > > > class = simple comms > > > > > > It attached and worked under 7.4-STABLE (as long as I disabled > > > the interrupt using hint.ppc.0.irq=""): > > > > > > puc0: port > > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > > puc0: [FILTER] > > > uart0: on puc0 > > > uart0: [FILTER] > > > uart1: on puc0 > > > uart1: [FILTER] > > > ppc0: on puc0 > > > ppc0: Generic chipset (ECP/EPP/PS2/NIBBLE) in ECP+EPP mode (EPP 1.9) > > > ppbus0: on ppc0 > > > lpt0: on ppbus0 > > > lpt0: Polled port > > > > > > > > > Under 9.1 the card does not attach the ppc anymore. The hint entries > > > > > > hint.ppc.0.at=puc0 > > > hint.ppc.0.irq="" > > > hint.ppc.0.flags=0x2F > > > > > > get ignored and so it probes as ppc1 (failing due to the interrupt > > > problem as it was in 7.4 without hints): > > > > > > puc0: port > > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > > uart2: at port 1 on puc0 > > > uart3: <16550 or compatible> at port 2 on puc0 > > > ppc1: at port 3 on puc0 > > > ppc1: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > > > ppc1: failed to register interrupt handler: 6 > > > device_attach: ppc1 attach returned 6 > > > > > > Any ideas? How do I construct the hint entries under 9.1 so that > > > > > > 1. it does not want to use the interrupt (which made it attach under 7.4) > > > 2. it takes the flags 0x2F as it did before. > > > > > > I have also never understood if ppc itself needs to attach to > > > the irq as well (I thought this all would be handled by puc). > > > > Well, ppc wants to use puc's interrupt, and it should be finding puc's > > interrupt. Ah, I think I found the bug. Try this patch to sys/dev/puc/puc.c: > > > > Index: puc.c > > =================================================================== > > --- puc.c (revision 245225) > > +++ puc.c (working copy) > > @@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s > > if (cookiep == NULL || res != port->p_ires) > > return (EINVAL); > > /* We demand that serdev devices use filter_only interrupts. */ > > - if (ihand != NULL) > > + if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL) > > return (ENXIO); > > if (rman_get_device(port->p_ires) != originator) > > return (ENXIO); > > > > This should let your ppc device re-use IRQ 17 from your puc device. > > True, this really makes ppc use puc's interrupt: I removed > my local hack (more on this later) which brought the lost > hint.ppc.0.flags functionality back and applied the patch. > Now ppc attaches to puc without errors and which also is > confirmed by lpt: > > lpt0: on ppbus0 > lpt0: Interrupt-driven port > > (And, yes, I even printed a page with it ;-)) Great! I've committed that fix to HEAD and will MFC. > I have no idea if this has ever worked before -- in FreeBSD-7 I > also had to use the "do not use interrupt"-flag 0x20 in loader.conf > or ppc wouldn't have attached... > > Which brings me back to the initial problem: Hints like > > hint.ppc.0.at=puc0 > hint.ppc.0.irq="" > hint.ppc.0.flags=0x2F > > seems to be ignored in 9.1. While the interrupt thing seems > to be fixed now, one possibly still wants to used the other > flags. I have helped myself with this (ugly) patch to ppc > > --- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100 > +++ ppc.c 2013-01-12 18:07:24.000000000 +0100 > @@ -1729,6 +1729,11 @@ > ppc->ppc_base = rman_get_start(ppc->res_ioport); > > ppc->ppc_flags = device_get_flags(dev); > + if( ppc->ppc_flags == 0 ) { > + int tmp; > + if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp) == 0 ) > + ppc->ppc_flags = tmp; > + } > > if (!(ppc->ppc_flags & 0x20)) { > ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, > > in order to get at least the flags applied as it was the case > before in FreeBSD-7. Unfortuantely, I have no idea how to fix > that properly ;-(... This should not be needed for "flags". Look for 'devflags' in sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during device probe and stores them in dev->devflags and leaves them there after a successful probe (so they should be seen by attach). Specifically, note: /* Set the winning driver, devclass, and flags. */ if (!child->devclass) { result = device_set_devclass(child, best->driver->name); if (result != 0) return (result); } result = device_set_driver(child, best->driver); if (result != 0) return (result); resource_int_value(best->driver->name, child->unit, "flags", &child->devflags); This 'devflags' variable is what device_get_flags() returns. You should be able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no other hints meaning no "at", etc.) Perhaps try adding some debug printfs in subr_bus.c to make sure this is fetching the flags you expect? -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Tue Jan 15 20:38:43 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5FF8DFC9; Tue, 15 Jan 2013 20:38:43 +0000 (UTC) (envelope-from landsidel.allen@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA93721; Tue, 15 Jan 2013 20:38:42 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id l6so584194vcl.23 for ; Tue, 15 Jan 2013 12:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LGXylZR/pV7eo9guB/oQE8yXdD0Fq4sJJipw4jDHkVI=; b=r53HQwvgjYXbAKYzRoJ9ZAluYj/CQoeZqAmkFiyE2tmB9+vWDSbkkY/3N6OBBi0bRV Y2sG+MZwJ/76NaMqzxHBebltylggWUi2CEY5yayeqzekslNgEwX/O7Q80O6RX6vtdsur Xm0wCaBzhuttUKKsDnbD10fHNXbbjeVv1pUcZn5kSwy3G6gU5ja6zHtpIjil2J1CWTmE LoFP+tPtZ2QJiwVZ3Z2keJr8dbf9P28f4rRnmK8i0+95kr6JpZDGfeT1PKODNJS/8QJI AelatbeWjMpVvW3pVGcQHnkdU+w8gIcGukzlZKet0dU/2h9krcT4NjLsYGdk5lEWlz6Y RcuQ== X-Received: by 10.52.21.13 with SMTP id r13mr26235537vde.37.1358282318495; Tue, 15 Jan 2013 12:38:38 -0800 (PST) Received: from [192.168.130.0] (c-66-30-48-132.hsd1.nh.comcast.net. [66.30.48.132]) by mx.google.com with ESMTPS id t6sm9169850vdf.18.2013.01.15.12.38.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 12:38:37 -0800 (PST) Message-ID: <50F5BE48.2090508@gmail.com> Date: Tue, 15 Jan 2013 15:38:32 -0500 From: Allen Landsidel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fwd: Re: bin/166589: atacontrol(8) incorrectly treats RAID10 and 0+1 the same References: <50F57C0D.1010608@FreeBSD.org> <50F57EB5.1060801@gmail.com> <201301151413.22505.jhb@freebsd.org> In-Reply-To: <201301151413.22505.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hardware@freebsd.org X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:38:43 -0000 Several updates have occurred since the email, I think I've explained it to him well enough. Yes, there is a difference. A "fakeraid" / firmware RAID0+1 with two failed disks will not boot. A RAID10 will, if it's not the "wrong" 2nd disk. Even though the OS has no control over this behavior, it's not doing anyone any favors to suppressed or obscure the what the hardware is capable of. A RAID0+1 is a no-buy for many, including myself. A controller sold claiming to do RAID10 that actually does 0+1 is an RMA item. On 1/15/2013 14:13, John Baldwin wrote: > On Tuesday, January 15, 2013 11:07:17 am Allen Landsidel wrote: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=166589&cat= >> >> Can somebody else talk some sense into this guy? I'm losing my temper. > Well, is his last question correct? If the RAID BIOS writes the metadata > the same way regardless, then is there a reason (beyond "pure correctness") to > not just treat RAID0+1 as RAID10? > >> -------- Original Message -------- >> Subject: Re: bin/166589: atacontrol(8) incorrectly treats RAID10 and >> 0+1 the same >> Date: Tue, 15 Jan 2013 17:55:57 +0200 >> From: Alexander Motin >> To: Allen Landsidel >> CC: bug-followup@FreeBSD.org >> >> >> >> Their on-disk formats are identical. Even if RAID BIOS supports RAID0+1, >> there is no problem to handle it as RAID10 at the OS level. That gives >> better reliability without any downsides. I think there is much higher >> chance that inexperienced user will choose RAID0+1 by mistake, then >> experienced wish do to it on intentionally. Do you know any reason why >> RAID0+1 can't be handled as RAID10? >> >> On 15.01.2013 17:28, Allen Landsidel wrote: >>> Most devices typically only support one level or the other, but not >>> both. I don't "Insist that it should exist", it *does* exist. Both >>> levels do, and they are not the same thing. >>> >>> As for why it should be "available" to the user, I think that's a pretty >>> silly question. If their hardware supports one or both levels, they >>> should be available to the user -- and called by their correct names. >>> >>> On 1/15/2013 03:12, Alexander Motin wrote: >>>> That is clear and I had guess you mean it, but why do you insist that >>>> such RAID0+1 variant should even exist if it has no benefits over >>>> RAID10, and why it should be explicitly available to user? >>>> >>>> On 15.01.2013 04:51, Allen Landsidel wrote: >>>>> They are not variants in terminology, they are different raid levels. >>>>> Raid0+1 is two RAID-0 arrays, mirrored into a RAID-1. if one of the >>>>> disks fails, that entire RAID-0 is offline and must be rebuilt, and all >>>>> redundancy is lost. A RAID-10 is composed of N raid-1 disks combined >>>>> into a RAID-0. If one disk fails, only that particular RAID-1 is >>>>> degraded, and the redundancy of the others is maintained. >>>>> >>>>> 0+1 cannot survive two failed disks no matter how many are in the >>>>> array. 10 can survive half the disks failing, if it's the right half. >>>>> >>>>> This is something people who've never used more than 4 disks fail to >>>>> grasp, but those of us with 6 (or many many more) know very well. >>>>> >>>>> On 1/14/2013 21:46, Alexander Motin wrote: >>>>>> There could be variants in terminology, but in fact for most of users >>>>>> they are the same. If you have opinion why they should be treated >>>>>> differently, please explain it. >> >> -- >> Alexander Motin >> >> >> >> _______________________________________________ >> freebsd-hardware@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware >> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" >> From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 16 13:17:27 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 93612EAF for ; Wed, 16 Jan 2013 13:17:27 +0000 (UTC) (envelope-from ayuzhaninov@openstat.ru) Received: from mail.openstat.ru (mail.openstat.ru [193.169.234.252]) by mx1.freebsd.org (Postfix) with ESMTP id 41D10735 for ; Wed, 16 Jan 2013 13:17:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openstat.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=VdqwsAl35ka4HU/+fGcPxcQ3sA06WFBcoUovLMm8suU=; b=di6Yq1jZ/Cs68ZSFGJWENJm/JVJ5Glidg3Ew4TFIakNKFEu9UGTPMBEaO6tAlzwKDDnIp+M1uCixyfp2gBW2+cKdSivVce+eJwhiXawCLTKyka4UDxaYzhrVMAYLNVO8MfO3jDkq2RSrxBf/U/wtIziTASIHHWmLAspLX42j6dM=; Received: from citrin.office.vega.ru ([10.100.124.49]) by mail.openstat.ru with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TvSlL-00070J-L4 for freebsd-hardware@freebsd.org; Wed, 16 Jan 2013 17:10:39 +0400 Message-ID: <50F6A6CF.80901@openstat.ru> Date: Wed, 16 Jan 2013 17:10:39 +0400 From: Anton Yuzhaninov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Subject: Intel QST driver Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: ayuzhaninov X-Rspam-Status: skip_authenticated X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 13:17:27 -0000 Is anybody working on driver for access motherboard sensors via Intel QST? There is open source SDK from Intel: http://software.intel.com/en-us/blogs/2010/02/18/great-news-the-intelr-qst-sdk-is-now-public -- Anton Yuzhaninov From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 16 16:33:50 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E77E41F0; Wed, 16 Jan 2013 16:33:50 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 70DCF939; Wed, 16 Jan 2013 16:33:49 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r0GGXgld000305; Wed, 16 Jan 2013 17:33:42 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r0GGXgKA010057; Wed, 16 Jan 2013 17:33:42 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.14.5/8.14.5) id r0GGXgqE060976; Date: Wed, 16 Jan 2013 17:33:42 +0100 From: Andre Albsmeier To: John Baldwin Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Message-ID: <20130116163342.GA30733@bali> References: <20130110074052.GA8922@bali> <201301141502.58550.jhb@freebsd.org> <20130115154433.GA3459@bali> <201301151527.07227.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301151527.07227.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 16:33:51 -0000 On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote: > On Tuesday, January 15, 2013 10:44:33 am Andre Albsmeier wrote: > > On Mon, 14-Jan-2013 at 21:02:58 +0100, John Baldwin wrote: > > > On Thursday, January 10, 2013 2:40:52 am Andre Albsmeier wrote: > > > > [Retrying here, maybe anyone can help...} > > > > > > > > I want my printer port back on 9.1 ;-( > > > > > > > > I have this card: > > > > > > > > puc0@pci0:4:1:0: class=0x078000 card=0x00121000 chip=0x98359710 > > > rev=0x01 hdr=0x00 > > > > vendor = 'NetMos Technology' > > > > device = 'PCI 9835 Multi-I/O Controller' > > > > class = simple comms > > > > > > > > It attached and worked under 7.4-STABLE (as long as I disabled > > > > the interrupt using hint.ppc.0.irq=""): > > > > > > > > puc0: port > > > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > > > puc0: [FILTER] > > > > uart0: on puc0 > > > > uart0: [FILTER] > > > > uart1: on puc0 > > > > uart1: [FILTER] > > > > ppc0: on puc0 > > > > ppc0: Generic chipset (ECP/EPP/PS2/NIBBLE) in ECP+EPP mode (EPP 1.9) > > > > ppbus0: on ppc0 > > > > lpt0: on ppbus0 > > > > lpt0: Polled port > > > > > > > > > > > > Under 9.1 the card does not attach the ppc anymore. The hint entries > > > > > > > > hint.ppc.0.at=puc0 > > > > hint.ppc.0.irq="" > > > > hint.ppc.0.flags=0x2F > > > > > > > > get ignored and so it probes as ppc1 (failing due to the interrupt > > > > problem as it was in 7.4 without hints): > > > > > > > > puc0: port > > > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07 > > > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4 > > > > uart2: at port 1 on puc0 > > > > uart3: <16550 or compatible> at port 2 on puc0 > > > > ppc1: at port 3 on puc0 > > > > ppc1: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > > > > ppc1: failed to register interrupt handler: 6 > > > > device_attach: ppc1 attach returned 6 > > > > > > > > Any ideas? How do I construct the hint entries under 9.1 so that > > > > > > > > 1. it does not want to use the interrupt (which made it attach under > 7.4) > > > > 2. it takes the flags 0x2F as it did before. > > > > > > > > I have also never understood if ppc itself needs to attach to > > > > the irq as well (I thought this all would be handled by puc). > > > > > > Well, ppc wants to use puc's interrupt, and it should be finding puc's > > > interrupt. Ah, I think I found the bug. Try this patch to > sys/dev/puc/puc.c: > > > > > > Index: puc.c > > > =================================================================== > > > --- puc.c (revision 245225) > > > +++ puc.c (working copy) > > > @@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s > > > if (cookiep == NULL || res != port->p_ires) > > > return (EINVAL); > > > /* We demand that serdev devices use filter_only interrupts. */ > > > - if (ihand != NULL) > > > + if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL) > > > return (ENXIO); > > > if (rman_get_device(port->p_ires) != originator) > > > return (ENXIO); > > > > > > This should let your ppc device re-use IRQ 17 from your puc device. > > > > True, this really makes ppc use puc's interrupt: I removed > > my local hack (more on this later) which brought the lost > > hint.ppc.0.flags functionality back and applied the patch. > > Now ppc attaches to puc without errors and which also is > > confirmed by lpt: > > > > lpt0: on ppbus0 > > lpt0: Interrupt-driven port > > > > (And, yes, I even printed a page with it ;-)) > > Great! I've committed that fix to HEAD and will MFC. Thanks! > > > I have no idea if this has ever worked before -- in FreeBSD-7 I > > also had to use the "do not use interrupt"-flag 0x20 in loader.conf > > or ppc wouldn't have attached... > > > > Which brings me back to the initial problem: Hints like > > > > hint.ppc.0.at=puc0 > > hint.ppc.0.irq="" > > hint.ppc.0.flags=0x2F > > > > seems to be ignored in 9.1. While the interrupt thing seems > > to be fixed now, one possibly still wants to used the other > > flags. I have helped myself with this (ugly) patch to ppc > > > > --- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100 > > +++ ppc.c 2013-01-12 18:07:24.000000000 +0100 > > @@ -1729,6 +1729,11 @@ > > ppc->ppc_base = rman_get_start(ppc->res_ioport); > > > > ppc->ppc_flags = device_get_flags(dev); > > + if( ppc->ppc_flags == 0 ) { > > + int tmp; > > + if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp) > == 0 ) > > + ppc->ppc_flags = tmp; > > + } > > > > if (!(ppc->ppc_flags & 0x20)) { > > ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, > > > > in order to get at least the flags applied as it was the case > > before in FreeBSD-7. Unfortuantely, I have no idea how to fix > > that properly ;-(... > > This should not be needed for "flags". Look for 'devflags' in > sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during > device probe and stores them in dev->devflags and leaves them there after a > successful probe (so they should be seen by attach). Specifically, note: > > /* Set the winning driver, devclass, and flags. */ > if (!child->devclass) { > result = device_set_devclass(child, best->driver->name); > if (result != 0) > return (result); > } > result = device_set_driver(child, best->driver); > if (result != 0) > return (result); > resource_int_value(best->driver->name, child->unit, > "flags", &child->devflags); > > This 'devflags' variable is what device_get_flags() returns. You should be > able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no > other hints meaning no "at", etc.) Hmm, you are right. It now works even without my hackish patch. Apparently, the "flags" hints (indicating that no interrupt should be used) were not observed when I tried to use them to work around the bug (which you fixed now). But after a successful attach they are used and this is what's really important. Thanks for you help, -Andre From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 17 03:10:39 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76EF4202; Thu, 17 Jan 2013 03:10:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0742A3E0; Thu, 17 Jan 2013 03:10:38 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0H3AZMG011287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 14:10:36 +1100 Date: Thu, 17 Jan 2013 14:10:34 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andre Albsmeier Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works In-Reply-To: <20130116163342.GA30733@bali> Message-ID: <20130117134523.K1345@besplex.bde.org> References: <20130110074052.GA8922@bali> <201301141502.58550.jhb@freebsd.org> <20130115154433.GA3459@bali> <201301151527.07227.jhb@freebsd.org> <20130116163342.GA30733@bali> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zty1sKHG c=1 sm=1 a=_UANyrYDgloA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=D2UiwzQrqZMA:10 a=zz2zN5Br6-0ck3MPuXEA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 03:10:39 -0000 On Wed, 16 Jan 2013, Andre Albsmeier wrote: > On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote: >> On Tuesday, January 15, 2013 10:44:33 am Andre Albsmeier wrote: >>* ... >>> I have no idea if this has ever worked before -- in FreeBSD-7 I >>> also had to use the "do not use interrupt"-flag 0x20 in loader.conf >>> or ppc wouldn't have attached... >>> >>> Which brings me back to the initial problem: Hints like >>> >>> hint.ppc.0.at=puc0 >>> hint.ppc.0.irq="" >>> hint.ppc.0.flags=0x2F >>> >>> seems to be ignored in 9.1. While the interrupt thing seems >>> to be fixed now, one possibly still wants to used the other >>> flags. I have helped myself with this (ugly) patch to ppc >>> >>> --- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100 >>> +++ ppc.c 2013-01-12 18:07:24.000000000 +0100 >>> @@ -1729,6 +1729,11 @@ >>> ppc->ppc_base = rman_get_start(ppc->res_ioport); >>> >>> ppc->ppc_flags = device_get_flags(dev); >>> + if( ppc->ppc_flags == 0 ) { >>> + int tmp; >>> + if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp) >> == 0 ) >>> + ppc->ppc_flags = tmp; >>> + } >>> >>> if (!(ppc->ppc_flags & 0x20)) { >>> ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, >>> >>> in order to get at least the flags applied as it was the case >>> before in FreeBSD-7. Unfortuantely, I have no idea how to fix >>> that properly ;-(... >> >> This should not be needed for "flags". Look for 'devflags' in >> sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during >> device probe and stores them in dev->devflags and leaves them there after a >> successful probe (so they should be seen by attach). Specifically, note: >> >> /* Set the winning driver, devclass, and flags. */ So the flags interface is unusable before some driver "wins". >> if (!child->devclass) { >> result = device_set_devclass(child, best->driver->name); >> if (result != 0) >> return (result); >> } >> result = device_set_driver(child, best->driver); >> if (result != 0) >> return (result); >> resource_int_value(best->driver->name, child->unit, >> "flags", &child->devflags); >> >> This 'devflags' variable is what device_get_flags() returns. You should be >> able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no >> other hints meaning no "at", etc.) > > Hmm, you are right. It now works even without my hackish patch. > > Apparently, the "flags" hints (indicating that no interrupt > should be used) were not observed when I tried to use them to > work around the bug (which you fixed now). But after a > successful attach they are used and this is what's really > important. This leaves the layering/ordering bug that device flags are unusable at probe time. But ppc.c only initializes them in ppc_probe(). It assigns them to ppc->ppc_flags and apparently depends on the whole of *ppc living across probe/attach. But it mainly uses the ppc_flags part for the probe, where it is unusable. resource_int_value() is still used a in a few drivers to find the flags. Most of the uses are for low level console drivers, where the device flags are unavailable because new-bus is unavailable. The only new-bus- level probe that uses this method seems to be nvram2env_probe(). Unstructured environment settings can work in drivers, but new-bus is even further from being able to support this (by the definition of "unstructured"). The driver just has to find them using a direct method in the probe if they are needed in the probe. Then there are complications linking these with the new-bus part of the configuration. Bruce From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 17 13:29:08 2013 Return-Path: Delivered-To: freebsd-hardware@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6380A08 for ; Thu, 17 Jan 2013 13:29:08 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id ECFBFDFE for ; Thu, 17 Jan 2013 13:29:07 +0000 (UTC) Received: (qmail 23855 invoked from network); 17 Jan 2013 17:22:24 +0400 Received: from 95-27-78-36.broadband.corbina.ru (95-27-78-36.broadband.corbina.ru [95.27.78.36]) by mail.sub.ru ([88.212.205.2]) with ESMTP via TCP; 31 Dec 1969 23:59:59 -0000 Message-ID: <50F7FB12.5040602@webmail.sub.ru> Date: Thu, 17 Jan 2013 17:22:26 +0400 From: Alex Povolotsky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120817 Thunderbird/14.0 MIME-Version: 1.0 To: Mark Felder Subject: Re: Strange problem with... ZFS? Disk? Controller? References: <50D56D4B.4060709@webmail.sub.ru> <20121222032541.0ceb9f56@tech304> In-Reply-To: <20121222032541.0ceb9f56@tech304> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-hardware@FreeBSD.ORG X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 13:29:08 -0000 On 12/22/12 13:25, Mark Felder wrote: > Try running diskinfo -t /dev/... > > If it says your device is really slow it's probably dying. I'd suspect it's having trouble seeking. > It was a break-in. Some dumb php script running with user privileges managed FreeBSD to hang on disk io up to stopping responding to anything besides reset. Alex From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 17 13:57:00 2013 Return-Path: Delivered-To: freebsd-hardware@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 641FE6EE; Thu, 17 Jan 2013 13:57:00 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 33240F6D; Thu, 17 Jan 2013 13:56:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=MjTYHRTY4K2TeNvGFKh/G0aL3sffha4cpGPt3Mmu8zo=; b=CiR1+XsOw1cln1xBOgzpmmJ1mU8L06A2ZZNKShGhr1aZTDctncaAEd5j51eGpTRJT7fuRciCihpVnCiZhSCZjd5WmeqJT3Qg736F+0JIkNsKyGIsblFo4yaEQoJ8MtT7; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tvpxh-0000Ls-Ch; Thu, 17 Jan 2013 07:56:57 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1358431011-86880-86877/5/2; Thu, 17 Jan 2013 13:56:51 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: Alex Povolotsky Subject: Re: Strange problem with... ZFS? Disk? Controller? References: <50D56D4B.4060709@webmail.sub.ru> <20121222032541.0ceb9f56@tech304> <50F7FB12.5040602@webmail.sub.ru> Date: Thu, 17 Jan 2013 07:56:51 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <50F7FB12.5040602@webmail.sub.ru> User-Agent: Opera Mail/12.12 (FreeBSD) Cc: freebsd-stable@freebsd.org, freebsd-hardware@FreeBSD.ORG X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 13:57:00 -0000 On Thu, 17 Jan 2013 07:22:26 -0600, Alex Povolotsky wrote: > On 12/22/12 13:25, Mark Felder wrote: >> Try running diskinfo -t /dev/... >> >> If it says your device is really slow it's probably dying. I'd suspect >> it's having trouble seeking. >> > It was a break-in. Some dumb php script running with user privileges > managed FreeBSD to hang on disk io up to stopping responding to anything > besides reset. > > Alex Yikes! Make sure to run freebsd-update IDS to check the base OS's checksums and if you're using pkgng you can use "pkg check-s" to look for any tampered with files owned by packages. From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 17 18:40:58 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EDD10697 for ; Thu, 17 Jan 2013 18:40:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0E56948 for ; Thu, 17 Jan 2013 18:40:58 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 09860B95B; Thu, 17 Jan 2013 13:40:58 -0500 (EST) From: John Baldwin To: Bruce Evans Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Date: Thu, 17 Jan 2013 13:37:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130110074052.GA8922@bali> <20130116163342.GA30733@bali> <20130117134523.K1345@besplex.bde.org> In-Reply-To: <20130117134523.K1345@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301171337.56851.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 Jan 2013 13:40:58 -0500 (EST) Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:40:59 -0000 On Wednesday, January 16, 2013 10:10:34 pm Bruce Evans wrote: > On Wed, 16 Jan 2013, Andre Albsmeier wrote: > > > On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote: > >> On Tuesday, January 15, 2013 10:44:33 am Andre Albsmeier wrote: > >>* ... > >>> I have no idea if this has ever worked before -- in FreeBSD-7 I > >>> also had to use the "do not use interrupt"-flag 0x20 in loader.conf > >>> or ppc wouldn't have attached... > >>> > >>> Which brings me back to the initial problem: Hints like > >>> > >>> hint.ppc.0.at=puc0 > >>> hint.ppc.0.irq="" > >>> hint.ppc.0.flags=0x2F > >>> > >>> seems to be ignored in 9.1. While the interrupt thing seems > >>> to be fixed now, one possibly still wants to used the other > >>> flags. I have helped myself with this (ugly) patch to ppc > >>> > >>> --- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100 > >>> +++ ppc.c 2013-01-12 18:07:24.000000000 +0100 > >>> @@ -1729,6 +1729,11 @@ > >>> ppc->ppc_base = rman_get_start(ppc->res_ioport); > >>> > >>> ppc->ppc_flags = device_get_flags(dev); > >>> + if( ppc->ppc_flags == 0 ) { > >>> + int tmp; > >>> + if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp) > >> == 0 ) > >>> + ppc->ppc_flags = tmp; > >>> + } > >>> > >>> if (!(ppc->ppc_flags & 0x20)) { > >>> ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, > >>> > >>> in order to get at least the flags applied as it was the case > >>> before in FreeBSD-7. Unfortuantely, I have no idea how to fix > >>> that properly ;-(... > >> > >> This should not be needed for "flags". Look for 'devflags' in > >> sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during > >> device probe and stores them in dev->devflags and leaves them there after a > >> successful probe (so they should be seen by attach). Specifically, note: > >> > >> /* Set the winning driver, devclass, and flags. */ > > So the flags interface is unusable before some driver "wins". No, we set it twice. Specifically, it is set before each probe, then it is set again after a winning driver is chosen so that the proper flags exist during attach as well. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 18 08:06:00 2013 Return-Path: Delivered-To: freebsd-hardware@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EAAF7F51; Fri, 18 Jan 2013 08:06:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 89E6E32A; Fri, 18 Jan 2013 08:05:56 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0I85r97018316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 19:05:55 +1100 Date: Fri, 18 Jan 2013 19:05:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works In-Reply-To: <201301171337.56851.jhb@freebsd.org> Message-ID: <20130118184242.Q1470@besplex.bde.org> References: <20130110074052.GA8922@bali> <20130116163342.GA30733@bali> <20130117134523.K1345@besplex.bde.org> <201301171337.56851.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zty1sKHG c=1 sm=1 a=_UANyrYDgloA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=D2UiwzQrqZMA:10 a=S3IBTVES4DInHFQ1o40A:9 a=CjuIK1q_8ugA:10 a=qZsCKa-0RAXQNNg1:21 a=ph4GaHcx3gN3oOQx:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 08:06:01 -0000 On Thu, 17 Jan 2013, John Baldwin wrote: > On Wednesday, January 16, 2013 10:10:34 pm Bruce Evans wrote: >> On Wed, 16 Jan 2013, Andre Albsmeier wrote: >> >>> On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote: >>>>> [reading flags in the driver] >>>> This should not be needed for "flags". Look for 'devflags' in >>>> sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during >>>> device probe and stores them in dev->devflags and leaves them there after a >>>> successful probe (so they should be seen by attach). Specifically, note: >>>> >>>> /* Set the winning driver, devclass, and flags. */ >> >> So the flags interface is unusable before some driver "wins". > > No, we set it twice. Specifically, it is set before each probe, then it is > set again after a winning driver is chosen so that the proper flags exist > during attach as well. Why didn't it work for Andre then? It might be a layering problem, with the flags not working because the hint says that they are for ppc but the bus name being puc. I thought that this problem was fixed. In FreeBSD-~5.2, I had to add flags reading to sio_pci.c and sio_puc.c to get flags for sio actually seen by sio when the bus is not isa. subr_bus.c does the 2 settings of the flags much the same in FreeBSD-~5.2, but this certainly doesn't work. Bruce From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 18 17:13:17 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76BE1475 for ; Fri, 18 Jan 2013 17:13:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5455388E for ; Fri, 18 Jan 2013 17:13:17 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B9599B9A4; Fri, 18 Jan 2013 12:13:16 -0500 (EST) From: John Baldwin To: Bruce Evans Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Date: Fri, 18 Jan 2013 11:58:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130110074052.GA8922@bali> <201301171337.56851.jhb@freebsd.org> <20130118184242.Q1470@besplex.bde.org> In-Reply-To: <20130118184242.Q1470@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301181158.50048.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 Jan 2013 12:13:16 -0500 (EST) Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:13:17 -0000 On Friday, January 18, 2013 3:05:53 am Bruce Evans wrote: > On Thu, 17 Jan 2013, John Baldwin wrote: > > > On Wednesday, January 16, 2013 10:10:34 pm Bruce Evans wrote: > >> On Wed, 16 Jan 2013, Andre Albsmeier wrote: > >> > >>> On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote: > > >>>>> [reading flags in the driver] > >>>> This should not be needed for "flags". Look for 'devflags' in > >>>> sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during > >>>> device probe and stores them in dev->devflags and leaves them there after a > >>>> successful probe (so they should be seen by attach). Specifically, note: > >>>> > >>>> /* Set the winning driver, devclass, and flags. */ > >> > >> So the flags interface is unusable before some driver "wins". > > > > No, we set it twice. Specifically, it is set before each probe, then it is > > set again after a winning driver is chosen so that the proper flags exist > > during attach as well. > > Why didn't it work for Andre then? In followup e-mail he said it did work. The one reason it might not have worked before is that if he did 'ppc.0.at=foo' and that forced the ppc device to be ppc1 instead of ppc0 in which case the ppc0 flags wouldn't have applied. > It might be a layering problem, with the flags not working because the > hint says that they are for ppc but the bus name being puc. I thought > that this problem was fixed. In FreeBSD-~5.2, I had to add flags > reading to sio_pci.c and sio_puc.c to get flags for sio actually seen > by sio when the bus is not isa. subr_bus.c does the 2 settings of the > flags much the same in FreeBSD-~5.2, but this certainly doesn't work. I don't know off hand. :( -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Fri Jan 18 17:39:23 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8FC535D1; Fri, 18 Jan 2013 17:39:23 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 29645B3D; Fri, 18 Jan 2013 17:39:22 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r0IHdFtg010370; Fri, 18 Jan 2013 18:39:15 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r0IHdFNd010923; Fri, 18 Jan 2013 18:39:15 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.14.5/8.14.5) id r0IHdFMb070720; Date: Fri, 18 Jan 2013 18:39:14 +0100 From: Andre Albsmeier To: John Baldwin Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Message-ID: <20130118173914.GA93921@bali> References: <20130110074052.GA8922@bali> <201301171337.56851.jhb@freebsd.org> <20130118184242.Q1470@besplex.bde.org> <201301181158.50048.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301181158.50048.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:39:23 -0000 On Fri, 18-Jan-2013 at 17:58:49 +0100, John Baldwin wrote: > On Friday, January 18, 2013 3:05:53 am Bruce Evans wrote: > > On Thu, 17 Jan 2013, John Baldwin wrote: > > > > > On Wednesday, January 16, 2013 10:10:34 pm Bruce Evans wrote: > > >> On Wed, 16 Jan 2013, Andre Albsmeier wrote: > > >> > > >>> On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote: > > > > >>>>> [reading flags in the driver] > > >>>> This should not be needed for "flags". Look for 'devflags' in > > >>>> sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during > > >>>> device probe and stores them in dev->devflags and leaves them there after a > > >>>> successful probe (so they should be seen by attach). Specifically, note: > > >>>> > > >>>> /* Set the winning driver, devclass, and flags. */ > > >> > > >> So the flags interface is unusable before some driver "wins". > > > > > > No, we set it twice. Specifically, it is set before each probe, then it is > > > set again after a winning driver is chosen so that the proper flags exist > > > during attach as well. > > > > Why didn't it work for Andre then? > > In followup e-mail he said it did work. The one reason it might not have > worked before is that if he did 'ppc.0.at=foo' and that forced the ppc device > to be ppc1 instead of ppc0 in which case the ppc0 flags wouldn't have applied. Well, in my despair (before the bug was fixed) I tried also (and only): hint.ppc.1.flags=0x2F but this didn't work as well. If we want to dig into this, I can plug another puc card in my desktop box (the other one is sitting in a server where I don't want to do experiments) and try to reproduce it here... -Andre > > > It might be a layering problem, with the flags not working because the > > hint says that they are for ppc but the bus name being puc. I thought > > that this problem was fixed. In FreeBSD-~5.2, I had to add flags > > reading to sio_pci.c and sio_puc.c to get flags for sio actually seen > > by sio when the bus is not isa. subr_bus.c does the 2 settings of the > > flags much the same in FreeBSD-~5.2, but this certainly doesn't work. > > I don't know off hand. :( > > -- > John Baldwin -- In a world without walls and fences, who needs windows and gates?