From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 11:01:55 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A863316A4CE for ; Mon, 1 Nov 2004 11:01:55 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D90843D2D for ; Mon, 1 Nov 2004 11:01:55 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id iA1B1sUm094136 for ; Mon, 1 Nov 2004 11:01:54 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iA1B1qgw094130 for freebsd-acpi@freebsd.org; Mon, 1 Nov 2004 11:01:52 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Nov 2004 11:01:52 GMT Message-Id: <200411011101.iA1B1qgw094130@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 11:01:55 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/07] kern/53008 acpi [PATCH] genwakecode generates errornously o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2003/09/03] i386/56372 acpi acpi don't work on TYAN tiger100 M/B f [2003/09/10] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 f [2003/12/17] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2004/01/22] i386/61703 acpi ACPI + Sound + Boot = Reboot o [2004/03/17] kern/64365 acpi ACPI problems f [2004/05/25] i386/67189 acpi ACPI S3 reboot computer on Dell Latitude o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) f [2004/06/23] i386/68219 acpi ACPI + snd_maestro3 problem o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 6 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 12:59:26 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3080916A4CE; Mon, 1 Nov 2004 12:59:26 +0000 (GMT) Received: from mail.struchtrup.de (mail.struchtrup.de [80.190.247.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91D6143D31; Mon, 1 Nov 2004 12:59:21 +0000 (GMT) (envelope-from seb@struchtrup.com) Received: from p5087c910.dip0.t-ipconnect.de ([80.135.201.16] helo=notebook.intranet.struchtrup.com) by mail.struchtrup.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1CObmB-00044Y-MT; Mon, 01 Nov 2004 12:59:11 +0000 Received: from seb by notebook.intranet.struchtrup.com with local (Exim 4.43 (FreeBSD)) id 1CObmK-000D37-02; Mon, 01 Nov 2004 13:59:20 +0100 To: FreeBSD-gnats-submit@freebsd.org From: Sebastian Schulze Struchtrup X-send-pr-version: 3.113 X-GNATS-Notify: Message-Id: Date: Mon, 01 Nov 2004 13:59:20 +0100 X-Struchtrup-MailScanner-Information: Please contact the ISP for more information X-Struchtrup-MailScanner: Found to be clean X-MailScanner-From: seb@struchtrup.com cc: acpi@freebsd.org Subject: [patch] kldload acpi_asus.ko causes page fault on Samsung P35 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Sebastian Schulze Struchtrup List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 12:59:26 -0000 >Submitter-Id: current-users >Originator: Sebastian Schulze Struchtrup >Confidential: no >Synopsis: [patch] kldload acpi_asus.ko causes page fault on Samsung P35 >Severity: non-critical >Priority: medium >Category: i386 >Class: sw-bug >Release: FreeBSD 5.3-RC2 i386 >Environment: System: FreeBSD notebook.intranet.struchtrup.com 5.3-RC2 FreeBSD 5.3-RC2 #6: Sun Oct 31 19:22:38 CET 2004 seb@notebook.intranet.struchtrup.com:/usr/obj/usr/src/sys/notebook i386 >Description: The Samsung P30/P35 notebooks have an Asus ATK device. But on ATK Init, they return a null pointer instead of a model identification. This results in a page fault in acpi_asus_probe (strcmp againt null pointer) The linux acpi4asus identifies them by an "ODEM" string as their DSDT Oem Table ID. >Fix: I have modified the acpi_asus_probe function to identify the notebook via the "ODEM" string. We have to see if this will work in the future or if there are other notebooks with the same string which require different handling. At least the linux acpi4asus seems to work without problems with this approach. Addionally, I have splitted the acpi_asus_models struct and added an extra struct acpi_asus_extra_models. The first contains the models which are identified by their model identification (inside the for loop), the second one contains models identified in another way (currently, only the Samsung P30/35). The enum acpi_asus_extra_models_idx holds their indices. I have also introduced a longname attribute in both tables, which contains the full name including Manufacturer. This is only used for correctly setting/printing driver information. Switching WLAN on/off and reporting events to devd with various special keys and Fn-key combinations works fine. This patch should not break anything, but I was not able to test it with a real Asus notebook. Someone should do this before committing From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 13:14:45 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4AA716A4D0; Mon, 1 Nov 2004 13:14:45 +0000 (GMT) Received: from mail.struchtrup.de (mail.struchtrup.de [80.190.247.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1BF343D49; Mon, 1 Nov 2004 13:14:44 +0000 (GMT) (envelope-from sebastian@struchtrup.de) Received: from p5087c910.dip0.t-ipconnect.de ([80.135.201.16] helo=[10.0.0.198]) by mail.struchtrup.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1COc13-00046Q-OF; Mon, 01 Nov 2004 13:14:34 +0000 Message-ID: <418636C1.8000801@struchtrup.de> Date: Mon, 01 Nov 2004 14:14:41 +0100 From: Sebastian Schulze Struchtrup User-Agent: Mozilla Thunderbird 0.8 (X11/20041027) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastian Schulze Struchtrup References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------050207030109020209080808" X-Struchtrup-MailScanner-Information: Please contact the ISP for more information X-Struchtrup-MailScanner: Found to be clean X-MailScanner-From: sebastian@struchtrup.de cc: acpi@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: i386/73380: [patch] kldload acpi_asus.ko causes page fault on Samsung P35 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 13:14:45 -0000 This is a multi-part message in MIME format. --------------050207030109020209080808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well, the patch got lost. Here it is. --------------050207030109020209080808 Content-Type: text/plain; name="acpi_asus.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_asus.c.patch" Index: acpi_asus.c =================================================================== RCS file: /home/ncvs/src/sys/i386/acpica/acpi_asus.c,v retrieving revision 1.11 diff -u -p -r1.11 acpi_asus.c --- acpi_asus.c 13 Aug 2004 06:22:29 -0000 1.11 +++ acpi_asus.c 1 Nov 2004 12:48:17 -0000 @@ -26,7 +26,7 @@ */ #include -__FBSDID("$FreeBSD$"); +__FBSDID("$FreeBSD: src/sys/i386/acpica/acpi_asus.c,v 1.11 2004/08/13 06:22:29 njl Exp $"); /* * Driver for extra ACPI-controlled gadgets (hotkeys, leds, etc) found on @@ -58,7 +58,7 @@ ACPI_MODULE_NAME("ASUS") struct acpi_asus_model { char *name; - + char *longname; char *mled_set; char *tled_set; char *wled_set; @@ -103,9 +103,11 @@ struct acpi_asus_softc { }; /* Models we know about */ +/* These are identified by name returned on ATK INIT */ static struct acpi_asus_model acpi_asus_models[] = { { .name = "L2D", + .longname = "Asus L2D", .mled_set = "MLED", .wled_set = "WLED", .brn_up = "\\Q0E", @@ -115,6 +117,7 @@ static struct acpi_asus_model acpi_asus_ }, { .name = "L3C", + .longname = "Asus L3C", .mled_set = "MLED", .wled_set = "WLED", .brn_get = "GPLV", @@ -124,6 +127,7 @@ static struct acpi_asus_model acpi_asus_ }, { .name = "L3D", + .longname = "Asus L3D", .mled_set = "MLED", .wled_set = "WLED", .brn_get = "GPLV", @@ -133,6 +137,7 @@ static struct acpi_asus_model acpi_asus_ }, { .name = "L3H", + .longname = "Asus L3H", .mled_set = "MLED", .wled_set = "WLED", .brn_get = "GPLV", @@ -143,11 +148,13 @@ static struct acpi_asus_model acpi_asus_ .disp_set = "SDSP" }, { - .name = "L8L" + .name = "L8L", + .longname = "Asus L8L" /* Only has hotkeys, apparantly */ }, { .name = "M1A", + .longname = "Asus M1A", .mled_set = "MLED", .brn_up = "\\_SB.PCI0.PX40.EC0.Q0E", .brn_dn = "\\_SB.PCI0.PX40.EC0.Q0F", @@ -156,6 +163,7 @@ static struct acpi_asus_model acpi_asus_ }, { .name = "M2E", + .longname = "Asus M2E", .mled_set = "MLED", .wled_set = "WLED", .brn_get = "GPLV", @@ -163,18 +171,33 @@ static struct acpi_asus_model acpi_asus_ .lcd_get = "\\GP06", .lcd_set = "\\Q10" }, + + { .name = NULL } +}; + +/* This notebook are also supported, but cannon be identified by + * their name because ATK INIT does not return their name + * update the following enum when updating this table */ + +static struct acpi_asus_model acpi_asus_extra_models[] = { { .name = "P30", + .longname = "Samsung P30/P35", .wled_set = "WLED", .brn_up = "\\_SB.PCI0.LPCB.EC0._Q68", .brn_dn = "\\_SB.PCI0.LPCB.EC0._Q69", .lcd_get = "\\BKLT", .lcd_set = "\\_SB.PCI0.LPCB.EC0._Q0E" }, +}; - { .name = NULL } +/* must be in sync with acpi_asus_extra_models above */ +enum acpi_asus_extra_models_idx +{ + SAMSUNG_P30 = 0 }; + ACPI_SERIAL_DECL(asus, "ACPI ASUS extras"); /* Function prototypes */ @@ -218,6 +241,10 @@ acpi_asus_probe(device_t dev) ACPI_BUFFER Buf; ACPI_OBJECT Arg, *Obj; ACPI_OBJECT_LIST Args; + ACPI_TABLE_HEADER dsdt_header; + ACPI_STATUS status; + int has_dsdt; + static char *asus_ids[] = { "ATK0100", NULL }; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -233,6 +260,17 @@ acpi_asus_probe(device_t dev) if (sb == NULL) return (ENOMEM); + /* Get DSDT Header (copy the header into our dsdt_header struct) */ + status = AcpiGetTableHeader(ACPI_TABLE_DSDT, 1, &dsdt_header); + if (ACPI_FAILURE(status)) + { + device_printf(dev, "unable to load DSDT\n"); + has_dsdt = 0; + } + else + has_dsdt = 1; + + /* Call ATK INIT */ Arg.Type = ACPI_TYPE_INTEGER; Arg.Integer.Value = 0; @@ -243,33 +281,54 @@ acpi_asus_probe(device_t dev) Buf.Length = ACPI_ALLOCATE_BUFFER; AcpiEvaluateObject(sc->handle, "INIT", &Args, &Buf); - Obj = Buf.Pointer; - - for (model = acpi_asus_models; model->name != NULL; model++) - if (strcmp(Obj->String.Pointer, model->name) == 0) { - sbuf_printf(sb, "Asus %s Laptop Extras", - Obj->String.Pointer); - sbuf_finish(sb); - - sc->model = model; - device_set_desc(dev, sbuf_data(sb)); - - sbuf_delete(sb); - AcpiOsFree(Buf.Pointer); - return (0); + + sc->model = NULL; + if ((Obj != NULL) && (Obj->String.Pointer != NULL)) + { + /* got name, loop over known models */ + for (model = acpi_asus_models; model->name != NULL; model++) + if (strcmp(Obj->String.Pointer, model->name) == 0) { + sc->model = model; + } + + if (sc->model == NULL) { + sbuf_printf(sb, "Unsupported Asus laptop detected: %s\n", + Obj->String.Pointer); + } + AcpiOsFree(Buf.Pointer); + } + else + { + /* some notebooks don't return anything on INIT (NULL) + The Samsung P30/P35 are known to do this. + */ + if ((has_dsdt) && (strncmp("ODEM", dsdt_header.OemTableId, 4)==0)) { + sc->model = &acpi_asus_extra_models[SAMSUNG_P30]; + sbuf_printf(sb, "Missing model name: " + "Identified as Samsung P30/P35\n"); } + else + { + sbuf_printf(sb, "Your notebook supports the asus ATK device," + " but can't be identified\n"); + } + } - sbuf_printf(sb, "Unsupported Asus laptop detected: %s\n", - Obj->String.Pointer); sbuf_finish(sb); - device_printf(dev, sbuf_data(sb)); - - sbuf_delete(sb); - AcpiOsFree(Buf.Pointer); + + if (sc->model != NULL) + { + sbuf_clear(sb); + sbuf_printf(sb, "%s Laptop Extras", sc->model->longname); + sbuf_finish(sb); + device_set_desc(dev, sbuf_data(sb)); + sbuf_delete(sb); + return(0); + } } - + /* either not identified or disabled */ return (ENXIO); } --------------050207030109020209080808-- From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 22:18:22 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2876516A4CE for ; Mon, 1 Nov 2004 22:18:22 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4C0943D2F for ; Mon, 1 Nov 2004 22:18:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 15043 invoked from network); 1 Nov 2004 22:18:21 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Nov 2004 22:18:21 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA1MIBOC062933; Mon, 1 Nov 2004 17:18:16 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Mon, 1 Nov 2004 17:48:25 -0500 User-Agent: KMail/1.6.2 References: <20041005203251.325D95D04@ptavv.es.net> <200410061320.44673.jhb@FreeBSD.org> In-Reply-To: <200410061320.44673.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411011748.25052.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 22:18:22 -0000 On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > From: John Baldwin > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > From: John Baldwin > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > Kevin Oberman wrote: > > > > > > > It looks like interrupts from the Ethernet are not delivered > > > > > > > without ACPI, but that is hardly your problem. I have > > > > > > > over-ridden the black-list and things are back to normal. > > > > > > > > > > > > The reason this system works in Windows without ACPI is that irq > > > > > > routing in Windows uses multiple info sources including _PIR and > > > > > > $PIR. John Baldwin has patches to do this for us too. > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite a > > > > > while. The patches I have are to make the acpi_pci_link code work > > > > > more like the $PIR code already does. It doesn't change the ACPI > > > > > code to actually use $PIR or the MPTable though. I can try to look > > > > > at why the ethernet device doesn't get interrupts correctly if you > > > > > can provide verbose ACPI and non-ACPI dmesgs to look at. > > > > > > > > I am attaching the files. I do see some oddities with the > > > > interrupts that I had not previously noted, but they seen to be > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates it > > > > should be on IRQ 6. interrupt total > > > > rate > > > > irq0: clk 4242251 99 > > > > irq1: atkbd0 3 0 > > > > irq7: ppc0 1 0 > > > > irq8: rtc 5430044 127 > > > > irq10: xl0 13699 0 > > > > irq13: npx0 1 0 > > > > irq14: ata0 166980 3 > > > > irq15: ata1 136 0 > > > > Total 9853115 232 > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an option > > > for your link devices but ACPI does. In the non-APCI case we use IRQ > > > 10 for both xl0 and pcm0. Are you saying that in that case pcm0 works > > > but xl0 does not? > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > first tone in the file plays continuously, like there are no interrupts > > from the sound card. :-) > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of the > box, you can try setting a hint to force the link for your sound card to > use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or maybe > 'hw.pci.link.0x04.irq' if that doesn't work. Actually, the $PIR code won't let you use an invalid IRQ currently, but this patch lets it do so. I'm curious if you could try booting with this patch with ACPI disabled and using an appropriate tunable (such as 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them routed. If this does work, I'd like to try another patch as well that would help it to work out-of-the-box for the non-ACPI case. Thanks. --- //depot/vendor/freebsd/src/sys/i386/pci/pci_pir.c 2004/07/01 07:50:36 +++ //depot/user/jhb/acpipci/i386/pci/pci_pir.c 2004/10/20 17:47:41 @@ -386,9 +386,9 @@ } /* - * Allow the user to override the IRQ for a given link device as - * long as the override is valid or is 255 or 0 to clear a preset - * IRQ. + * Allow the user to override the IRQ for a given link device. We + * allow invalid IRQs to be specified but warn about them. An IRQ + * of 255 or 0 clears any preset IRQ. */ i = 0; TAILQ_FOREACH(pci_link, &pci_links, pl_links) { @@ -398,12 +398,14 @@ continue; if (irq == 0) irq = PCI_INVALID_IRQ; - if (irq == PCI_INVALID_IRQ || - pci_pir_valid_irq(pci_link, irq)) { - pci_link->pl_routed = 0; - pci_link->pl_irq = irq; - i = 1; - } + if (irq != PCI_INVALID_IRQ && + !pci_pir_valid_irq(pci_link, irq) && bootverbose) + printf( + "$PIR: Warning, IRQ %d for link %#x is not listed as valid\n", + irq, pci_link->pl_id); + pci_link->pl_routed = 0; + pci_link->pl_irq = irq; + i = 1; } if (bootverbose && i) { printf("$PIR: Links after tunable overrides:\n"); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 22:18:23 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54CDA16A4CE for ; Mon, 1 Nov 2004 22:18:23 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E03243D2F for ; Mon, 1 Nov 2004 22:18:23 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 15043 invoked from network); 1 Nov 2004 22:18:21 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Nov 2004 22:18:21 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA1MIBOC062933; Mon, 1 Nov 2004 17:18:16 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Mon, 1 Nov 2004 17:48:25 -0500 User-Agent: KMail/1.6.2 References: <20041005203251.325D95D04@ptavv.es.net> <200410061320.44673.jhb@FreeBSD.org> In-Reply-To: <200410061320.44673.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411011748.25052.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 22:18:23 -0000 On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > From: John Baldwin > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > From: John Baldwin > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > Kevin Oberman wrote: > > > > > > > It looks like interrupts from the Ethernet are not delivered > > > > > > > without ACPI, but that is hardly your problem. I have > > > > > > > over-ridden the black-list and things are back to normal. > > > > > > > > > > > > The reason this system works in Windows without ACPI is that irq > > > > > > routing in Windows uses multiple info sources including _PIR and > > > > > > $PIR. John Baldwin has patches to do this for us too. > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite a > > > > > while. The patches I have are to make the acpi_pci_link code work > > > > > more like the $PIR code already does. It doesn't change the ACPI > > > > > code to actually use $PIR or the MPTable though. I can try to look > > > > > at why the ethernet device doesn't get interrupts correctly if you > > > > > can provide verbose ACPI and non-ACPI dmesgs to look at. > > > > > > > > I am attaching the files. I do see some oddities with the > > > > interrupts that I had not previously noted, but they seen to be > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates it > > > > should be on IRQ 6. interrupt total > > > > rate > > > > irq0: clk 4242251 99 > > > > irq1: atkbd0 3 0 > > > > irq7: ppc0 1 0 > > > > irq8: rtc 5430044 127 > > > > irq10: xl0 13699 0 > > > > irq13: npx0 1 0 > > > > irq14: ata0 166980 3 > > > > irq15: ata1 136 0 > > > > Total 9853115 232 > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an option > > > for your link devices but ACPI does. In the non-APCI case we use IRQ > > > 10 for both xl0 and pcm0. Are you saying that in that case pcm0 works > > > but xl0 does not? > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > first tone in the file plays continuously, like there are no interrupts > > from the sound card. :-) > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of the > box, you can try setting a hint to force the link for your sound card to > use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or maybe > 'hw.pci.link.0x04.irq' if that doesn't work. Actually, the $PIR code won't let you use an invalid IRQ currently, but this patch lets it do so. I'm curious if you could try booting with this patch with ACPI disabled and using an appropriate tunable (such as 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them routed. If this does work, I'd like to try another patch as well that would help it to work out-of-the-box for the non-ACPI case. Thanks. --- //depot/vendor/freebsd/src/sys/i386/pci/pci_pir.c 2004/07/01 07:50:36 +++ //depot/user/jhb/acpipci/i386/pci/pci_pir.c 2004/10/20 17:47:41 @@ -386,9 +386,9 @@ } /* - * Allow the user to override the IRQ for a given link device as - * long as the override is valid or is 255 or 0 to clear a preset - * IRQ. + * Allow the user to override the IRQ for a given link device. We + * allow invalid IRQs to be specified but warn about them. An IRQ + * of 255 or 0 clears any preset IRQ. */ i = 0; TAILQ_FOREACH(pci_link, &pci_links, pl_links) { @@ -398,12 +398,14 @@ continue; if (irq == 0) irq = PCI_INVALID_IRQ; - if (irq == PCI_INVALID_IRQ || - pci_pir_valid_irq(pci_link, irq)) { - pci_link->pl_routed = 0; - pci_link->pl_irq = irq; - i = 1; - } + if (irq != PCI_INVALID_IRQ && + !pci_pir_valid_irq(pci_link, irq) && bootverbose) + printf( + "$PIR: Warning, IRQ %d for link %#x is not listed as valid\n", + irq, pci_link->pl_id); + pci_link->pl_routed = 0; + pci_link->pl_irq = irq; + i = 1; } if (bootverbose && i) { printf("$PIR: Links after tunable overrides:\n"); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 23:05:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33FA016A566; Mon, 1 Nov 2004 23:05:04 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00AB843D1D; Mon, 1 Nov 2004 23:05:04 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP id IBA74465; Mon, 01 Nov 2004 15:05:03 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6BFCC5D09; Mon, 1 Nov 2004 15:05:03 -0800 (PST) To: John Baldwin In-reply-to: Your message of "Mon, 01 Nov 2004 17:48:25 EST." <200411011748.25052.jhb@FreeBSD.org> Date: Mon, 01 Nov 2004 15:05:03 -0800 From: "Kevin Oberman" Message-Id: <20041101230503.6BFCC5D09@ptavv.es.net> cc: acpi@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 23:05:04 -0000 > From: John Baldwin > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > From: John Baldwin > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > From: John Baldwin > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > Kevin Oberman wrote: > > > > > > > > It looks like interrupts from the Ethernet are not delivered > > > > > > > > without ACPI, but that is hardly your problem. I have > > > > > > > > over-ridden the black-list and things are back to normal. > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that irq > > > > > > > routing in Windows uses multiple info sources including _PIR and > > > > > > > $PIR. John Baldwin has patches to do this for us too. > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite a > > > > > > while. The patches I have are to make the acpi_pci_link code work > > > > > > more like the $PIR code already does. It doesn't change the ACPI > > > > > > code to actually use $PIR or the MPTable though. I can try to look > > > > > > at why the ethernet device doesn't get interrupts correctly if you > > > > > > can provide verbose ACPI and non-ACPI dmesgs to look at. > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > interrupts that I had not previously noted, but they seen to be > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates it > > > > > should be on IRQ 6. interrupt total > > > > > rate > > > > > irq0: clk 4242251 99 > > > > > irq1: atkbd0 3 0 > > > > > irq7: ppc0 1 0 > > > > > irq8: rtc 5430044 127 > > > > > irq10: xl0 13699 0 > > > > > irq13: npx0 1 0 > > > > > irq14: ata0 166980 3 > > > > > irq15: ata1 136 0 > > > > > Total 9853115 232 > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an option > > > > for your link devices but ACPI does. In the non-APCI case we use IRQ > > > > 10 for both xl0 and pcm0. Are you saying that in that case pcm0 works > > > > but xl0 does not? > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > first tone in the file plays continuously, like there are no interrupts > > > from the sound card. :-) > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of the > > box, you can try setting a hint to force the link for your sound card to > > use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or maybe > > 'hw.pci.link.0x04.irq' if that doesn't work. > > Actually, the $PIR code won't let you use an invalid IRQ currently, but this > patch lets it do so. I'm curious if you could try booting with this patch > with ACPI disabled and using an appropriate tunable (such as > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them routed. > If this does work, I'd like to try another patch as well that would help it > to work out-of-the-box for the non-ACPI case. Thanks. John, I just did the patch and the kernel is rebuilding, but I am in Pittsburgh for SuperComputing conference next week and will not be back home (where the ASUS is) until Nov. 13. I will ask my wife to be available to re-boot the old kernel if it fails, but that won't be until tonight. I should have some feedback on this by tomorrow, but if I get busy with SCinet (which is what I'm being paid to do), my response may be delayed. Thanks for looking at this issue. It's beyond my area of knowledge. In fact, all of the $PIR stuff is. Hard IRQs are brain dead, but easier for me to understand. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 23:05:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33FA016A566; Mon, 1 Nov 2004 23:05:04 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00AB843D1D; Mon, 1 Nov 2004 23:05:04 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP id IBA74465; Mon, 01 Nov 2004 15:05:03 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6BFCC5D09; Mon, 1 Nov 2004 15:05:03 -0800 (PST) To: John Baldwin In-reply-to: Your message of "Mon, 01 Nov 2004 17:48:25 EST." <200411011748.25052.jhb@FreeBSD.org> Date: Mon, 01 Nov 2004 15:05:03 -0800 From: "Kevin Oberman" Message-Id: <20041101230503.6BFCC5D09@ptavv.es.net> cc: acpi@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 23:05:04 -0000 > From: John Baldwin > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > From: John Baldwin > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > From: John Baldwin > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > Kevin Oberman wrote: > > > > > > > > It looks like interrupts from the Ethernet are not delivered > > > > > > > > without ACPI, but that is hardly your problem. I have > > > > > > > > over-ridden the black-list and things are back to normal. > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that irq > > > > > > > routing in Windows uses multiple info sources including _PIR and > > > > > > > $PIR. John Baldwin has patches to do this for us too. > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite a > > > > > > while. The patches I have are to make the acpi_pci_link code work > > > > > > more like the $PIR code already does. It doesn't change the ACPI > > > > > > code to actually use $PIR or the MPTable though. I can try to look > > > > > > at why the ethernet device doesn't get interrupts correctly if you > > > > > > can provide verbose ACPI and non-ACPI dmesgs to look at. > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > interrupts that I had not previously noted, but they seen to be > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates it > > > > > should be on IRQ 6. interrupt total > > > > > rate > > > > > irq0: clk 4242251 99 > > > > > irq1: atkbd0 3 0 > > > > > irq7: ppc0 1 0 > > > > > irq8: rtc 5430044 127 > > > > > irq10: xl0 13699 0 > > > > > irq13: npx0 1 0 > > > > > irq14: ata0 166980 3 > > > > > irq15: ata1 136 0 > > > > > Total 9853115 232 > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an option > > > > for your link devices but ACPI does. In the non-APCI case we use IRQ > > > > 10 for both xl0 and pcm0. Are you saying that in that case pcm0 works > > > > but xl0 does not? > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > first tone in the file plays continuously, like there are no interrupts > > > from the sound card. :-) > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of the > > box, you can try setting a hint to force the link for your sound card to > > use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or maybe > > 'hw.pci.link.0x04.irq' if that doesn't work. > > Actually, the $PIR code won't let you use an invalid IRQ currently, but this > patch lets it do so. I'm curious if you could try booting with this patch > with ACPI disabled and using an appropriate tunable (such as > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them routed. > If this does work, I'd like to try another patch as well that would help it > to work out-of-the-box for the non-ACPI case. Thanks. John, I just did the patch and the kernel is rebuilding, but I am in Pittsburgh for SuperComputing conference next week and will not be back home (where the ASUS is) until Nov. 13. I will ask my wife to be available to re-boot the old kernel if it fails, but that won't be until tonight. I should have some feedback on this by tomorrow, but if I get busy with SCinet (which is what I'm being paid to do), my response may be delayed. Thanks for looking at this issue. It's beyond my area of knowledge. In fact, all of the $PIR stuff is. Hard IRQs are brain dead, but easier for me to understand. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 14:15:24 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2AB416A4CE for ; Tue, 2 Nov 2004 14:15:24 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 311AF43D31 for ; Tue, 2 Nov 2004 14:15:24 +0000 (GMT) (envelope-from philip@nixsys.be) Received: from loge.nixsys.be (loge.nixsys.be [195.144.77.45]) by gateway.nixsys.be (Postfix) with ESMTP id E732D1B6 for ; Tue, 2 Nov 2004 15:15:22 +0100 (CET) Received: from loge.nixsys.be (smmsp@localhost [127.0.0.1]) by loge.nixsys.be (8.13.1/8.13.1) with ESMTP id iA2EFO6u015889; Tue, 2 Nov 2004 15:15:25 +0100 (CET) (envelope-from philip@loge.nixsys.be) Received: (from philip@localhost) by loge.nixsys.be (8.13.1/8.13.1/Submit) id iA2D2t2a001011; Tue, 2 Nov 2004 14:02:55 +0100 (CET) (envelope-from philip) Date: Tue, 2 Nov 2004 14:02:55 +0100 From: Philip Paeps To: Andreas Dieling Message-ID: <20041102130255.GA953@loge.nixsys.be> Mail-Followup-To: Andreas Dieling , freebsd-acpi@freebsd.org References: <200410281706.43210.snow@quantentunnel.de> <200410281710.40758.snow@quantentunnel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410281710.40758.snow@quantentunnel.de> X-Date-in-Rome: ante diem IV Nonas Novembres MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! Organization: Happily Disorganized User-Agent: Mutt/1.5.6i cc: freebsd-acpi@freebsd.org Subject: Re: Asus M6N X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 14:15:24 -0000 On 2004-10-28 17:10:40 (+0200), Andreas Dieling wrote: > my changes to acpi_asus.c: Commited, thanks! - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. If you are already in a hole, there's no use to continue digging. From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 11:32:59 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06FE516A4CE; Thu, 4 Nov 2004 11:32:59 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F62143D31; Thu, 4 Nov 2004 11:32:58 +0000 (GMT) (envelope-from philip@paeps.cx) Received: from erda.home.paeps.cx (erda.home.paeps.cx [IPv6:2001:838:37f:10::1]) by gateway.nixsys.be (Postfix) with ESMTP id 5CF705D; Thu, 4 Nov 2004 12:32:56 +0100 (CET) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [10.0.0.2]) by erda.home.paeps.cx (Postfix) with ESMTP id 620D02103; Thu, 4 Nov 2004 12:27:43 +0100 (CET) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) by fasolt.home.paeps.cx (8.13.1/8.13.1) with ESMTP id iA4BRwT7031642; Thu, 4 Nov 2004 12:27:58 +0100 (CET) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.13.1/8.13.1/Submit) id iA4BRvVc031641; Thu, 4 Nov 2004 12:27:57 +0100 (CET) (envelope-from philip) Date: Thu, 4 Nov 2004 12:27:57 +0100 From: Philip Paeps To: Sebastian Schulze Struchtrup Message-ID: <20041104112757.GA31494@fasolt.home.paeps.cx> Mail-Followup-To: Sebastian Schulze Struchtrup , Sebastian Schulze Struchtrup , FreeBSD-gnats-submit@freebsd.org, acpi@freebsd.org References: <418636C1.8000801@struchtrup.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <418636C1.8000801@struchtrup.de> X-Date-in-Rome: pridie Nonas Novembres MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! Organization: Happily Disorganized User-Agent: Mutt/1.5.6i cc: acpi@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: i386/73380: [patch] kldload acpi_asus.ko causes page fault on Samsung P35 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 11:32:59 -0000 On 2004-11-01 14:14:41 (+0100), Sebastian Schulze Struchtrup wrote: > Well, the patch got lost. > Here it is. Does this patch work for you? I think it's a bit simpler than yours, and it should accomplish the same thing. It also doesn't break style(9) quite so dramatically ;-) Index: acpi_asus.c =================================================================== RCS file: /home/freebsd/FreeBSD-CVS/src/sys/i386/acpica/acpi_asus.c,v retrieving revision 1.12 diff -u -r1.12 acpi_asus.c --- acpi_asus.c 2 Nov 2004 13:02:22 -0000 1.12 +++ acpi_asus.c 4 Nov 2004 09:14:47 -0000 @@ -102,7 +102,10 @@ int s_lcd; }; -/* Models we know about */ +/* + * We can identify Asus laptops from the string they return + * as a result of calling the ATK0100 'INIT' method. + */ static struct acpi_asus_model acpi_asus_models[] = { { .name = "L2D", @@ -174,6 +177,15 @@ .disp_set = "SDSP", .disp_get = "\\SSTE" }, + + { .name = NULL } +}; + +/* + * Samsung P30/P35 laptops have an Asus ATK0100 gadget interface, + * but they can't be probed quite the same way as Asus laptops. + */ +static struct acpi_asus_model acpi_samsung_models[] = { { .name = "P30", .wled_set = "WLED", @@ -254,13 +266,48 @@ Buf.Length = ACPI_ALLOCATE_BUFFER; AcpiEvaluateObject(sc->handle, "INIT", &Args, &Buf); - Obj = Buf.Pointer; + /* + * The Samsung P30 returns a null-pointer from INIT, we + * can identify it from the 'ODEM' string in the DSDT. + */ + if (Obj == NULL) { + ACPI_STATUS status; + ACPI_TABLE_HEADER th; + + status = AcpiGetTableHeader(ACPI_TABLE_DSDT, 1, &th); + if (ACPI_FAILURE(status)) { + sbuf_printf(sb, "Unsupported laptop\n"); + sbuf_finish(sb); + + device_printf(dev, sbuf_data(sb)); + + sbuf_delete(sb); + AcpiOsFree(Buf.Pointer); + return (ENXIO); + } + + if (strncmp("ODEM", th.OemTableId, 4) == 0) { + sbuf_printf(sb, "Samsung P30 Laptop Extras"); + sbuf_finish(sb); + + sc->model = &acpi_samsung_models[0]; + device_set_desc(dev, sbuf_data(sb)); + + sbuf_delete(sb); + AcpiOsFree(Buf.Pointer); + return (0); + } + } + + /* + * Asus laptops are simply identified by name, easy! + */ for (model = acpi_asus_models; model->name != NULL; model++) if (strcmp(Obj->String.Pointer, model->name) == 0) { sbuf_printf(sb, "Asus %s Laptop Extras", - Obj->String.Pointer); + Obj->String.Pointer); sbuf_finish(sb); sc->model = model; @@ -272,7 +319,7 @@ } sbuf_printf(sb, "Unsupported Asus laptop detected: %s\n", - Obj->String.Pointer); + Obj->String.Pointer); sbuf_finish(sb); device_printf(dev, sbuf_data(sb)); - Philip -- Philip Paeps Made from non-edible parts philip@freebsd.org BOFH Excuse #228: That function is not currently supported, but Bill Gates assures us it will be featured in the next upgrade. From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 13:18:48 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4117116A4CE; Thu, 4 Nov 2004 13:18:48 +0000 (GMT) Received: from mail.struchtrup.de (mail.struchtrup.de [80.190.247.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545B943D45; Thu, 4 Nov 2004 13:18:44 +0000 (GMT) (envelope-from sebastian@struchtrup.de) Received: from p5087c351.dip0.t-ipconnect.de ([80.135.195.81] helo=[10.0.0.198]) by mail.struchtrup.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1CPhV8-000DZW-Ul; Thu, 04 Nov 2004 13:18:07 +0000 Message-ID: <418A2C34.1090103@struchtrup.de> Date: Thu, 04 Nov 2004 14:18:44 +0100 From: Sebastian Schulze Struchtrup User-Agent: Mozilla Thunderbird 0.8 (X11/20041027) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Paeps References: <418636C1.8000801@struchtrup.de> <20041104112757.GA31494@fasolt.home.paeps.cx> In-Reply-To: <20041104112757.GA31494@fasolt.home.paeps.cx> Content-Type: multipart/mixed; boundary="------------020603070606090906090205" X-Struchtrup-MailScanner-Information: Please contact the ISP for more information X-Struchtrup-MailScanner: Found to be clean X-MailScanner-From: sebastian@struchtrup.de cc: acpi@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: i386/73380: [patch] kldload acpi_asus.ko causes page fault on Samsung P35 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 13:18:48 -0000 This is a multi-part message in MIME format. --------------020603070606090906090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Philip Paeps wrote: >On 2004-11-01 14:14:41 (+0100), Sebastian Schulze Struchtrup wrote: > > >>Well, the patch got lost. >>Here it is. >> >> > >Does this patch work for you? I think it's a bit simpler than yours, and it >should accomplish the same thing. It also doesn't break style(9) quite so >dramatically ;-) > > Not yet. It is rather Obj->String.Pointer which is NULL, not Obj itself. After changing this, it works. I think I have had both checks in my patch, with the one being redundant. Thanks for handling this! The corrected patch is attached. --------------020603070606090906090205 Content-Type: text/plain; name="acpi_asus.c.patch-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_asus.c.patch-2" Index: acpi_asus.c =================================================================== RCS file: /home/ncvs/src/sys/i386/acpica/acpi_asus.c,v retrieving revision 1.12 diff -u -p -r1.12 acpi_asus.c --- acpi_asus.c 2 Nov 2004 13:02:22 -0000 1.12 +++ acpi_asus.c 4 Nov 2004 13:13:29 -0000 @@ -102,7 +102,10 @@ struct acpi_asus_softc { int s_lcd; }; -/* Models we know about */ +/* + * We can identify Asus laptops from the string they return + * as a result of calling the ATK0100 'INIT' method. + */ static struct acpi_asus_model acpi_asus_models[] = { { .name = "L2D", @@ -174,6 +177,15 @@ static struct acpi_asus_model acpi_asus_ .disp_set = "SDSP", .disp_get = "\\SSTE" }, + + { .name = NULL } +}; + +/* + * Samsung P30/P35 laptops have an Asus ATK0100 gadget interface, + * but they can't be probed quite the same way as Asus laptops. + */ +static struct acpi_asus_model acpi_samsung_models[] = { { .name = "P30", .wled_set = "WLED", @@ -254,13 +266,48 @@ acpi_asus_probe(device_t dev) Buf.Length = ACPI_ALLOCATE_BUFFER; AcpiEvaluateObject(sc->handle, "INIT", &Args, &Buf); - Obj = Buf.Pointer; + /* + * The Samsung P30 returns a null-pointer from INIT, we + * can identify it from the 'ODEM' string in the DSDT. + */ + if (Obj->String.Pointer == NULL) { + ACPI_STATUS status; + ACPI_TABLE_HEADER th; + + status = AcpiGetTableHeader(ACPI_TABLE_DSDT, 1, &th); + if (ACPI_FAILURE(status)) { + sbuf_printf(sb, "Unsupported laptop\n"); + sbuf_finish(sb); + + device_printf(dev, sbuf_data(sb)); + + sbuf_delete(sb); + AcpiOsFree(Buf.Pointer); + return (ENXIO); + } + + if (strncmp("ODEM", th.OemTableId, 4) == 0) { + sbuf_printf(sb, "Samsung P30 Laptop Extras"); + sbuf_finish(sb); + + sc->model = &acpi_samsung_models[0]; + device_set_desc(dev, sbuf_data(sb)); + + sbuf_delete(sb); + AcpiOsFree(Buf.Pointer); + return (0); + } + } + + /* + * Asus laptops are simply identified by name, easy! + */ for (model = acpi_asus_models; model->name != NULL; model++) if (strcmp(Obj->String.Pointer, model->name) == 0) { sbuf_printf(sb, "Asus %s Laptop Extras", - Obj->String.Pointer); + Obj->String.Pointer); sbuf_finish(sb); sc->model = model; @@ -272,7 +319,7 @@ acpi_asus_probe(device_t dev) } sbuf_printf(sb, "Unsupported Asus laptop detected: %s\n", - Obj->String.Pointer); + Obj->String.Pointer); sbuf_finish(sb); device_printf(dev, sbuf_data(sb)); --------------020603070606090906090205-- From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 22:23:52 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBCD416A4CE; Thu, 4 Nov 2004 22:23:52 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5679A43D3F; Thu, 4 Nov 2004 22:23:52 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP id IBA74465; Thu, 04 Nov 2004 14:23:52 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CA4B55D04; Thu, 4 Nov 2004 14:23:51 -0800 (PST) To: John Baldwin In-reply-to: Your message of "Mon, 01 Nov 2004 17:48:25 EST." <200411011748.25052.jhb@FreeBSD.org> Date: Thu, 04 Nov 2004 14:23:51 -0800 From: "Kevin Oberman" Message-Id: <20041104222351.CA4B55D04@ptavv.es.net> cc: acpi@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:23:53 -0000 > From: John Baldwin > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > From: John Baldwin > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > From: John Baldwin > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > Kevin Oberman wrote: > > > > > > > > It looks like interrupts from the Ethernet are not delivered > > > > > > > > without ACPI, but that is hardly your problem. I have > > > > > > > > over-ridden the black-list and things are back to normal. > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that irq > > > > > > > routing in Windows uses multiple info sources including _PIR and > > > > > > > $PIR. John Baldwin has patches to do this for us too. > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite a > > > > > > while. The patches I have are to make the acpi_pci_link code work > > > > > > more like the $PIR code already does. It doesn't change the ACPI > > > > > > code to actually use $PIR or the MPTable though. I can try to look > > > > > > at why the ethernet device doesn't get interrupts correctly if you > > > > > > can provide verbose ACPI and non-ACPI dmesgs to look at. > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > interrupts that I had not previously noted, but they seen to be > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates it > > > > > should be on IRQ 6. interrupt total > > > > > rate > > > > > irq0: clk 4242251 99 > > > > > irq1: atkbd0 3 0 > > > > > irq7: ppc0 1 0 > > > > > irq8: rtc 5430044 127 > > > > > irq10: xl0 13699 0 > > > > > irq13: npx0 1 0 > > > > > irq14: ata0 166980 3 > > > > > irq15: ata1 136 0 > > > > > Total 9853115 232 > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an option > > > > for your link devices but ACPI does. In the non-APCI case we use IRQ > > > > 10 for both xl0 and pcm0. Are you saying that in that case pcm0 works > > > > but xl0 does not? > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > first tone in the file plays continuously, like there are no interrupts > > > from the sound card. :-) > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of the > > box, you can try setting a hint to force the link for your sound card to > > use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or maybe > > 'hw.pci.link.0x04.irq' if that doesn't work. > > Actually, the $PIR code won't let you use an invalid IRQ currently, but this > patch lets it do so. I'm curious if you could try booting with this patch > with ACPI disabled and using an appropriate tunable (such as > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them routed. > If this does work, I'd like to try another patch as well that would help it > to work out-of-the-box for the non-ACPI case. Thanks. John, I have not forgotten this, but remote testing when re-boots are required is a bit difficult. My wife helped me a bit yesterday, but she is a Solaris type and I need to step her through things command by command, so it's a bit tedious. I may get a chance to try again tonight, depending on when I get out of the convention center tonight. (Today we installed all of the hardware into the NOC... 2 big Juniper routers, a Force10 E1200, a Foundry NetIron, and bunch of Cisco 6509s. I think we have 8 or 9 10 Gig. circuits coming inn this year. Lots of fiber patching!) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 22:23:52 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBCD416A4CE; Thu, 4 Nov 2004 22:23:52 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5679A43D3F; Thu, 4 Nov 2004 22:23:52 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP id IBA74465; Thu, 04 Nov 2004 14:23:52 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CA4B55D04; Thu, 4 Nov 2004 14:23:51 -0800 (PST) To: John Baldwin In-reply-to: Your message of "Mon, 01 Nov 2004 17:48:25 EST." <200411011748.25052.jhb@FreeBSD.org> Date: Thu, 04 Nov 2004 14:23:51 -0800 From: "Kevin Oberman" Message-Id: <20041104222351.CA4B55D04@ptavv.es.net> cc: acpi@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:23:53 -0000 > From: John Baldwin > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > From: John Baldwin > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > From: John Baldwin > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > Kevin Oberman wrote: > > > > > > > > It looks like interrupts from the Ethernet are not delivered > > > > > > > > without ACPI, but that is hardly your problem. I have > > > > > > > > over-ridden the black-list and things are back to normal. > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that irq > > > > > > > routing in Windows uses multiple info sources including _PIR and > > > > > > > $PIR. John Baldwin has patches to do this for us too. > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite a > > > > > > while. The patches I have are to make the acpi_pci_link code work > > > > > > more like the $PIR code already does. It doesn't change the ACPI > > > > > > code to actually use $PIR or the MPTable though. I can try to look > > > > > > at why the ethernet device doesn't get interrupts correctly if you > > > > > > can provide verbose ACPI and non-ACPI dmesgs to look at. > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > interrupts that I had not previously noted, but they seen to be > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates it > > > > > should be on IRQ 6. interrupt total > > > > > rate > > > > > irq0: clk 4242251 99 > > > > > irq1: atkbd0 3 0 > > > > > irq7: ppc0 1 0 > > > > > irq8: rtc 5430044 127 > > > > > irq10: xl0 13699 0 > > > > > irq13: npx0 1 0 > > > > > irq14: ata0 166980 3 > > > > > irq15: ata1 136 0 > > > > > Total 9853115 232 > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an option > > > > for your link devices but ACPI does. In the non-APCI case we use IRQ > > > > 10 for both xl0 and pcm0. Are you saying that in that case pcm0 works > > > > but xl0 does not? > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > first tone in the file plays continuously, like there are no interrupts > > > from the sound card. :-) > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of the > > box, you can try setting a hint to force the link for your sound card to > > use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or maybe > > 'hw.pci.link.0x04.irq' if that doesn't work. > > Actually, the $PIR code won't let you use an invalid IRQ currently, but this > patch lets it do so. I'm curious if you could try booting with this patch > with ACPI disabled and using an appropriate tunable (such as > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them routed. > If this does work, I'd like to try another patch as well that would help it > to work out-of-the-box for the non-ACPI case. Thanks. John, I have not forgotten this, but remote testing when re-boots are required is a bit difficult. My wife helped me a bit yesterday, but she is a Solaris type and I need to step her through things command by command, so it's a bit tedious. I may get a chance to try again tonight, depending on when I get out of the convention center tonight. (Today we installed all of the hardware into the NOC... 2 big Juniper routers, a Force10 E1200, a Foundry NetIron, and bunch of Cisco 6509s. I think we have 8 or 9 10 Gig. circuits coming inn this year. Lots of fiber patching!) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 22:38:25 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07FC216A4E4 for ; Thu, 4 Nov 2004 22:38:24 +0000 (GMT) Received: from secnap2.secnap.com (secnap2.secnap.net [204.89.241.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7105E43D53 for ; Thu, 4 Nov 2004 22:38:24 +0000 (GMT) (envelope-from scheidell@secnap.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 4 Nov 2004 17:38:21 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Had problems with 4.10 and Dell 750l fixed Thread-Index: AcTCvvynYCcphjXJQ/ukp6y09Oe0+w== From: "Michael Scheidell" To: Subject: Had problems with 4.10 and Dell 750l fixed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:38:25 -0000 I had some problems with a Dell 750 and power management. (it rebooted instead of powering off) I THINK it worked with 4_10_RELEASE build, but the 4_10 security release and RELENG_4 wouldn't power down the computer. Kernel compiled with any combination of apm0 (nexus, disable, flags, etc) didn't seem to work. Dmesg didn't find any apm devices. So, I tried with the acpica option in kernel. When I pressed the power off button, it pretended to power off, go to 'ACPI Power off'.. Hung there for 10 seconds then said 'failed. Timeout' and rebooted. Likewise, shutdown -p did similar, but instead of rebooting, ended with 'press any key to reboot'.=20 Now, with a headless box, you sure want the ability to turn it off without a user needing to watch a CRT, so I spent some time googling (to no avail) and testing. I finally set this in /etc/sysctl.conf: hw.acpi.disable_on_poweroff=3D0 (it was 1, just like every other box I have seen) Now it works. Again, whats funny is that it USED TO WORK FINE, and I don't know why it stopped. Ps, I finally found =20 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm l It suggests hw.acpi.disable_on_poweroff=3D0 So, to help debugging and fixing, here are specs: Dell poweredge 750 2.8G P4, A02 Bios. (no way to change anything apm or acpi in bios that I can see) hw.acpi.supported_sleep_state: S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S1 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 600 hw.acpi.s4bios: 1 hw.acpi.verbose: 0 hw.acpi.disable_on_poweroff: 1 Ascidump: www.secnap.com/private/acpi.txt --=20 Michael Scheidell, CTO SECNAP Network Security 561-999-5000 x 1131 www.secnap.com From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 22:50:44 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A1D716A4CE for ; Thu, 4 Nov 2004 22:50:44 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B57A843D41 for ; Thu, 4 Nov 2004 22:50:43 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25712 invoked from network); 4 Nov 2004 22:50:43 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Nov 2004 22:50:42 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA4Mocao089213; Thu, 4 Nov 2004 17:50:39 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Thu, 4 Nov 2004 17:30:04 -0500 User-Agent: KMail/1.6.2 References: <20041104222351.CA4B55D04@ptavv.es.net> In-Reply-To: <20041104222351.CA4B55D04@ptavv.es.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041730.04081.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:50:44 -0000 On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote: > > From: John Baldwin > > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > > From: John Baldwin > > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > > From: John Baldwin > > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > > Kevin Oberman wrote: > > > > > > > > > It looks like interrupts from the Ethernet are not > > > > > > > > > delivered without ACPI, but that is hardly your problem. I > > > > > > > > > have over-ridden the black-list and things are back to > > > > > > > > > normal. > > > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that > > > > > > > > irq routing in Windows uses multiple info sources including > > > > > > > > _PIR and $PIR. John Baldwin has patches to do this for us > > > > > > > > too. > > > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite > > > > > > > a while. The patches I have are to make the acpi_pci_link code > > > > > > > work more like the $PIR code already does. It doesn't change > > > > > > > the ACPI code to actually use $PIR or the MPTable though. I > > > > > > > can try to look at why the ethernet device doesn't get > > > > > > > interrupts correctly if you can provide verbose ACPI and > > > > > > > non-ACPI dmesgs to look at. > > > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > > interrupts that I had not previously noted, but they seen to be > > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates > > > > > > it should be on IRQ 6. interrupt total > > > > > > rate > > > > > > irq0: clk 4242251 99 > > > > > > irq1: atkbd0 3 0 > > > > > > irq7: ppc0 1 0 > > > > > > irq8: rtc 5430044 127 > > > > > > irq10: xl0 13699 0 > > > > > > irq13: npx0 1 0 > > > > > > irq14: ata0 166980 3 > > > > > > irq15: ata1 136 0 > > > > > > Total 9853115 232 > > > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an > > > > > option for your link devices but ACPI does. In the non-APCI case > > > > > we use IRQ 10 for both xl0 and pcm0. Are you saying that in that > > > > > case pcm0 works but xl0 does not? > > > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > > first tone in the file plays continuously, like there are no > > > > interrupts from the sound card. :-) > > > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of > > > the box, you can try setting a hint to force the link for your sound > > > card to use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or > > > maybe 'hw.pci.link.0x04.irq' if that doesn't work. > > > > Actually, the $PIR code won't let you use an invalid IRQ currently, but > > this patch lets it do so. I'm curious if you could try booting with this > > patch with ACPI disabled and using an appropriate tunable (such as > > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them > > routed. If this does work, I'd like to try another patch as well that > > would help it to work out-of-the-box for the non-ACPI case. Thanks. > > John, > > I have not forgotten this, but remote testing when re-boots are required > is a bit difficult. My wife helped me a bit yesterday, but she is a > Solaris type and I need to step her through things command by command, > so it's a bit tedious. That's ok, take your time, this isn't super critical. > I may get a chance to try again tonight, depending on when I get out of > the convention center tonight. (Today we installed all of the hardware > into the NOC... 2 big Juniper routers, a Force10 E1200, a Foundry > NetIron, and bunch of Cisco 6509s. I think we have 8 or 9 10 Gig. > circuits coming inn this year. Lots of fiber patching!) Heh, sounds like fun. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 22:50:44 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A88416A4CF for ; Thu, 4 Nov 2004 22:50:44 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B562D43D39 for ; Thu, 4 Nov 2004 22:50:43 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25712 invoked from network); 4 Nov 2004 22:50:43 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Nov 2004 22:50:42 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA4Mocao089213; Thu, 4 Nov 2004 17:50:39 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Thu, 4 Nov 2004 17:30:04 -0500 User-Agent: KMail/1.6.2 References: <20041104222351.CA4B55D04@ptavv.es.net> In-Reply-To: <20041104222351.CA4B55D04@ptavv.es.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041730.04081.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:50:44 -0000 On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote: > > From: John Baldwin > > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > > From: John Baldwin > > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > > From: John Baldwin > > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > > Kevin Oberman wrote: > > > > > > > > > It looks like interrupts from the Ethernet are not > > > > > > > > > delivered without ACPI, but that is hardly your problem. I > > > > > > > > > have over-ridden the black-list and things are back to > > > > > > > > > normal. > > > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that > > > > > > > > irq routing in Windows uses multiple info sources including > > > > > > > > _PIR and $PIR. John Baldwin has patches to do this for us > > > > > > > > too. > > > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite > > > > > > > a while. The patches I have are to make the acpi_pci_link code > > > > > > > work more like the $PIR code already does. It doesn't change > > > > > > > the ACPI code to actually use $PIR or the MPTable though. I > > > > > > > can try to look at why the ethernet device doesn't get > > > > > > > interrupts correctly if you can provide verbose ACPI and > > > > > > > non-ACPI dmesgs to look at. > > > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > > interrupts that I had not previously noted, but they seen to be > > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates > > > > > > it should be on IRQ 6. interrupt total > > > > > > rate > > > > > > irq0: clk 4242251 99 > > > > > > irq1: atkbd0 3 0 > > > > > > irq7: ppc0 1 0 > > > > > > irq8: rtc 5430044 127 > > > > > > irq10: xl0 13699 0 > > > > > > irq13: npx0 1 0 > > > > > > irq14: ata0 166980 3 > > > > > > irq15: ata1 136 0 > > > > > > Total 9853115 232 > > > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an > > > > > option for your link devices but ACPI does. In the non-APCI case > > > > > we use IRQ 10 for both xl0 and pcm0. Are you saying that in that > > > > > case pcm0 works but xl0 does not? > > > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > > first tone in the file plays continuously, like there are no > > > > interrupts from the sound card. :-) > > > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of > > > the box, you can try setting a hint to force the link for your sound > > > card to use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or > > > maybe 'hw.pci.link.0x04.irq' if that doesn't work. > > > > Actually, the $PIR code won't let you use an invalid IRQ currently, but > > this patch lets it do so. I'm curious if you could try booting with this > > patch with ACPI disabled and using an appropriate tunable (such as > > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them > > routed. If this does work, I'd like to try another patch as well that > > would help it to work out-of-the-box for the non-ACPI case. Thanks. > > John, > > I have not forgotten this, but remote testing when re-boots are required > is a bit difficult. My wife helped me a bit yesterday, but she is a > Solaris type and I need to step her through things command by command, > so it's a bit tedious. That's ok, take your time, this isn't super critical. > I may get a chance to try again tonight, depending on when I get out of > the convention center tonight. (Today we installed all of the hardware > into the NOC... 2 big Juniper routers, a Force10 E1200, a Foundry > NetIron, and bunch of Cisco 6509s. I think we have 8 or 9 10 Gig. > circuits coming inn this year. Lots of fiber patching!) Heh, sounds like fun. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org