From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 16 01:01:19 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 6B2D516A4E1; Sun, 16 Jul 2006 01:01:19 +0000 (UTC) (envelope-from john@utzweb.net) Received: from marley.grokthis.net (marley.grokthis.net [69.93.78.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 923D343D4C; Sun, 16 Jul 2006 01:01:18 +0000 (GMT) (envelope-from john@utzweb.net) Received: from utzweb.net (marley.grokthis.net [127.0.0.1]) by marley.grokthis.net (Postfix) with ESMTP id 70404F10B7; Sat, 15 Jul 2006 21:01:19 -0400 (EDT) Received: from 69.93.78.27 (proxying for 24.22.134.170) (SquirrelMail authenticated user john-utzweb-net); by utzweb.net with HTTP; Sat, 15 Jul 2006 21:01:23 -0400 (EDT) Message-ID: <46050.69.93.78.27.1153011683.squirrel@69.93.78.27> In-Reply-To: <20060715183804.GN17014@poupinou.org> References: <200607122136.54293.mistry.7@osu.edu> <44B6401F.8050507@centtech.com> <44B641F2.2020500@centtech.com> <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> <39062.69.93.78.27.1152857140.squirrel@69.93.78.27> <20060715183804.GN17014@poupinou.org> Date: Sat, 15 Jul 2006 21:01:23 -0400 (EDT) From: john@utzweb.net To: "Bruno Ducrot" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: ch to fix this Re: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 01:01:19 -0000 > Hi John, Hello Bruno > On Fri, Jul 14, 2006 at 02:05:40AM -0400, john@utzweb.net wrote: >> acpi_video.c expects the lcd to be identified as 0x0110, but my Dell >> Latitude C400 (and probably others) id's the lcd at 0x0400: >> >> Device (LCD) >> { >> Method (_ADR, 0, NotSerialized) >> { >> Return (0x0400) >> } >> >> >> so, acpi_video needs to account for this. >> >> >> got this sorted, and now the display turns back on, here's the patch, i >> already send-pr'd it > > Youre somewhat right, but your patch is wrong. Thankyou for taking interest and reviewing my analysis and patch. I would beg to differ with your assertions concerning the patch's correctness, because the operation you mention below is handled a few lines above the patch. > Actually you have to check if ((adr & 0x0400) == 0x0400). the & occurs at the top of the switch, here's the destroy case: static void acpi_video_vo_destroy(struct acpi_video_output *vo) { struct acpi_video_output_queue *voqh; ACPI_SERIAL_ASSERT(video); if (vo->vo_sysctl_tree != NULL) { vo->vo_sysctl_tree = NULL; sysctl_ctx_free(&vo->vo_sysctl_ctx); } if (vo->vo_levels != NULL) AcpiOsFree(vo->vo_levels); switch (vo->adr & DOD_DEVID_MASK) { case DOD_DEVID_MONITOR: voqh = &crt_units; break; case DOD_DEVID_PANEL: case 0x400: voqh = &lcd_units; break; case DOD_DEVID_TV: voqh = &tv_units; break; default: voqh = &other_units; } STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next); free(vo, M_ACPIVIDEO); } there is also the indisputable fact that it worked: [spaz@minime /usr/home/spaz]$ sysctl hw.acpi.video hw.acpi.video.crt0.active: 0 hw.acpi.video.lcd0.active: 1 <-- used to be out0 [spaz@minime /usr/home/spaz]$ > In fact, acpi_video.c is > correct for ACPI spec2, but ACPI spec3 have changed in that regard, and > only the value 0x110 (LCD internal panel) should be kept for > backward compatility. > > Please look at the two specifications (v2.0c and v3) at the ACPI > info website: http://www.acpi.info for more. ah, the spec. thankyou! i will take the time to read it carefully. currently, i think that the next areas of despair with my dell are the following: from dmesg on boot: pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.31.INTA at func 1: 255 ACPI: Found matching pin for 0.31.INTB at func 5: 11 pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid from dmesg post quitting xorg: "Interrupt storm detected on irq 11; throttling interrupt source" i would think that if i could figure out how to fix the invalid INTB, i'd probably not get the interrupt storm > (pseudo patch snipped) > > Cheers, > > -- > Bruno Ducrot > > -- Which is worse: ignorance or apathy? > -- Don't know. Don't care. > > From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 16 03:21:38 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 66ADB16A4DF; Sun, 16 Jul 2006 03:21:38 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCE5943D49; Sun, 16 Jul 2006 03:21:37 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1G1xCE-00017l-00; Sun, 16 Jul 2006 05:21:30 +0200 Date: Sun, 16 Jul 2006 05:21:30 +0200 To: john@utzweb.net Message-ID: <20060716032130.GP17014@poupinou.org> References: <44B6401F.8050507@centtech.com> <44B641F2.2020500@centtech.com> <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> <39062.69.93.78.27.1152857140.squirrel@69.93.78.27> <20060715183804.GN17014@poupinou.org> <46050.69.93.78.27.1153011683.squirrel@69.93.78.27> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46050.69.93.78.27.1153011683.squirrel@69.93.78.27> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: ch to fix this Re: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 03:21:38 -0000 On Sat, Jul 15, 2006 at 09:01:23PM -0400, john@utzweb.net wrote: > > Hi John, > > Hello Bruno > > > On Fri, Jul 14, 2006 at 02:05:40AM -0400, john@utzweb.net wrote: > >> acpi_video.c expects the lcd to be identified as 0x0110, but my Dell > >> Latitude C400 (and probably others) id's the lcd at 0x0400: > >> > >> Device (LCD) > >> { > >> Method (_ADR, 0, NotSerialized) > >> { > >> Return (0x0400) > >> } > >> > >> > >> so, acpi_video needs to account for this. > >> > >> > >> got this sorted, and now the display turns back on, here's the patch, i > >> already send-pr'd it > > > > Youre somewhat right, but your patch is wrong. > > Thankyou for taking interest and reviewing my analysis and patch. > > I would beg to differ with your assertions concerning the patch's > correctness, because the operation you mention below is handled a few > lines above the patch. > > > Actually you have to check if ((adr & 0x0400) == 0x0400). > > the & occurs at the top of the switch, here's the destroy case: But with the *WRONG* mask. It used to be 0xffff with ACPI v2, but shall now be 0x0f00 with ACPI v3. If for example the _ADR is 0x0401, then your patch won't work. Same if for example the _ADR is 0x0101, which identify a CRT monitor, etc. The only one value that must be kept for backward compatility is (adr & 0xffff) == 0x0110 which is for an internal Flat Panel, instead of a CRT monitor if we take the new specification into account without this very specific value. BTW I compiled and found some stupid mistakes. I also changed my DSDT such that I'm pretty sure it will work for you, and for others where the _ADR may be 0x04xx as well. Please consider that one: Index: acpi_video.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_video.c,v retrieving revision 1.12 diff -u -p -r1.12 acpi_video.c --- acpi_video.c 20 Dec 2005 22:42:16 -0000 1.12 +++ acpi_video.c 16 Jul 2006 03:11:24 -0000 @@ -110,9 +110,12 @@ static void vo_set_device_state(ACPI_HAN /* _DOD and subdev's _ADR */ #define DOD_DEVID_MASK 0xffff +#define DOD_DEVID_TYPE 0x0f00 #define DOD_DEVID_MONITOR 0x0100 -#define DOD_DEVID_PANEL 0x0110 #define DOD_DEVID_TV 0x0200 +#define DOD_DEVID_DIGITAL 0x0300 +#define DOD_DEVID_PANEL 0x0400 +#define DOD_DEVID_PANEL_COMPAT 0x0110 #define DOD_BIOS (1 << 16) #define DOD_NONVGA (1 << 17) #define DOD_HEAD_ID_SHIFT 18 @@ -409,27 +412,37 @@ acpi_video_vo_init(UINT32 adr) struct acpi_video_output_queue *voqh; ACPI_SERIAL_ASSERT(video); - switch (adr & DOD_DEVID_MASK) { - case DOD_DEVID_MONITOR: - desc = "CRT monitor"; - type = "crt"; - voqh = &crt_units; - break; - case DOD_DEVID_PANEL: + if ((adr & DOD_DEVID_MASK) == DOD_DEVID_PANEL_COMPAT) { desc = "LCD panel"; type = "lcd"; voqh = &lcd_units; - break; - case DOD_DEVID_TV: - desc = "TV"; - type = "tv"; - voqh = &tv_units; - break; - default: - desc = "unknown output"; - type = "out"; - voqh = &other_units; - } + } else + switch (adr & DOD_DEVID_TYPE) { + case DOD_DEVID_MONITOR: + desc = "CRT monitor"; + type = "crt"; + voqh = &crt_units; + break; + case DOD_DEVID_DIGITAL: + desc = "Digital monitor"; + type = "crt"; + voqh = &crt_units; + break; + case DOD_DEVID_PANEL: + desc = "LCD panel"; + type = "lcd"; + voqh = &lcd_units; + break; + case DOD_DEVID_TV: + desc = "TV"; + type = "tv"; + voqh = &tv_units; + break; + default: + desc = "unknown output"; + type = "out"; + voqh = &other_units; + } n = 0; vn = vp = NULL; @@ -553,19 +566,25 @@ acpi_video_vo_destroy(struct acpi_video_ if (vo->vo_levels != NULL) AcpiOsFree(vo->vo_levels); - switch (vo->adr & DOD_DEVID_MASK) { - case DOD_DEVID_MONITOR: - voqh = &crt_units; - break; - case DOD_DEVID_PANEL: + if ((vo->adr & 0xffff) == DOD_DEVID_PANEL_COMPAT) voqh = &lcd_units; - break; - case DOD_DEVID_TV: - voqh = &tv_units; - break; - default: - voqh = &other_units; - } + else + switch (vo->adr & DOD_DEVID_TYPE) { + case DOD_DEVID_MONITOR: + voqh = &crt_units; + break; + case DOD_DEVID_DIGITAL: + voqh = &crt_units; + break; + case DOD_DEVID_PANEL: + voqh = &lcd_units; + break; + case DOD_DEVID_TV: + voqh = &tv_units; + break; + default: + voqh = &other_units; + } STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next); free(vo, M_ACPIVIDEO); } Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 16 06:47:42 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 2918516A4DE; Sun, 16 Jul 2006 06:47:42 +0000 (UTC) (envelope-from john@utzweb.net) Received: from marley.grokthis.net (marley.grokthis.net [69.93.78.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A271743D46; Sun, 16 Jul 2006 06:47:41 +0000 (GMT) (envelope-from john@utzweb.net) Received: from utzweb.net (marley.grokthis.net [127.0.0.1]) by marley.grokthis.net (Postfix) with ESMTP id C16BEF10B4; Sun, 16 Jul 2006 02:47:35 -0400 (EDT) Received: from 69.93.78.27 (proxying for 24.22.134.170) (SquirrelMail authenticated user john-utzweb-net); by utzweb.net with HTTP; Sun, 16 Jul 2006 02:47:41 -0400 (EDT) Message-ID: <50159.69.93.78.27.1153032461.squirrel@69.93.78.27> In-Reply-To: <20060716032130.GP17014@poupinou.org> References: <44B6401F.8050507@centtech.com> <44B641F2.2020500@centtech.com> <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> <39062.69.93.78.27.1152857140.squirrel@69.93.78.27> <20060715183804.GN17014@poupinou.org> <46050.69.93.78.27.1153011683.squirrel@69.93.78.27> <20060716032130.GP17014@poupinou.org> Date: Sun, 16 Jul 2006 02:47:41 -0400 (EDT) From: john@utzweb.net To: "Bruno Ducrot" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: ch to fix this Re: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 06:47:42 -0000 > On Sat, Jul 15, 2006 at 09:01:23PM -0400, john@utzweb.net wrote: >> > Hi John, >> >> Hello Bruno >> >> > On Fri, Jul 14, 2006 at 02:05:40AM -0400, john@utzweb.net wrote: >> >> acpi_video.c expects the lcd to be identified as 0x0110, but my Dell >> >> Latitude C400 (and probably others) id's the lcd at 0x0400: >> >> >> >> Device (LCD) >> >> { >> >> Method (_ADR, 0, NotSerialized) >> >> { >> >> Return (0x0400) >> >> } >> >> >> >> >> >> so, acpi_video needs to account for this. >> >> >> >> >> >> got this sorted, and now the display turns back on, here's the patch, >> i >> >> already send-pr'd it >> > >> > Youre somewhat right, but your patch is wrong. >> >> Thankyou for taking interest and reviewing my analysis and patch. >> >> I would beg to differ with your assertions concerning the patch's >> correctness, because the operation you mention below is handled a few >> lines above the patch. >> >> > Actually you have to check if ((adr & 0x0400) == 0x0400). >> >> the & occurs at the top of the switch, here's the destroy case: > > But with the *WRONG* mask. It used to be 0xffff with ACPI v2, but > shall now be 0x0f00 with ACPI v3. ohh! > If for example the _ADR is 0x0401, then your patch won't work. Same > if for example the _ADR is 0x0101, which identify a CRT monitor, etc. ok, i get it, my approach met my immediate needs but would fail in the general v3 compliant case. > The only one value that must be kept for backward compatility is > (adr & 0xffff) == 0x0110 which is for an internal Flat Panel, instead > of a CRT monitor if we take the new specification into account without > this very specific value. i have much to learn, tnx for taking the time to explain it! reading the spec should greatly diminish my clue deficit > BTW I compiled and found some stupid mistakes. I also changed my DSDT > such that I'm pretty sure it will work for you, and for others where > the _ADR may be 0x04xx as well. > > Please consider that one: i'll try this out after i get some sleep. > Index: acpi_video.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi_video.c,v > retrieving revision 1.12 > diff -u -p -r1.12 acpi_video.c > --- acpi_video.c 20 Dec 2005 22:42:16 -0000 1.12 > +++ acpi_video.c 16 Jul 2006 03:11:24 -0000 > @@ -110,9 +110,12 @@ static void vo_set_device_state(ACPI_HAN > > /* _DOD and subdev's _ADR */ > #define DOD_DEVID_MASK 0xffff > +#define DOD_DEVID_TYPE 0x0f00 > #define DOD_DEVID_MONITOR 0x0100 > -#define DOD_DEVID_PANEL 0x0110 > #define DOD_DEVID_TV 0x0200 > +#define DOD_DEVID_DIGITAL 0x0300 > +#define DOD_DEVID_PANEL 0x0400 > +#define DOD_DEVID_PANEL_COMPAT 0x0110 > #define DOD_BIOS (1 << 16) > #define DOD_NONVGA (1 << 17) > #define DOD_HEAD_ID_SHIFT 18 > @@ -409,27 +412,37 @@ acpi_video_vo_init(UINT32 adr) > struct acpi_video_output_queue *voqh; > > ACPI_SERIAL_ASSERT(video); > - switch (adr & DOD_DEVID_MASK) { > - case DOD_DEVID_MONITOR: > - desc = "CRT monitor"; > - type = "crt"; > - voqh = &crt_units; > - break; > - case DOD_DEVID_PANEL: > + if ((adr & DOD_DEVID_MASK) == DOD_DEVID_PANEL_COMPAT) { > desc = "LCD panel"; > type = "lcd"; > voqh = &lcd_units; > - break; > - case DOD_DEVID_TV: > - desc = "TV"; > - type = "tv"; > - voqh = &tv_units; > - break; > - default: > - desc = "unknown output"; > - type = "out"; > - voqh = &other_units; > - } > + } else > + switch (adr & DOD_DEVID_TYPE) { > + case DOD_DEVID_MONITOR: > + desc = "CRT monitor"; > + type = "crt"; > + voqh = &crt_units; > + break; > + case DOD_DEVID_DIGITAL: > + desc = "Digital monitor"; > + type = "crt"; > + voqh = &crt_units; > + break; > + case DOD_DEVID_PANEL: > + desc = "LCD panel"; > + type = "lcd"; > + voqh = &lcd_units; > + break; > + case DOD_DEVID_TV: > + desc = "TV"; > + type = "tv"; > + voqh = &tv_units; > + break; > + default: > + desc = "unknown output"; > + type = "out"; > + voqh = &other_units; > + } > > n = 0; > vn = vp = NULL; > @@ -553,19 +566,25 @@ acpi_video_vo_destroy(struct acpi_video_ > if (vo->vo_levels != NULL) > AcpiOsFree(vo->vo_levels); > > - switch (vo->adr & DOD_DEVID_MASK) { > - case DOD_DEVID_MONITOR: > - voqh = &crt_units; > - break; > - case DOD_DEVID_PANEL: > + if ((vo->adr & 0xffff) == DOD_DEVID_PANEL_COMPAT) > voqh = &lcd_units; > - break; > - case DOD_DEVID_TV: > - voqh = &tv_units; > - break; > - default: > - voqh = &other_units; > - } > + else > + switch (vo->adr & DOD_DEVID_TYPE) { > + case DOD_DEVID_MONITOR: > + voqh = &crt_units; > + break; > + case DOD_DEVID_DIGITAL: > + voqh = &crt_units; > + break; > + case DOD_DEVID_PANEL: > + voqh = &lcd_units; > + break; > + case DOD_DEVID_TV: > + voqh = &tv_units; > + break; > + default: > + voqh = &other_units; > + } > STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next); > free(vo, M_ACPIVIDEO); > } > > > Cheers, > > -- > Bruno Ducrot > > -- Which is worse: ignorance or apathy? > -- Don't know. Don't care. > > From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 17 04:25:10 2006 Return-Path: X-Original-To: freebsd-acpi@hub.freebsd.org Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 858D716A4DD; Mon, 17 Jul 2006 04:25:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AA8143D46; Mon, 17 Jul 2006 04:25:10 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6H4PAEe034585; Mon, 17 Jul 2006 04:25:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6H4P9iQ034581; Mon, 17 Jul 2006 04:25:09 GMT (envelope-from linimon) Date: Mon, 17 Jul 2006 04:25:09 GMT From: Mark Linimon Message-Id: <200607170425.k6H4P9iQ034581@freefall.freebsd.org> To: fukui.FreeBSD@fanet.net, linimon@FreeBSD.org, freebsd-acpi@FreeBSD.org, linimon@FreeBSD.org Cc: Subject: Re: i386/93963: [panic] [patch] ACPI Panic with some ACPI 2.0 PC & cannot boot X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 04:25:10 -0000 Synopsis: [panic] [patch] ACPI Panic with some ACPI 2.0 PC & cannot boot State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Mon Jul 17 04:23:53 UTC 2006 State-Changed-Why: To submitter: did this commit fix your problem? Responsible-Changed-From-To: freebsd-acpi->linimon Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 17 04:23:53 UTC 2006 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=93963 From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 17 09:17:04 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 E7AD016A4DE for ; Mon, 17 Jul 2006 09:17:04 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mail.goodforbusiness.co.uk (mail.goodforbusiness.co.uk [81.19.179.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 155D443D5F for ; Mon, 17 Jul 2006 09:16:57 +0000 (GMT) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.goodforbusiness.co.uk (Postfix) with ESMTP id 08A9111465 for ; Mon, 17 Jul 2006 10:16:56 +0100 (BST) X-Virus-Scanned: mail.goodforbusiness.co.uk Received: from mail.goodforbusiness.co.uk ([127.0.0.1]) by localhost (mail.goodforbusiness.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwYcncuUR6s0 for ; Mon, 17 Jul 2006 10:16:54 +0100 (BST) Received: from mail.helenmarks.co.uk (unknown [192.168.100.1]) by mail.goodforbusiness.co.uk (Postfix) with ESMTP id 87D9411462 for ; Mon, 17 Jul 2006 10:16:54 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 3DACD170E9; Mon, 17 Jul 2006 10:16:54 +0100 (BST) X-Virus-Scanned: amavisd-new at helenmarks.co.uk Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4TDMVDMQhOL; Mon, 17 Jul 2006 10:16:52 +0100 (BST) Received: by mail.helenmarks.co.uk (Postfix, from userid 80) id B25EF1704B; Mon, 17 Jul 2006 10:16:52 +0100 (BST) Received: from mailhost.graphdata.co.uk ([195.12.22.194]) (SquirrelMail authenticated user dom) by mail.helenmarks.co.uk with HTTP; Mon, 17 Jul 2006 10:16:52 +0100 (BST) Message-ID: <3368.195.12.22.194.1153127812.squirrel@mail.helenmarks.co.uk> Date: Mon, 17 Jul 2006 10:16:52 +0100 (BST) From: "Dominic Marks" To: freebsd-acpi@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [Fwd: ACPI related crash on a Dell PowerEdge SC1420 regression since 6.1-RELEASE] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 09:17:05 -0000 >>> Forwarding to -acpi since I had no reply on -stable. Hello, I upgraded a PowerEdge SC1420 which had been installed with 6.1-R to 6.1-S today and now it no longer boots with ACPI enabled. It doesn't give a crash dump so here is the information I managed to note down before it rebooted: This happens after em and twe in the boot process. FVA 0x20:0xc0afce73 SP 0x28:0xc0c20944 FP 0x28:0xc0c20958 Trap 12 in swapper. I've no idea how useful this information is, hopeful it is a clue. Full dmesg below (from a non-ACPI boot, of course), please let me know if there is any other information I can provide. Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-STABLE #0: Thu Jul 13 15:22:54 UTC 2006 dom@gdc083.internal.graphdata.co.uk:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 1072218112 (1022 MB) avail memory = 1040330752 (992 MB) MPTable: ioapic0: Changing APIC ID to 8 ioapic0: Assuming intbase of 0 ioapic1: Changing APIC ID to 9 ioapic1: Assuming intbase of 24 ioapic2: Changing APIC ID to 10 ioapic2: Assuming intbase of 48 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib0: unable to route slot 2 INTA pcib0: unable to route slot 3 INTA pcib0: unable to route slot 4 INTA pci0: at device 0.1 (no driver attached) pcib1: irq 11 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 pci2: at device 12.0 (no driver attached) pcib3: at device 0.2 on pci1 pci3: on pcib3 twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xccb0-0xccbf mem 0xdd800000-0xddffffff irq 49 at device 13.0 on pci3 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 em0: port 0xccc0-0xccff mem 0xdd6e0000-0xdd6fffff irq 48 at device 14.0 on pci3 em0: Ethernet address: 00:13:72:8b:3c:a9 pcib4: irq 11 at device 3.0 on pci0 pci4: on pcib4 pcib5: irq 11 at device 4.0 on pci0 pci5: on pcib5 uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: waiting for BIOS to give up control usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered umass0: FREECOM. ATAPI-6 Bridge Controller, rev 2.00/0.00, addr 2 umass1: Freecom Classic Mobile 2.5' Hard Disk, rev 2.00/0.33, addr 3 pcib6: at device 30.0 on pci0 pci6: on pcib6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xdffffc00-0xdfffffff irq 18 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 18 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc9fff,0xca000-0xcbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) ukbd0: Dell Dell USB Keyboard, rev 1.10/2.00, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. Timecounter "TSC" frequency 2992515172 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDROM at ata1-master UDMA33 ad4: 76293MB at ata2-master SATA150 da1 at umass-sim1 bus 1 target 0 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 28615MB (58605120 512 byte sectors: 255H 63S/T 3648C) da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 38154MB (78140160 512 byte sectors: 255H 63S/T 4864C) Trying to mount root from ufs:/dev/ad4s1a Thanks! Dominic From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 17 11:02:26 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 D34E616A4DD for ; Mon, 17 Jul 2006 11:02:26 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 801EA43D46 for ; Mon, 17 Jul 2006 11:02:26 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6HB2Qpm071409 for ; Mon, 17 Jul 2006 11:02:26 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6HB2PQb071405 for freebsd-acpi@freebsd.org; Mon, 17 Jul 2006 11:02:25 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 17 Jul 2006 11:02:25 GMT Message-Id: <200607171102.k6HB2PQb071405@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 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 11:02:26 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- 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 [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 o [2005/03/21] i386/79080 acpi acpi thermal changes freezes HP nx6110 o [2005/03/21] i386/79081 acpi ACPI suspend/resume not working on HP nx6 o [2005/04/28] i386/80426 acpi [APIC] [panic] 5.4-RC3 still panic when b o [2005/10/17] i386/87568 acpi [ACPI] [REGRESSION] 6.0-STABLE needs ACPI 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 o [2004/11/11] i386/73822 acpi [request] add thermal support to ACPI o [2004/11/11] kern/73823 acpi [feature request] acpi / power-on by time f [2004/11/17] kern/74030 acpi Unplugging AC causes battery % to stay lo f [2005/12/24] kern/90871 acpi ACPI problems with ASUS A8N-VM-CSM o [2006/05/30] kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 50 7 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 18 18:40:40 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 15D3F16A4DD for ; Tue, 18 Jul 2006 18:40:40 +0000 (UTC) (envelope-from doug@safeport.com) Received: from pemaquid.safeport.com (pemaquid.safeport.com [209.31.154.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5117343D76 for ; Tue, 18 Jul 2006 18:40:36 +0000 (GMT) (envelope-from doug@safeport.com) Received: from localhost (localhost [127.0.0.1]) by pemaquid.safeport.com (8.13.4/8.12.11) with ESMTP id k6IIeZsb094603; Tue, 18 Jul 2006 14:40:35 -0400 (EDT) (envelope-from doug@safeport.com) Date: Tue, 18 Jul 2006 14:40:35 -0400 (EDT) From: doug@safeport.com To: Nate Lawson In-Reply-To: <44B980C0.8040400@root.org> Message-ID: <20060718142939.E89339@pemaquid.safeport.com> References: <20060626025813.M64069@pemaquid.safeport.com> <44B980C0.8040400@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: acpi on thinkpad T42p X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 18:40:40 -0000 On Sat, 15 Jul 2006, Nate Lawson wrote: > doug@safeport.com wrote: > > I am trying to get suspend/coincidence working. I think what I have is a problem in > > the Xorg ATI driver, but I am not sure and would greatly appreciate some > > guidance. > > > > I am running 6.1 and Xorg 6.9.0. The S1 and S3 states worked with the only > > change being commenting out the DRI module in xorg.conf. My video shows as: > > > > none2@pci1:0:0: class=0x030000 card=0x054f1014 chip=0x4e541002 rev=0x80 hdr=0x00 > > vendor = 'ATI Technologies Inc' > > device = 'Radeon Mobility M10 NT (RV350-WS)' > > class = display > > subclass = VGA > > > > Upon a resume from an S3 state the background is not restored, looking rather > > like a zebra (black and white lines). I can restore the background by forcing > > KDE to redraw it. Everything else except the built-in mouse is restored. I am > > using the ipw wireless driver, usually the network also comes back > > > > Am I correct in thinking the problem is in the ATI driver? > > Well, it's probably X's responsibility to reinitialize the video right. > > You can probably force the mouse reset with: > hint.psm.0.flags="0x2000" Thanks Nate, this did indeed fix the mouse. Oddly enough it largely fixed the problem with restoring the screen. At this point I have done 3 suspend/resumes just to test this thought. I am viewing this a coindenance until I have some time to mess this thing. Any linkage is not logical I think. > > -- > Nate > _____ Douglas Denault http://www.safeport.com doug@safeport.com Voice: 301-469-8766 Fax: 301-469-0601 From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 19 09:44:39 2006 Return-Path: X-Original-To: acpi@FreeBSD.org 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 4B07616A4DA for ; Wed, 19 Jul 2006 09:44:39 +0000 (UTC) (envelope-from 5817@ostrov.net) Received: from ostrov.mail.pike.ru (ostrov.mail.pike.ru [85.30.224.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id E602543D45 for ; Wed, 19 Jul 2006 09:44:36 +0000 (GMT) (envelope-from 5817@ostrov.net) Received: (qmail 36891 invoked from network); 19 Jul 2006 09:44:34 -0000 Received: from wizard93.ostrov.pike (HELO ?192.168.0.5?) (10.105.15.10) by ostrov.mail.pike.ru with SMTP; 19 Jul 2006 09:44:34 -0000 Message-ID: <44BDFF6A.7030506@ostrov.net> Date: Wed, 19 Jul 2006 10:46:18 +0100 From: Dmitry Stefankov <5817@ostrov.net> Organization: HOME User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: acpi@FreeBSD.org Content-Type: multipart/mixed; boundary="------------050907090705080108020308" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Problem with ACPI shutdown code X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 5817@ostrov.net List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 09:44:39 -0000 This is a multi-part message in MIME format. --------------050907090705080108020308 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues. I saw for some x-86 based computers (some notebooks, Intel server platforms) and for FreeBSD 5.x/6.x the following problem: during reboot sequence the computer hangs forever after ACPI shutdown code executing and final reboot is not executed. I found that the reset code doesn't work. But if ACPI shutdown code is be skipped then the computer is rebooted OK (if we have a kernel panic then all works OK). I suggest to add a small workaround to fix this problem. I attached the sample code for FreeBSD 6.1R code. Please note also that Linux Fedora Core 5 has the same problem for this, hardware, but the Microsoft Windows XP and 2003 are rebooted OK. All the best, Dmitry Stefankov --------------050907090705080108020308-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 20 20:43:21 2006 Return-Path: X-Original-To: acpi@freebsd.org 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 B091516A4DD for ; Thu, 20 Jul 2006 20:43:21 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5463443D46 for ; Thu, 20 Jul 2006 20:43:20 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [67.119.74.222] Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by ylpvm01.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k6KKgxNW026572; Thu, 20 Jul 2006 16:42:59 -0400 Message-ID: <44BFEADA.8070802@root.org> Date: Thu, 20 Jul 2006 13:43:06 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Kevin Oberman References: <20060630160642.D8DC245043@ptavv.es.net> In-Reply-To: <20060630160642.D8DC245043@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: New errors when booting current X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 20:43:21 -0000 Kevin Oberman wrote: > I am seeing large numbers of "bad write" and "bad read" errors from acpi > since my last update of the OS. I'm getting these from both desktops with > minimal ACPI capability and my laptop. > > I don't see any problems, so I suspect they are cosmetic, but I am > curious as to what changed to trigger them and whether they might be > eliminated. > > Let me know if you want to see my ASL, but it seems to be happening on > all of my current systems. > > Here is an excerpt from my dmesg on the desktop: > acpi: bad write to port 0x070 (8), val 0x26 > acpi: bad read from port 0x071 (8) > acpi: bad write to port 0x070 (8), val 0x26 > acpi: bad read from port 0x071 (8) > acpi: bad write to port 0x070 (8), val 0x26 Your ASL is writing to the RTC hardware directly. This is not allowed by Windows XP and newer systems for obvious reasons. We added the check recently but do not block the accesses yet. I don't think we use the RTC much so we're just lucky there's no collision. I'll try to add a patch soon that only prints the first 5 errors or so but can do more if we want to use it for debugging. http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 21 03:27:41 2006 Return-Path: X-Original-To: acpi@freebsd.org 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 B165916A4DA for ; Fri, 21 Jul 2006 03:27:41 +0000 (UTC) (envelope-from dana.myers@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB08D43D45 for ; Fri, 21 Jul 2006 03:27:38 +0000 (GMT) (envelope-from dana.myers@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so314725wra for ; Thu, 20 Jul 2006 20:27:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Isv7gTbmwVUPD4SDCP+cUDGuMyqdgGyud4NJTlJgCnJfCGEQrDcCOS6p9QUgymLKRHxgM5LIDjPxU5K+cE3lySTFBArSLk3OCqzTWfU56giu3uKYlRahM/cOMq0N5CVn8Lpr/CYzNWTjq/gmZ3P5un/e/HbBGuDmUjVJD6mpq6g= Received: by 10.65.138.14 with SMTP id q14mr184645qbn; Thu, 20 Jul 2006 20:27:37 -0700 (PDT) Received: from ?192.168.0.2? ( [67.180.22.170]) by mx.gmail.com with ESMTP id e18sm436382qba.2006.07.20.20.27.36; Thu, 20 Jul 2006 20:27:37 -0700 (PDT) Message-ID: <44C049AD.8040101@gmail.com> Date: Thu, 20 Jul 2006 20:27:41 -0700 From: "Dana H. Myers" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Nate Lawson References: <20060630160642.D8DC245043@ptavv.es.net> <44BFEADA.8070802@root.org> In-Reply-To: <44BFEADA.8070802@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: New errors when booting current X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 03:27:41 -0000 Nate Lawson wrote: > Kevin Oberman wrote: >> I am seeing large numbers of "bad write" and "bad read" errors from acpi >> since my last update of the OS. I'm getting these from both desktops with >> minimal ACPI capability and my laptop. >> >> I don't see any problems, so I suspect they are cosmetic, but I am >> curious as to what changed to trigger them and whether they might be >> eliminated. >> >> Let me know if you want to see my ASL, but it seems to be happening on >> all of my current systems. >> >> Here is an excerpt from my dmesg on the desktop: >> acpi: bad write to port 0x070 (8), val 0x26 >> acpi: bad read from port 0x071 (8) >> acpi: bad write to port 0x070 (8), val 0x26 >> acpi: bad read from port 0x071 (8) >> acpi: bad write to port 0x070 (8), val 0x26 > > Your ASL is writing to the RTC hardware directly. This is not allowed > by Windows XP and newer systems for obvious reasons. We added the check > recently but do not block the accesses yet. I don't think we use the > RTC much so we're just lucky there's no collision. I'll try to add a > patch soon that only prints the first 5 errors or so but can do more if > we want to use it for debugging. > > http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx Windows apparently does more than block the accesses; it does to some effort to make them work safely. I eventually gave up on most I/O port access control in the Solaris ACPI CA OSL; we'd been running for several years (first with our homegrown interpreter, and then with the ACPI CA port) without port checks and we didn't have a single report of trouble as a result; when I added the checks, I immediately started getting reports of trouble. Dana From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 21 21:15:28 2006 Return-Path: X-Original-To: acpi@freebsd.org 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 2C6D716A4DD; Fri, 21 Jul 2006 21:15:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4596043D46; Fri, 21 Jul 2006 21:15:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6LLFQKb001253; Fri, 21 Jul 2006 17:15:26 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: acpi@freebsd.org Date: Fri, 21 Jul 2006 17:15:00 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607211715.00759.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 21 Jul 2006 17:15:26 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1614/Fri Jul 21 16:27:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: amd64@freebsd.org, njl@freebsd.org Subject: [PATCH] Fix hw.physmem use with ACPI.. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 21:15:28 -0000 Several folks had problems using hw.physmem with ACPI as depending on where the system's ACPI tables were located in physical address space, using the hw.physmem tunable could result in the kernel zero'ing part of the ACPI tables. This resulted from the rather peculiar behavior of the hw.physmem/MAXMEM tunable. A (relatively) long time ago in FreeBSD land, machines did not provide a reliable way of detecting how much memory was installed (and/or FreeBSD didn't reliable detect it). As a result, the MAXMEM/hw.physmem stuff was added with 2 apparent purposes. First off, any memory above that limit was not to be used, so it could cap memory usage. The second purpose is more curious though. If the system had claimed to have less than MAXMEM, the kernel would extend the last memory segment up to MAXMEM. Thus, if your system had 64 MB of RAM but only detected 16, you could use MAXMEM to force it to see all 64 MB. This second feature is what got machines into trouble. Modern machines (such as those with ACPI) all include a BIOS-supplied map of physical memory (known as the SMAP (I think it stands for system map)) that specifies which regions of the physical address space are available RAM, which are reserved for the BIOS or devices, etc. On these systems, we can trust the SMAP, and extending the top of memory can only produce pain (e.g. moving the top of memory up into the area reserved for ACPI tables). All this is to provide the background for the change in this patch. The patch is simple. If we used the SMAP to figure out our memory map, then we turn off the second feature of MAXMEM and just use it to cap the top of memory. Since amd64 always uses the SMAP, the second feature has been axed altogether on that platform. http://www.FreeBSD.org/~jhb/patches/hw.physmem.patch Please test it. Especially if you used to have problems using hw.physmem with ACPI in the past. -- John Baldwin