From nobody Mon May 17 20:00:21 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C5B3085A886 for ; Mon, 17 May 2021 20:00:27 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkVNp68PPz3QT5 for ; Mon, 17 May 2021 20:00:23 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.189] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 14HK0K21047189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 May 2021 14:00:22 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.189] From: John Nielsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: How to properly locate/parse ACPI table from kernel module? Message-Id: Date: Mon, 17 May 2021 14:00:21 -0600 To: "freebsd-acpi@freebsd.org" X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FkVNp68PPz3QT5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mailers.freebsdsolutions.net:c]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-acpi@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; DMARC_NA(0.00)[jnielsen.net]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-acpi] Hi all- I=E2=80=99m not much of a kernel programmer but I=E2=80=99m trying to = maintain/improve the isboot module, which allows booting directly from = iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up the = interface with the details specified therein and connecting to the = specified iSCSI target before trying to mount root. I=E2=80=99m not the original author but as the port maintainer I am = hosting the code here: https://github.com/jnielsendotnet/isboot I have a test system where the module loads but fails to find the iBFT. = I reviewed the iBFT code and realized it has a bunch of magic numbers = mixed in with some random memory diving. If I=E2=80=99m reading it right = (see https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 = and = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), = it looks like it scans all of the (kernel?) memory between 512K and 1M = in 16-byte increments looking for one beginning with the string = =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as the offset for = reading the table. I don=E2=80=99t know where the 512K and 1M values = came from or if they are correct, but I do have a system where that = method does not work. IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find it = would be safer and more reliable. So my question is: how does one do = that? Are there other places in the kernel code that do this sort of = thing that I could use as a model? Any gotchas I should know about as a = (less-than) novice kernel programmer? Thanks! JN From nobody Mon May 17 20:27:48 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3C70F85FCCE for ; Mon, 17 May 2021 20:27:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkW0S14Zcz3ktY; Mon, 17 May 2021 20:27:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id AD3192A9E8; Mon, 17 May 2021 20:27:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) To: John Nielsen , "freebsd-acpi@freebsd.org" References: From: Andriy Gapon Subject: Re: How to properly locate/parse ACPI table from kernel module? Message-ID: Date: Mon, 17 May 2021 23:27:48 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.10.1 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam: Yes On 17/05/2021 23:00, John Nielsen wrote: > Hi all- > > I’m not much of a kernel programmer but I’m trying to maintain/improve the > isboot module, which allows booting directly from iSCSI by reading the iSCSI > Boot Firmware Table (iBFT), bringing up the interface with the details > specified therein and connecting to the specified iSCSI target before trying > to mount root. > > I’m not the original author but as the port maintainer I am hosting the code > here: https://github.com/jnielsendotnet/isboot > > I have a test system where the module loads but fails to find the iBFT. I > reviewed the iBFT code and realized it has a bunch of magic numbers mixed in > with some random memory diving. If I’m reading it right (see > https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and > https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), it > looks like it scans all of the (kernel?) memory between 512K and 1M in > 16-byte increments looking for one beginning with the string “iBFT”, which if > it finds will be used as the offset for reading the table. I don’t know where > the 512K and 1M values came from or if they are correct, but I do have a > system where that method does not work. They seem to come from iBFT specification. Locating the iBFT The iBFT can be located by the Low RAM Method. Scan for the table header signature in system memory between 512K and 1024K. The scan MUST be done starting at the lower address scanning forward to the higher address. When using the Low RAM Method, the table header must be aligned on a 16-byte boundary. > IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find it > would be safer and more reliable. So my question is: how does one do that? > Are there other places in the kernel code that do this sort of thing that I > could use as a model? Yes. Search for occurrences of AcpiGetTable() in the code, that's the function you want to use. But it could be that the table gets overwritten during boot for some reason... -- Andriy Gapon From nobody Mon May 17 20:27:49 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 176A285FD61 for ; Mon, 17 May 2021 20:27:58 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkW0Y711wz3ktv for ; Mon, 17 May 2021 20:27:57 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id i20so5617944qtx.4 for ; Mon, 17 May 2021 13:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=8jEIHbgT99ZxJiFVSxpful4/ssN+HfKIIt2wKHtcEpw=; b=oTKq/WTBwAHEtPh0SnOpxJE1fdLSmExC+l17EKz+vzqBKEY6EQTOgPXQk+MWMR24dU /j/yMfYggRMYaWGq7ahIfAji6KE9jXmm55sUKIXF/qVv5ndACPiBc2vOzOT0P/vnpDXl xQ/MyFOFjP6C3jzR+sb/KUU+6qTeiiXubEOLRce3P/9bV6ZrR67a/KtZI3ERuL1hmPnV 0el0lcjVtvLiD7WBniT2qtufAoBYJpHgVIRXkYZGn2pq/YenYybysQX/nv4Je3RnY1y/ TdDDDIJ5GkATqAGl3BVyKmX0p4ks6AzYTzVqQ6EWCdcNxEKT6Rm4Rpi7tb0Nwq43KvLk +rcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8jEIHbgT99ZxJiFVSxpful4/ssN+HfKIIt2wKHtcEpw=; b=DgSBA7lKcqgrR8ofjIe9zKSbZNCEZijMEWfw7Sp4DrQkp7WkJnv5JqOSsVlI8fRR69 yhIkuWs1qBdSPP3Rs5GzGPNpvBfRDNicyKJmG5Av39MouJwQNq9biFwjzYiunBqusf8n 2H9up/ALlKqorlJUosVZ+5vXhspVcwWXriElsKXG/Afx6XPZIy8fdnPutffpW9W7usDO s3WHmggtbup45+AzI59NtpXm7Qg0pMS0AmaVeeZUpTyHG8CqF1nh0uvhCkvspm7MX3zz PfHwDEJiRecLwaqvtnHRh0Z4j7XBrlNKNKNhrRQ/OltpkrnpU38Ee15zWewR8vDBShsq Ch6Q== X-Gm-Message-State: AOAM530+qMj0nTDvDzuK5weGW0dtmWjmDSoMoXKsNu5gniSRYvFdQohK jyy4VQH0JqQ+07rAwgeSQSdTql/CuP7J1A== X-Google-Smtp-Source: ABdhPJz1i2N9rDUw4PzOH4RgOgXCWSbUOMPKgrZdD1UIXhef7gQwFKDASUfMDvYyC+tfUANGSmX7pg== X-Received: by 2002:ac8:4b74:: with SMTP id g20mr1316168qts.196.1621283276716; Mon, 17 May 2021 13:27:56 -0700 (PDT) Received: from hammer.mj.niksun.com (pool-100-8-53-238.nwrknj.fios.verizon.net. [100.8.53.238]) by smtp.gmail.com with ESMTPSA id a16sm10852268qkl.46.2021.05.17.13.27.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 May 2021 13:27:56 -0700 (PDT) To: John Nielsen , "freebsd-acpi@freebsd.org" References: From: Jung-uk Kim Subject: Re: How to properly locate/parse ACPI table from kernel module? Message-ID: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> Date: Mon, 17 May 2021 16:27:49 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4FkW0Y711wz3ktv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] On 21. 5. 17., John Nielsen wrote: > Hi all- > > I’m not much of a kernel programmer but I’m trying to maintain/improve the isboot module, which allows booting directly from iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up the interface with the details specified therein and connecting to the specified iSCSI target before trying to mount root. > > I’m not the original author but as the port maintainer I am hosting the code here: https://github.com/jnielsendotnet/isboot > > I have a test system where the module loads but fails to find the iBFT. I reviewed the iBFT code and realized it has a bunch of magic numbers mixed in with some random memory diving. If I’m reading it right (see https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), it looks like it scans all of the (kernel?) memory between 512K and 1M in 16-byte increments looking for one beginning with the string “iBFT”, which if it finds will be used as the offset for reading the table. I don’t know where the 512K and 1M values came from or if they are correct, but I do have a system where that method does not work. > > IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find it would be safer and more reliable. So my question is: how does one do that? Are there other places in the kernel code that do this sort of thing that I could use as a model? Any gotchas I should know about as a (less-than) novice kernel programmer? You may use AcpiGetTable() and AcpiPutTable(), e.g., status = AcpiGetTable(ACPI_SIG_IBFT, ...); Jung-uk Kim From nobody Wed May 19 17:10:08 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7FDD28C280F for ; Wed, 19 May 2021 17:10:20 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FlfWb4xBpz3sLc for ; Wed, 19 May 2021 17:10:19 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.191] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 14JHAAw6093124 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 May 2021 11:10:12 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.191] Content-Type: text/plain; charset=utf-8 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: How to properly locate/parse ACPI table from kernel module? From: John Nielsen In-Reply-To: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> Date: Wed, 19 May 2021 11:10:08 -0600 Cc: "freebsd-acpi@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> To: Jung-uk Kim X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FlfWb4xBpz3sLc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-1.45 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_XAW(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.66)[-0.655]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[jnielsen.net]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-acpi] > On May 17, 2021, at 2:27 PM, Jung-uk Kim wrote: >=20 > On 21. 5. 17., John Nielsen wrote: >> I=E2=80=99m not much of a kernel programmer but I=E2=80=99m trying to = maintain/improve the isboot module, which allows booting directly from = iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up the = interface with the details specified therein and connecting to the = specified iSCSI target before trying to mount root. >>=20 >> I=E2=80=99m not the original author but as the port maintainer I am = hosting the code here: https://github.com/jnielsendotnet/isboot >>=20 >> I have a test system where the module loads but fails to find the = iBFT. I reviewed the iBFT code and realized it has a bunch of magic = numbers mixed in with some random memory diving. If I=E2=80=99m reading = it right (see = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), = it looks like it scans all of the (kernel?) memory between 512K and 1M = in 16-byte increments looking for one beginning with the string = =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as the offset for = reading the table. I don=E2=80=99t know where the 512K and 1M values = came from or if they are correct, but I do have a system where that = method does not work. >>=20 >> IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find = it would be safer and more reliable. So my question is: how does one do = that? Are there other places in the kernel code that do this sort of = thing that I could use as a model? Any gotchas I should know about as a = (less-than) novice kernel programmer? >=20 > You may use AcpiGetTable() and AcpiPutTable(), e.g., >=20 > status =3D AcpiGetTable(ACPI_SIG_IBFT, =E2=80=A6); Thank you (and Andriy) for your responses. Good to know that = ACPI_SIG_IBFT is already defined in the upstream headers. What is the second argument (=E2=80=9CInstance=E2=80=9D) of = AcpiGetTable()? Is it just an offset in case there are multiple = instances of a given table type? Also, when/why should AcpiPutTable() be used? Thanks! JN From nobody Wed May 19 17:35:52 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0B2908B7D89 for ; Wed, 19 May 2021 17:35:56 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Flg576F56z4cgH for ; Wed, 19 May 2021 17:35:55 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: by mail-qk1-x736.google.com with SMTP id c20so13538915qkm.3 for ; Wed, 19 May 2021 10:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FWz1UajC6DH5dDXMGhZNNwmsw5EnGwqqHfiugaGc2VM=; b=HF9hHE2nHsefCR+dAM50Cos6yzalxjjEf7nbMQqYq9S4ES3zaLDIu8l4z6uCyC9cXt rPSx0ndERCx+hzxZ+GAyIcOKp9M8bC5ooBbNb9ioxbJ7uONzfAe5wChFecZngbdzz7iN zxuV8SwZ0dL2oOvwa2raPZnJ6XlOet54rXuqxBc8ta1vJ6R1D7O8U/kMr0FZxp8Q/mPX SUfEj0N91rmtom4X1l8v6dtYehgDup7RfZ9849RvNwsbMrGxwsDWmzrnA4UteG0urNKI I7zXWwwOi4bCWX0raSuw6FCWuopS5MksvvXU7MmG0/xaYpK5AD7C7sWvJJkrxmQMKm6U 6VGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FWz1UajC6DH5dDXMGhZNNwmsw5EnGwqqHfiugaGc2VM=; b=p58cZ8e7ZaAxQbaSM1G/Xaw966MJHPo4UXnaXiZu0/Hx0SLbs+igohmJzRVjoVn+y2 eshoKAojaRtXyQCWk/qv6rVBFOjo6hQq1Er74P7xmZiS2MU5tFQmB1AEpebzLujhuD78 OgwUBdnlMAKuarYyjAGkr8/WhitSQKC22PD9rLR8tsH25B+bwnquvbrDWv7GUMHxiNFk VuUGaczSXQ2Nuu3ZF79g1OnsIEfylEezhY75Re1NPS/rzsLkHI9vEM/GtF0K9X29hZCJ VUCeB7efvUAicO19OBzl0VNv1eS+PAmo8UZ9TBq/9264gT6YvMh6a3nI2aTSc5CBRSXi 1sKA== X-Gm-Message-State: AOAM530ELh41DdKyQOi6UH99L71oz+qtkujP/PCHMPCI9zdS0XieC2Pg uvJQV3oCxnAB+hdtRtiQHnGlMcxR9cegMQ== X-Google-Smtp-Source: ABdhPJxLaqi98SfS2D78A11f8x9VJaDv2OHLm+Ac82RadGpk8vU6fNXGXT9rjDA/mWh1CVbEybETZA== X-Received: by 2002:a37:638e:: with SMTP id x136mr502462qkb.109.1621445754423; Wed, 19 May 2021 10:35:54 -0700 (PDT) Received: from hammer.mj.niksun.com (pool-100-8-53-238.nwrknj.fios.verizon.net. [100.8.53.238]) by smtp.gmail.com with ESMTPSA id k10sm50362qtm.73.2021.05.19.10.35.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 May 2021 10:35:53 -0700 (PDT) To: John Nielsen Cc: "freebsd-acpi@freebsd.org" References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> From: Jung-uk Kim Subject: Re: How to properly locate/parse ACPI table from kernel module? Message-ID: <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> Date: Wed, 19 May 2021 13:35:52 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Flg576F56z4cgH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] On 21. 5. 19., John Nielsen wrote: >> On May 17, 2021, at 2:27 PM, Jung-uk Kim wrote: >> >> On 21. 5. 17., John Nielsen wrote: >>> I’m not much of a kernel programmer but I’m trying to maintain/improve the isboot module, which allows booting directly from iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up the interface with the details specified therein and connecting to the specified iSCSI target before trying to mount root. >>> >>> I’m not the original author but as the port maintainer I am hosting the code here: https://github.com/jnielsendotnet/isboot >>> >>> I have a test system where the module loads but fails to find the iBFT. I reviewed the iBFT code and realized it has a bunch of magic numbers mixed in with some random memory diving. If I’m reading it right (see https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), it looks like it scans all of the (kernel?) memory between 512K and 1M in 16-byte increments looking for one beginning with the string “iBFT”, which if it finds will be used as the offset for reading the table. I don’t know where the 512K and 1M values came from or if they are correct, but I do have a system where that method does not work. >>> >>> IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find it would be safer and more reliable. So my question is: how does one do that? Are there other places in the kernel code that do this sort of thing that I could use as a model? Any gotchas I should know about as a (less-than) novice kernel programmer? >> >> You may use AcpiGetTable() and AcpiPutTable(), e.g., >> >> status = AcpiGetTable(ACPI_SIG_IBFT, …); > > Thank you (and Andriy) for your responses. Good to know that ACPI_SIG_IBFT is already defined in the upstream headers. It seems there are two methods. ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware_table_v1.03.pdf 1.4.3.1 Locating the iBFT The iBFT is located by the following methods. A platform shall implement one or more of these methods. 1. The ACPI Method. The iBFT is pointed to by an entry in the RSDT/XSDT. Note that ACPI [ACPI=3.0b] specifies the string in the pointer as “IBFT” (all upper case) HOWEVER the signature in the table being pointed to is“iBFT” (note the mixed case). 2. The Low RAM Method. Scan for the table header signature in system memory between 512K and 1024K. The scan MUST be done starting at the lower address scanning forward to the higher address. When using the Low RAM Method the table header must be aligned on a 16-byte boundary. Note: A system operating in UEFI mode shall utilize only the ACPI method. For modern system, it seems you should be using Method 1. I don't understand the "HOWEVER" part, though. > What is the second argument (“Instance”) of AcpiGetTable()? Is it just an offset in case there are multiple instances of a given table type? Yes. https://acpica.org/sites/acpica/files/acpica-reference_18.pdf 8.2.9 AcpiGetTable Instance Which table instance, if multiple instances of the table are allowed (SSDTor UEFI). One based (1...n). This document is little out-dated, though. > Also, when/why should AcpiPutTable() be used? To free the table after use. Jung-uk Kim From nobody Wed May 19 18:21:46 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AFCA58BA147 for ; Wed, 19 May 2021 18:21:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Flh624cppz3HHw; Wed, 19 May 2021 18:21:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7F5A9204D8; Wed, 19 May 2021 18:21:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Nielsen Cc: "freebsd-acpi@freebsd.org" References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> Organization: FreeBSD.org Subject: Re: How to properly locate/parse ACPI table from kernel module? Message-ID: Date: Wed, 19 May 2021 14:21:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 In-Reply-To: <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam: Yes On 21. 5. 19., Jung-uk Kim wrote: > On 21. 5. 19., John Nielsen wrote: >>> On May 17, 2021, at 2:27 PM, Jung-uk Kim wrote: >>> >>> On 21. 5. 17., John Nielsen wrote: >>>> I’m not much of a kernel programmer but I’m trying to maintain/improve the isboot module, which allows booting directly from iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up the interface with the details specified therein and connecting to the specified iSCSI target before trying to mount root. >>>> >>>> I’m not the original author but as the port maintainer I am hosting the code here: https://github.com/jnielsendotnet/isboot >>>> >>>> I have a test system where the module loads but fails to find the iBFT. I reviewed the iBFT code and realized it has a bunch of magic numbers mixed in with some random memory diving. If I’m reading it right (see https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), it looks like it scans all of the (kernel?) memory between 512K and 1M in 16-byte increments looking for one beginning with the string “iBFT”, which if it finds will be used as the offset for reading the table. I don’t know where the 512K and 1M values came from or if they are correct, but I do have a system where that method does not work. >>>> >>>> IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find it would be safer and more reliable. So my question is: how does one do that? Are there other places in the kernel code that do this sort of thing that I could use as a model? Any gotchas I should know about as a (less-than) novice kernel programmer? >>> >>> You may use AcpiGetTable() and AcpiPutTable(), e.g., >>> >>> status = AcpiGetTable(ACPI_SIG_IBFT, …); >> >> Thank you (and Andriy) for your responses. Good to know that ACPI_SIG_IBFT is already defined in the upstream headers. > > It seems there are two methods. > > ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware_table_v1.03.pdf > > 1.4.3.1 Locating the iBFT > > The iBFT is located by the following methods. A platform shall implement > one or more of these methods. > > 1. The ACPI Method. The iBFT is pointed to by an entry in the RSDT/XSDT. > Note that ACPI [ACPI=3.0b] specifies the string in the pointer as > “IBFT” (all upper case) HOWEVER the signature in the table being pointed > to is“iBFT” (note the mixed case). > > 2. The Low RAM Method. Scan for the table header signature in system > memory between 512K and 1024K. The scan MUST be done starting at > the lower address scanning forward to the higher address. When using the > Low RAM Method the table header must be aligned on a 16-byte > boundary. > > Note: A system operating in UEFI mode shall utilize only the ACPI method. > > For modern system, it seems you should be using Method 1. I don't > understand the "HOWEVER" part, though. ... I did little more research. It seems iSCSI spec. predates ACPI standardization and IBM kept on using "iBFT" instead of ACPI spec. "IBFT". Because this confusion, some systems use "iBFT" and some use "IBFT". Therefore, it seems you need to test both, e.g., status = AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft); if (ACPI_FAILURE(status)) status = AcpiGetTable("iBFT", 0, &ibft); Jung-uk Kim From nobody Thu May 20 03:41:56 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EACFA8BB164 for ; Thu, 20 May 2021 03:42:01 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FlwXT5Csxz4ZJ9; Thu, 20 May 2021 03:42:01 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.191] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 14K3fudS007008 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 May 2021 21:41:59 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.191] From: John Nielsen Message-Id: <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F" List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: How to properly locate/parse ACPI table from kernel module? Date: Wed, 19 May 2021 21:41:56 -0600 In-Reply-To: Cc: "freebsd-acpi@freebsd.org" To: Jung-uk Kim References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FlwXT5Csxz4ZJ9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes --Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 19, 2021, at 12:21 PM, Jung-uk Kim wrote: >=20 > On 21. 5. 19., Jung-uk Kim wrote: >> On 21. 5. 19., John Nielsen wrote: >>>> On May 17, 2021, at 2:27 PM, Jung-uk Kim = wrote: >>>>=20 >>>> On 21. 5. 17., John Nielsen wrote: >>>>> I=E2=80=99m not much of a kernel programmer but I=E2=80=99m trying = to maintain/improve the isboot module, which allows booting directly = from iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up = the interface with the details specified therein and connecting to the = specified iSCSI target before trying to mount root. >>>>>=20 >>>>> I=E2=80=99m not the original author but as the port maintainer I = am hosting the code here: https://github.com/jnielsendotnet/isboot >>>>>=20 >>>>> I have a test system where the module loads but fails to find the = iBFT. I reviewed the iBFT code and realized it has a bunch of magic = numbers mixed in with some random memory diving. If I=E2=80=99m reading = it right (see = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), = it looks like it scans all of the (kernel?) memory between 512K and 1M = in 16-byte increments looking for one beginning with the string = =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as the offset for = reading the table. I don=E2=80=99t know where the 512K and 1M values = came from or if they are correct, but I do have a system where that = method does not work. >>>>>=20 >>>>> IIUC, the iBFT is an ACPI table, and it seems like using ACPI to = find it would be safer and more reliable. So my question is: how does = one do that? Are there other places in the kernel code that do this sort = of thing that I could use as a model? Any gotchas I should know about as = a (less-than) novice kernel programmer? >>>>=20 >>>> You may use AcpiGetTable() and AcpiPutTable(), e.g., >>>>=20 >>>> status =3D AcpiGetTable(ACPI_SIG_IBFT, =E2=80=A6); >>>=20 >>> Thank you (and Andriy) for your responses. Good to know that = ACPI_SIG_IBFT is already defined in the upstream headers. >>=20 >> It seems there are two methods. >>=20 >> = ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware= _table_v1.03.pdf >>=20 >> 1.4.3.1 Locating the iBFT >>=20 >> The iBFT is located by the following methods. A platform shall = implement >> one or more of these methods. >>=20 >> 1. The ACPI Method. The iBFT is pointed to by an entry in the = RSDT/XSDT. >> Note that ACPI [ACPI=3D3.0b] specifies the string in the pointer as >> =E2=80=9CIBFT=E2=80=9D (all upper case) HOWEVER the signature in the = table being pointed >> to is=E2=80=9CiBFT=E2=80=9D (note the mixed case). >>=20 >> 2. The Low RAM Method. Scan for the table header signature in system >> memory between 512K and 1024K. The scan MUST be done starting at >> the lower address scanning forward to the higher address. When using = the >> Low RAM Method the table header must be aligned on a 16-byte >> boundary. >>=20 >> Note: A system operating in UEFI mode shall utilize only the ACPI = method. >>=20 >> For modern system, it seems you should be using Method 1. I don't >> understand the "HOWEVER" part, though. >=20 > I did little more research. It seems iSCSI spec. predates ACPI > standardization and IBM kept on using "iBFT" instead of ACPI spec. > "IBFT". Because this confusion, some systems use "iBFT" and some use > "IBFT". Therefore, it seems you need to test both, e.g., >=20 > status =3D AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft); > if (ACPI_FAILURE(status)) > status =3D AcpiGetTable("iBFT", 0, &ibft); Very helpful once again, thank you. My test machine (either the = motherboard or the NIC) has a buggy BIOS that prevents it from booting = in legacy mode with iSCSI so I=E2=80=99m using UEFI whether I wanted to = or not. I=E2=80=99m glad that my theory that the Low RAM Method might = not work in UEFI has some merit. I did notice that Linux looks for both iBFT and IBFT in its driver; the = existence of two standards is alluded to in the comments but it=E2=80=99s = nice to know what they are. I=E2=80=99ll adopt your suggested approach. JN --Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 19, 2021, at 12:21 PM, Jung-uk Kim <jkim@freebsd.org> = wrote:

On 21. 5. 19., Jung-uk Kim wrote:
On = 21. 5. 19., John Nielsen wrote:
On May 17, 2021, at 2:27 = PM, Jung-uk Kim <junguk.kim@gmail.com> wrote:

On 21. 5. 17., John Nielsen wrote:
I=E2=80=99m not much of a kernel programmer but = I=E2=80=99m trying to maintain/improve the isboot module, which allows = booting directly from iSCSI by reading the iSCSI Boot Firmware Table = (iBFT), bringing up the interface with the details specified therein and = connecting to the specified iSCSI target before trying to mount root.

I=E2=80=99m not the original author but as the = port maintainer I am hosting the code here: https://github.com/jnielsendotnet/isboot

I have a test system where the module loads but fails to find = the iBFT. I reviewed the iBFT code and realized it has a bunch of magic = numbers mixed in with some random memory diving. If I=E2=80=99m reading = it right (see https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h= #L37 and https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c= #L521), it looks like it scans all of the (kernel?) memory between = 512K and 1M in 16-byte increments looking for one beginning with the = string =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as the = offset for reading the table. I don=E2=80=99t know where the 512K and 1M = values came from or if they are correct, but I do have a system where = that method does not work.

IIUC, the iBFT = is an ACPI table, and it seems like using ACPI to find it would be safer = and more reliable. So my question is: how does one do that? Are there = other places in the kernel code that do this sort of thing that I could = use as a model? Any gotchas I should know about as a (less-than) novice = kernel programmer?

You may use = AcpiGetTable() and AcpiPutTable(), e.g.,

= status =3D AcpiGetTable(ACPI_SIG_IBFT, =E2=80=A6);

Thank you (and Andriy) for your = responses. Good to know that ACPI_SIG_IBFT is already defined in the = upstream headers.

It seems = there are two methods.

ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_bo= ot_firmware_table_v1.03.pdf

1.4.3.1 = Locating the iBFT

The iBFT is located by = the following methods. A platform shall implement
one or = more of these methods.

1. The ACPI Method. = The iBFT is pointed to by an entry in the RSDT/XSDT.
Note = that ACPI [ACPI=3D3.0b] specifies the string in the pointer as
=E2=80=9CIBFT=E2=80=9D (all upper case) HOWEVER the signature = in the table being pointed
to is=E2=80=9CiBFT=E2=80=9D = (note the mixed case).

2. The Low RAM = Method. Scan for the table header signature in system
memory= between 512K and 1024K. The scan MUST be done starting at
the lower address scanning forward to the higher address. = When using the
Low RAM Method the table header must be = aligned on a 16-byte
boundary.

Note: A system operating in UEFI mode shall utilize only the = ACPI method.

For modern system, it seems = you should be using Method 1.  I don't
understand the = "HOWEVER" part, though.

I did little more research. =  It seems iSCSI spec. predates ACPI
standardization and IBM kept on using "iBFT" instead of ACPI = spec.
"IBFT". =  Because this confusion, some systems use "iBFT" and some = use
"IBFT". =  Therefore, it seems you need to test both, e.g.,

status =3D = AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft);
= if = (ACPI_FAILURE(status))
= status =3D = AcpiGetTable("iBFT", 0, &ibft);

Very helpful once again, thank you. My test = machine (either the motherboard or the NIC) has a buggy BIOS that = prevents it from booting in legacy mode with iSCSI so I=E2=80=99m using = UEFI whether I wanted to or not. I=E2=80=99m glad that my theory that = the Low RAM Method might not work in UEFI has some merit.

I did notice that Linux = looks for both iBFT and IBFT in its driver; the existence of two = standards is alluded to in the comments but it=E2=80=99s nice to know = what they are. I=E2=80=99ll adopt your suggested approach.

JN

= --Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F-- From nobody Thu May 20 18:30:54 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B6168BC90A for ; Thu, 20 May 2021 18:31:04 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmJGH3Nmvz3k1p; Thu, 20 May 2021 18:31:03 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.189] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 14KIUsqa022513 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 May 2021 12:30:56 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.189] From: John Nielsen Message-Id: <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6" List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: How to properly locate/parse ACPI table from kernel module? Date: Thu, 20 May 2021 12:30:54 -0600 In-Reply-To: <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> Cc: "freebsd-acpi@freebsd.org" To: Jung-uk Kim References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FmJGH3Nmvz3k1p X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-1.78 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:mailers.freebsdsolutions.net]; HAS_XAW(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[jnielsen.net]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-acpi] X-Spam: Yes --Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 19, 2021, at 9:41 PM, John Nielsen wrote: >=20 >> On May 19, 2021, at 12:21 PM, Jung-uk Kim > wrote: >>=20 >> On 21. 5. 19., Jung-uk Kim wrote: >>> On 21. 5. 19., John Nielsen wrote: >>>>> On May 17, 2021, at 2:27 PM, Jung-uk Kim > wrote: >>>>>=20 >>>>> On 21. 5. 17., John Nielsen wrote: >>>>>> I=E2=80=99m not much of a kernel programmer but I=E2=80=99m = trying to maintain/improve the isboot module, which allows booting = directly from iSCSI by reading the iSCSI Boot Firmware Table (iBFT), = bringing up the interface with the details specified therein and = connecting to the specified iSCSI target before trying to mount root. >>>>>>=20 >>>>>> I=E2=80=99m not the original author but as the port maintainer I = am hosting the code here: https://github.com/jnielsendotnet/isboot = >>>>>>=20 >>>>>> I have a test system where the module loads but fails to find the = iBFT. I reviewed the iBFT code and realized it has a bunch of magic = numbers mixed in with some random memory diving. If I=E2=80=99m reading = it right (see = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 = = and https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521 = ), = it looks like it scans all of the (kernel?) memory between 512K and 1M = in 16-byte increments looking for one beginning with the string = =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as the offset for = reading the table. I don=E2=80=99t know where the 512K and 1M values = came from or if they are correct, but I do have a system where that = method does not work. >>>>>>=20 >>>>>> IIUC, the iBFT is an ACPI table, and it seems like using ACPI to = find it would be safer and more reliable. So my question is: how does = one do that? Are there other places in the kernel code that do this sort = of thing that I could use as a model? Any gotchas I should know about as = a (less-than) novice kernel programmer? >>>>>=20 >>>>> You may use AcpiGetTable() and AcpiPutTable(), e.g., >>>>>=20 >>>>> status =3D AcpiGetTable(ACPI_SIG_IBFT, =E2=80=A6); >>>>=20 >>>> Thank you (and Andriy) for your responses. Good to know that = ACPI_SIG_IBFT is already defined in the upstream headers. >>>=20 >>> It seems there are two methods. >>>=20 >>> = ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware= _table_v1.03.pdf = >>>=20 >>> 1.4.3.1 Locating the iBFT >>>=20 >>> The iBFT is located by the following methods. A platform shall = implement >>> one or more of these methods. >>>=20 >>> 1. The ACPI Method. The iBFT is pointed to by an entry in the = RSDT/XSDT. >>> Note that ACPI [ACPI=3D3.0b] specifies the string in the pointer as >>> =E2=80=9CIBFT=E2=80=9D (all upper case) HOWEVER the signature in the = table being pointed >>> to is=E2=80=9CiBFT=E2=80=9D (note the mixed case). >>>=20 >>> 2. The Low RAM Method. Scan for the table header signature in system >>> memory between 512K and 1024K. The scan MUST be done starting at >>> the lower address scanning forward to the higher address. When using = the >>> Low RAM Method the table header must be aligned on a 16-byte >>> boundary. >>>=20 >>> Note: A system operating in UEFI mode shall utilize only the ACPI = method. >>>=20 >>> For modern system, it seems you should be using Method 1. I don't >>> understand the "HOWEVER" part, though. >>=20 >> I did little more research. It seems iSCSI spec. predates ACPI >> standardization and IBM kept on using "iBFT" instead of ACPI spec. >> "IBFT". Because this confusion, some systems use "iBFT" and some use >> "IBFT". Therefore, it seems you need to test both, e.g., >>=20 >> status =3D AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft); >> if (ACPI_FAILURE(status)) >> status =3D AcpiGetTable("iBFT", 0, &ibft); >=20 > Very helpful once again, thank you. My test machine (either the = motherboard or the NIC) has a buggy BIOS that prevents it from booting = in legacy mode with iSCSI so I=E2=80=99m using UEFI whether I wanted to = or not. I=E2=80=99m glad that my theory that the Low RAM Method might = not work in UEFI has some merit. >=20 > I did notice that Linux looks for both iBFT and IBFT in its driver; = the existence of two standards is alluded to in the comments but it=E2=80=99= s nice to know what they are. I=E2=80=99ll adopt your suggested = approach. In case anyone is actually following along at home, here=E2=80=99s what = I have so far: = https://github.com/jnielsendotnet/isboot/commit/255a01102c345347dece1ed15b= d8675fe3dd1dd9 Which not only compiles but also finds (and is able to correctly decode) = the iBFT on my test system. Hooray! Comments on the patch welcome. Otherwise I=E2=80=99ll move on to the = next issue=E2=80=A6 Thank you again for the help thus far. JN --Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 19, 2021, at 9:41 PM, John Nielsen <lists@jnielsen.net> = wrote:

On May = 19, 2021, at 12:21 PM, Jung-uk Kim <jkim@freebsd.org> wrote:

On 21. 5. 19., Jung-uk Kim wrote:
On = 21. 5. 19., John Nielsen wrote:
On May 17, 2021, at 2:27 = PM, Jung-uk Kim <junguk.kim@gmail.com> wrote:

On 21. 5. 17., John Nielsen wrote:
I=E2=80=99m not much of a kernel programmer but = I=E2=80=99m trying to maintain/improve the isboot module, which allows = booting directly from iSCSI by reading the iSCSI Boot Firmware Table = (iBFT), bringing up the interface with the details specified therein and = connecting to the specified iSCSI target before trying to mount root.

I=E2=80=99m not the original author but as the = port maintainer I am hosting the code here: https://github.com/jnielsendotnet/isboot

I have a test system where the module loads but fails to find = the iBFT. I reviewed the iBFT code and realized it has a bunch of magic = numbers mixed in with some random memory diving. If I=E2=80=99m reading = it right (see https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h= #L37 and https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c= #L521), it looks like it scans all of the (kernel?) memory between = 512K and 1M in 16-byte increments looking for one beginning with the = string =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as the = offset for reading the table. I don=E2=80=99t know where the 512K and 1M = values came from or if they are correct, but I do have a system where = that method does not work.

IIUC, the iBFT = is an ACPI table, and it seems like using ACPI to find it would be safer = and more reliable. So my question is: how does one do that? Are there = other places in the kernel code that do this sort of thing that I could = use as a model? Any gotchas I should know about as a (less-than) novice = kernel programmer?

You may use = AcpiGetTable() and AcpiPutTable(), e.g.,

= status =3D AcpiGetTable(ACPI_SIG_IBFT, =E2=80=A6);

Thank you (and Andriy) for your = responses. Good to know that ACPI_SIG_IBFT is already defined in the = upstream headers.

It seems = there are two methods.

ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_bo= ot_firmware_table_v1.03.pdf

1.4.3.1 = Locating the iBFT

The iBFT is located by = the following methods. A platform shall implement
one or = more of these methods.

1. The ACPI Method. = The iBFT is pointed to by an entry in the RSDT/XSDT.
Note = that ACPI [ACPI=3D3.0b] specifies the string in the pointer as
=E2=80=9CIBFT=E2=80=9D (all upper case) HOWEVER the signature = in the table being pointed
to is=E2=80=9CiBFT=E2=80=9D = (note the mixed case).

2. The Low RAM = Method. Scan for the table header signature in system
memory= between 512K and 1024K. The scan MUST be done starting at
the lower address scanning forward to the higher address. = When using the
Low RAM Method the table header must be = aligned on a 16-byte
boundary.

Note: A system operating in UEFI mode shall utilize only the = ACPI method.

For modern system, it seems = you should be using Method 1.  I don't
understand the = "HOWEVER" part, though.

I did little more research. =  It seems iSCSI spec. predates ACPI
standardization and IBM kept on using "iBFT" instead of ACPI = spec.
"IBFT". =  Because this confusion, some systems use "iBFT" and some = use
"IBFT". =  Therefore, it seems you need to test both, e.g.,

status =3D = AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft);
= if = (ACPI_FAILURE(status))
= status =3D = AcpiGetTable("iBFT", 0, &ibft);

Very helpful once again, thank you. My test = machine (either the motherboard or the NIC) has a buggy BIOS that = prevents it from booting in legacy mode with iSCSI so I=E2=80=99m using = UEFI whether I wanted to or not. I=E2=80=99m glad that my theory that = the Low RAM Method might not work in UEFI has some merit.

I did notice that Linux = looks for both iBFT and IBFT in its driver; the existence of two = standards is alluded to in the comments but it=E2=80=99s nice to know = what they are. I=E2=80=99ll adopt your suggested = approach.

In = case anyone is actually following along at home, here=E2=80=99s what I = have so far:
https://github.com/jnielsendotnet/isboot/commit/255a01102c34534= 7dece1ed15bd8675fe3dd1dd9

Which not only compiles but also finds (and is able to = correctly decode) the iBFT on my test system. Hooray!

Comments on the patch = welcome. Otherwise I=E2=80=99ll move on to the next issue=E2=80=A6

Thank you again for = the help thus far.

JN

= --Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6-- From nobody Thu May 20 18:45:22 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A6E58C5C74 for ; Thu, 20 May 2021 18:45:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmJZx3hhZz3qX9; Thu, 20 May 2021 18:45:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 58C722BD1C; Thu, 20 May 2021 18:45:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: How to properly locate/parse ACPI table from kernel module? To: John Nielsen Cc: "freebsd-acpi@freebsd.org" References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> From: Jung-uk Kim Organization: FreeBSD.org Message-ID: <11e31efe-5d4f-6ad3-c78d-94155d0e0c01@FreeBSD.org> Date: Thu, 20 May 2021 14:45:22 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 In-Reply-To: <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5rHCiLh9Z6MotwDOow71cO7msenb9LjYs" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5rHCiLh9Z6MotwDOow71cO7msenb9LjYs Content-Type: multipart/mixed; boundary="NanaW2UoaYP03tVTssiyo8LuFQ6pLiunF"; protected-headers="v1" From: Jung-uk Kim To: John Nielsen Cc: "freebsd-acpi@freebsd.org" Message-ID: <11e31efe-5d4f-6ad3-c78d-94155d0e0c01@FreeBSD.org> Subject: Re: How to properly locate/parse ACPI table from kernel module? References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> In-Reply-To: <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> --NanaW2UoaYP03tVTssiyo8LuFQ6pLiunF Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 21. 5. 20., John Nielsen wrote: >> On May 19, 2021, at 9:41 PM, John Nielsen > > wrote: >> >>> On May 19, 2021, at 12:21 PM, Jung-uk Kim >> > wrote: >>> >>> On 21. 5. 19., Jung-uk Kim wrote: >>>> On 21. 5. 19., John Nielsen wrote: >>>>>> On May 17, 2021, at 2:27 PM, Jung-uk Kim >>>>> > wrote: >>>>>> >>>>>> On 21. 5. 17., John Nielsen wrote: >>>>>>> I=E2=80=99m not much of a kernel programmer but I=E2=80=99m tryin= g to >>>>>>> maintain/improve the isboot module, which allows booting directly= >>>>>>> from iSCSI by reading the iSCSI Boot Firmware Table (iBFT), >>>>>>> bringing up the interface with the details specified therein and >>>>>>> connecting to the specified iSCSI target before trying to mount r= oot. >>>>>>> >>>>>>> I=E2=80=99m not the original author but as the port maintainer I = am >>>>>>> hosting the code here: https://github.com/jnielsendotnet/isboot >>>>>>> >>>>>>> >>>>>>> I have a test system where the module loads but fails to find the= >>>>>>> iBFT. I reviewed the iBFT code and realized it has a bunch of >>>>>>> magic numbers mixed in with some random memory diving. If I=E2=80= =99m >>>>>>> reading it right (see >>>>>>> https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L= 37 >>>>>>> >>>>>>> and >>>>>>> https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L= 521 >>>>>>> ), >>>>>>> it looks like it scans all of the (kernel?) memory between 512K >>>>>>> and 1M in 16-byte increments looking for one beginning with the >>>>>>> string =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as = the offset for >>>>>>> reading the table. I don=E2=80=99t know where the 512K and 1M val= ues came >>>>>>> from or if they are correct, but I do have a system where that >>>>>>> method does not work. >>>>>>> >>>>>>> IIUC, the iBFT is an ACPI table, and it seems like using ACPI to >>>>>>> find it would be safer and more reliable. So my question is: how >>>>>>> does one do that? Are there other places in the kernel code that >>>>>>> do this sort of thing that I could use as a model? Any gotchas I >>>>>>> should know about as a (less-than) novice kernel programmer? >>>>>> >>>>>> You may use AcpiGetTable() and AcpiPutTable(), e.g., >>>>>> >>>>>> status =3D AcpiGetTable(ACPI_SIG_IBFT, =E2=80=A6); >>>>> >>>>> Thank you (and Andriy) for your responses. Good to know that >>>>> ACPI_SIG_IBFT is already defined in the upstream headers. >>>> >>>> It seems there are two methods. >>>> >>>> ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_fi= rmware_table_v1.03.pdf >>>> >>>> >>>> 1.4.3.1 Locating the iBFT >>>> >>>> The iBFT is located by the following methods. A platform shall imple= ment >>>> one or more of these methods. >>>> >>>> 1. The ACPI Method. The iBFT is pointed to by an entry in the RSDT/X= SDT. >>>> Note that ACPI [ACPI=3D3.0b] specifies the string in the pointer as >>>> =E2=80=9CIBFT=E2=80=9D (all upper case) HOWEVER the signature in the= table being pointed >>>> to is=E2=80=9CiBFT=E2=80=9D (note the mixed case). >>>> >>>> 2. The Low RAM Method. Scan for the table header signature in system= >>>> memory between 512K and 1024K. The scan MUST be done starting at >>>> the lower address scanning forward to the higher address. When using= the >>>> Low RAM Method the table header must be aligned on a 16-byte >>>> boundary. >>>> >>>> Note: A system operating in UEFI mode shall utilize only the ACPI >>>> method. >>>> >>>> For modern system, it seems you should be using Method 1. =C2=A0I do= n't >>>> understand the "HOWEVER" part, though. >>> >>> I did little more research. =C2=A0It seems iSCSI spec. predates ACPI >>> standardization and IBM kept on using "iBFT" instead of ACPI spec. >>> "IBFT". =C2=A0Because this confusion, some systems use "iBFT" and som= e use >>> "IBFT". =C2=A0Therefore, it seems you need to test both, e.g., >>> >>> status =3D AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft); >>> if (ACPI_FAILURE(status)) >>> status =3D AcpiGetTable("iBFT", 0, &ibft); >> >> Very helpful once again, thank you. My test machine (either the >> motherboard or the NIC) has a buggy BIOS that prevents it from booting= >> in legacy mode with iSCSI so I=E2=80=99m using UEFI whether I wanted t= o or >> not. I=E2=80=99m glad that my theory that the Low RAM Method might not= work in >> UEFI has some merit. >> >> I did notice that Linux looks for both iBFT and IBFT in its driver; >> the existence of two standards is alluded to in the comments but it=E2= =80=99s >> nice to know what they are. I=E2=80=99ll adopt your suggested approach= =2E >=20 > In case anyone is actually following along at home, here=E2=80=99s what= I have > so far: > https://github.com/jnielsendotnet/isboot/commit/255a01102c345347dece1ed= 15bd8675fe3dd1dd9 > >=20 > Which not only compiles but also finds (and is able to correctly decode= ) > the iBFT on my test system. Hooray! Good to hear it. > Comments on the patch welcome. Otherwise I=E2=80=99ll move on to the ne= xt issue=E2=80=A6 You don't need to define USE_ACPI. It should be spelled "DEV_ACPI", e.g.= , #ifndef DEV_ACPI > Thank you again for the help thus far. Glad to help. Jung-uk Kim --NanaW2UoaYP03tVTssiyo8LuFQ6pLiunF-- --5rHCiLh9Z6MotwDOow71cO7msenb9LjYs Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmCmrkIFAwAAAAAACgkQfJ+WJvzb8UZy Mgf/WQa4THlBCXO2VyFmUzYQpr89hTQLQ/qaHw5dlSy/QxA5Iv/DSRHqVreL58Xi03o5ZQvdmloy UPODuv/N0Dug5Hh8mIJb9VvNEoj8SScqUbWugX2k86aZLFxbqCKMdIbhN4QOz8v4VyKx86/cjYoI F61GURht9HBiMb+PTMfWh+eQ5hSXyd8la4+qb6DprpAsIRNVxd1BJnfvjWimSCuEy1faNfli/PQE +7Se3rZtRnFg8KBNPjlxyfWwHUywDziiQTke/O2Qqqd5TtnA7QT1eF/pfOws/l3NuF5+KYUuLuif DAIV5xmeISNzlwsj728FrTWsQBJ4s5EETQtHFc54eg== =SEiW -----END PGP SIGNATURE----- --5rHCiLh9Z6MotwDOow71cO7msenb9LjYs-- From nobody Mon May 24 03:43:08 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F405F9F99E9 for ; Mon, 24 May 2021 03:43:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpNMw4n0qz4gLp for ; Mon, 24 May 2021 03:43:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8B2602370E for ; Mon, 24 May 2021 03:43:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14O3h8Sj051933 for ; Mon, 24 May 2021 03:43:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14O3h8Ie051932 for acpi@FreeBSD.org; Mon, 24 May 2021 03:43:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 255132] ACPI: different function key maps to same devd notify code Date: Mon, 24 May 2021 03:43:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255132 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |acpi@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue May 25 18:25:01 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8158EBF749A for ; Tue, 25 May 2021 18:25:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FqMv12hvdz4QnL for ; Tue, 25 May 2021 18:25:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 40BC4225B5 for ; Tue, 25 May 2021 18:25:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14PIP1qp014781 for ; Tue, 25 May 2021 18:25:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14PIP1ug014780 for acpi@FreeBSD.org; Tue, 25 May 2021 18:25:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 255132] ACPI: different function key maps to same devd notify code Date: Tue, 25 May 2021 18:25:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: georg.lastname@web.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255132 georg.lastname@web.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |georg.lastname@web.de --- Comment #1 from georg.lastname@web.de --- Are you using acpi_ibm module? If you are in Xorg, some key presses might appear in xev (e.g. as XF86AudioLowerVolume). In that case hotkeys can be handled by the window manager as well. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 2 19:58:28 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 32C0DE7E6A8 for ; Wed, 2 Jun 2021 19:58:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwKb80qqBz4fd8 for ; Wed, 2 Jun 2021 19:58:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 00DA91C9F4 for ; Wed, 2 Jun 2021 19:58:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 152JwRPL091227 for ; Wed, 2 Jun 2021 19:58:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 152JwRHw091226 for acpi@FreeBSD.org; Wed, 2 Jun 2021 19:58:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 256389] [PATCH] acpi: Include Samsung laptops in the x2APIC Sandy Bridge blacklist Date: Wed, 02 Jun 2021 19:58:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: easy X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256389 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |acpi@FreeBSD.org Keywords| |easy --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 2 22:45:50 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C01F512A271A for ; Wed, 2 Jun 2021 22:45:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwPJG4dXYz3BsN for ; Wed, 2 Jun 2021 22:45:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7F68C1F24C for ; Wed, 2 Jun 2021 22:45:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 152Mjod9085306 for ; Wed, 2 Jun 2021 22:45:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 152MjowD085305 for acpi@FreeBSD.org; Wed, 2 Jun 2021 22:45:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 256389] [PATCH] acpi: Include Samsung laptops in the x2APIC Sandy Bridge blacklist Date: Wed, 02 Jun 2021 22:45:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: easy X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256389 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #1 from Konstantin Belousov --- I did some additional refactoring, please see https://reviews.freebsd.org/D30624 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Jun 3 16:08:05 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B017DEA9F1B for ; Thu, 3 Jun 2021 16:08:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwrQs4TwWz3nmR for ; Thu, 3 Jun 2021 16:08:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7E4704CAF for ; Thu, 3 Jun 2021 16:08:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 153G85R8023322 for ; Thu, 3 Jun 2021 16:08:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 153G85AI023321 for acpi@FreeBSD.org; Thu, 3 Jun 2021 16:08:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 256389] [PATCH] acpi: Include Samsung laptops in the x2APIC Sandy Bridge blacklist Date: Thu, 03 Jun 2021 16:08:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: easy X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dasebek@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256389 --- Comment #2 from David Sebek --- (In reply to Konstantin Belousov from comment #1) I tested the refactored patch. It works. Thank you! --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Jun 3 19:48:20 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BCBDC1371C29 for ; Thu, 3 Jun 2021 19:48:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwxK02dZpz4jdY for ; Thu, 3 Jun 2021 19:48:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 40CE97CBD for ; Thu, 3 Jun 2021 19:48:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 153JmKJd038280 for ; Thu, 3 Jun 2021 19:48:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 153JmKCo038279 for acpi@FreeBSD.org; Thu, 3 Jun 2021 19:48:20 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 256389] [PATCH] acpi: Include Samsung laptops in the x2APIC Sandy Bridge blacklist Date: Thu, 03 Jun 2021 19:48:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: easy X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256389 --- Comment #3 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D37f780d3e0a2e8e4c64c526b6e7dc77ff= 6b91057 commit 37f780d3e0a2e8e4c64c526b6e7dc77ff6b91057 Author: Konstantin Belousov AuthorDate: 2021-06-02 22:29:07 +0000 Commit: Konstantin Belousov CommitDate: 2021-06-03 19:47:31 +0000 Disable x2APIC for SandyBridge laptops with Samsung BIOS From the PR: Almost always, my Samsung RF511 laptop could not boot with x2APIC enabled in the kernel. It froze during SMP initialization, shortly after "ACPI APIC Table: " was printed to the console. When the kernel is instructed not to use x2APIC, the system boots correctly. PR: 256389 Submitted by: David Sebek Reviewed by: markj MFC after: 1 week Differential revision: https://reviews.freebsd.org/D30624 sys/x86/acpica/madt.c | 1 + 1 file changed, 1 insertion(+) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jun 6 19:34:17 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F417960DC7 for ; Sun, 6 Jun 2021 19:34:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FymsP26Ftz3ndb for ; Sun, 6 Jun 2021 19:34:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 30BD61381 for ; Sun, 6 Jun 2021 19:34:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 156JYHqW001473 for ; Sun, 6 Jun 2021 19:34:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 156JYHOV001472 for acpi@FreeBSD.org; Sun, 6 Jun 2021 19:34:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 256389] [PATCH] acpi: Include Samsung laptops in the x2APIC Sandy Bridge blacklist Date: Sun, 06 Jun 2021 19:34:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: easy X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256389 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org Assignee|acpi@FreeBSD.org |kib@FreeBSD.org Status|New |In Progress --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Aug 17 20:18:19 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0536C175B52B for ; Tue, 17 Aug 2021 20:36:09 +0000 (UTC) (envelope-from freebsd-acpi@freebsd.org) Received: from hwsrv-899554.hostwindsdns.com (hwsrv-899554.hostwindsdns.com [IPv6:2607:5500:3000:1404::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4Gq2qX6dxjz3tlT for ; Tue, 17 Aug 2021 20:36:08 +0000 (UTC) (envelope-from freebsd-acpi@freebsd.org) Received: from cmhseci.org (localhost [IPv6:::1]) by hwsrv-899554.hostwindsdns.com (Postfix) with ESMTP id 9830C1BF4D for ; Tue, 17 Aug 2021 20:18:19 +0000 (UTC) From: Admin To: freebsd-acpi@freebsd.org Subject: Updated August salary review (Final Post-Covid-19 listing) Date: 17 Aug 2021 22:18:19 +0200 Message-ID: <20210817221818.E18F509974C7A61B@freebsd.org> List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Gq2qX6dxjz3tlT X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:54290, ipnet:2607:5500::/32, country:US] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y

 Dear freebsd-acpi,

   
    As already announced, The year's Wage increase will start in = August of 2021
    and will be paid out for the first time by = August, with recalculation as of July.

   

    salary-increase-sheet-August-20= 21.xls       &= nbsp;

   
    You will be informed of the details in advance by letter from= the HR department.

    regards
   =  freebsd.org HR
  

From nobody Mon Aug 30 23:54:07 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D27D17AF29A for ; Mon, 30 Aug 2021 23:54:23 +0000 (UTC) (envelope-from freebsd-acpi@freebsd.org) Received: from spfilter-3.sel01.mschosting.com (spfilter3-out3.sel01.mschosting.com [110.4.44.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gz6cG3FSvz3QLs for ; Mon, 30 Aug 2021 23:54:22 +0000 (UTC) (envelope-from freebsd-acpi@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spamexpertfilterl.mschosting.com; s=default; h=Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:reply-to:sender:cc: bcc:in-reply-to:references; bh=+vsAdGh6RJPX97/mk192SbQ64AnrFPtoXL4Pmqp3oAs=; b=jBUBTfuPknsd7wyQpl17njQVFSjDwUW37yoDSqV7BeX0lEsNpTiUbv5w+MaBoKSKWXQ3CLGgcv uPmPaU/ygDMtGlBtr+yrhONpz3+b8jef1V66T2CsbVL/P9EpMLMtzh1iakyafP7E8F5elAmnZ7Oir dqRxk2TmAS43jRJuJ2gA=; Received: from stormbreaker.mschosting.com ([103.6.198.89]) by spfilter-3.sel01.mschosting.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1mKr6O-0001AW-NQ for freebsd-acpi@freebsd.org; Tue, 31 Aug 2021 07:54:12 +0800 Received: from [212.192.241.141] (port=61322 helo=un.org) by stormbreaker.mschosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mKr6O-0006Uu-DK for freebsd-acpi@freebsd.org; Tue, 31 Aug 2021 07:54:07 +0800 From: E-mail Alert freebsd.org < freebsd-acpi@freebsd.org > To: freebsd-acpi@freebsd.org Subject: URGENT ATTENTION FOR freebsd-acpi@freebsd.org FROM SERVER freebsd.org Date: 31 Aug 2021 01:54:07 +0200 Message-ID: <20210831015407.2809E3ADC3C4B3D2@freebsd.org> List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-AuthUser: info@indahbumi.com X-Originating-IP: 103.6.198.89 X-SpamExperts-Domain: spamexpertfilterl.mschosting.com X-SpamExperts-Username: 103.6.198.89 X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.83) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8CiQX64INFl4znjAISWjwhPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wpF2Fd8pX4vemNwWK5+xR7AGbzAVrSFcM5kIiaOGXII7gN zB/4Jkrw1eDLcif59futKLny546ImG6tkwKPGN9XgYVALhXkueKT79r7FRLqfb863SpzGY3/o1VO YDlxH7bjodNYx15xVaICKFJ6KgiVZ96c66QPfXDOjE0uwP6rBH7ZWJkyjooKhLdDeVoBUZ2ExhZK g1yzDNZ/zbSvv1LshAGdpDDBhExcAXhbDyDsvd4LP6XepZN8VWJ303pfUylXQFOX0czP0M0FvfyK B99w+tYk7MnyW6QsekNAAVuBOGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4 tVHU1Zldyy+zfUoG8ApAGtnARcOCU5LFbg83Uq6lmzeN8BmPLJ9AsueO6+MR9Nol7RZuMNLAjhWw OH8CTlQwpHklpufi6pZ4ylUWDjsOSJdImWogkWyF713iRpl6t7rUo9nmwzOdTgK2ycqbteUxbTBb yGUa9rYMr+cZIKC9G3JBLnu48CZ5VbHJ2OUMeHyTpNN0eXybX/w7//Zvfrj9M8hBE8kGoYdZPbtq JtMVW/aC90eaO6IHXf2dtG+JKqAZOE/psqT2+8B5dt37wLuRRYCe/TscGPtsaL1f9athHn9nW6GW uxQchlGUR5YnqJxYjccyewgPLSHSI19L2zldRguLVknTBH19KmZPvhkSot3yX0Uz6/z7iRxNROKd yybV3OVeQ6HuOK8dqaUis6oWPztMBsTuIAj0JaL10mLF/SCXnjjc8Lx0r2LvjXy9gcAcIFYdt8EG WYMV69bcvMpClbqk6g9np4Awivo2/xvimmR+jeFoW2hE2OKV7sn+WPAZWuahsYMfUiOelSUKRK6O bnxr/EH5cLWQJzoaVoKvDvy+IDRFCU0SJJs3XZ0VrhMtn7BHaVLCrubA3CzS555JC/eJE0J20PW7 DIALEzVYDRyDg9J61iaa9Oq4rAER5w9U6IouI8DpgWhi/49yYjkgur7cbmMvzASyKBF/atFUtE0y pyCdDGMRwlRTXjY1HST9ZtIOqBaVtf6IBXii07T4YjLFruZMfnLuYZ8= X-Report-Abuse-To: spam@spfilter-1.sel01.mschosting.com X-Rspamd-Queue-Id: 4Gz6cG3FSvz3QLs X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:46015, ipnet:110.4.44.0/24, country:MY]; local_wl_from(0.00)[freebsd.org] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y

At 8/31/= 2021 1:54:07 a.m.,= Your eMail account freebsd-acpi@fre= ebsd.org  Failed to sync and = returned 10 Incoming Messages.

Sync failures occur when a eMail user has not U= pgraded his/her eMail account in 90 days..

To avoid D e-activati= on&n= bsp;of this eMail account kindly click below to retrieve & free pending= messages back to your inbox.

Click here to resolve


To Verify your account in one simple step and prevent a re-occurrence, plea= se click here.


©2020 Microsoft

8/31/2021 1:54:07 a.m.

From nobody Tue Oct 12 04:51:57 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C0CFD17B7786 for ; Tue, 12 Oct 2021 04:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HT3DF46Wmz3L5t for ; Tue, 12 Oct 2021 04:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6E9AE64E6 for ; Tue, 12 Oct 2021 04:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19C4pvgZ009008 for ; Tue, 12 Oct 2021 04:51:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19C4pvPM009007 for acpi@FreeBSD.org; Tue, 12 Oct 2021 04:51:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 255362] ACPI errors Date: Tue, 12 Oct 2021 04:51:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255362 sid@bsdmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #2 from sid@bsdmail.com --- Thank you. I'll close this. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Oct 12 04:52:13 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DC70E17B755B for ; Tue, 12 Oct 2021 04:52:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HT3DY4w35z3LTh for ; Tue, 12 Oct 2021 04:52:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7F432671B for ; Tue, 12 Oct 2021 04:52:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19C4qDYH009090 for ; Tue, 12 Oct 2021 04:52:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19C4qDx2009089 for acpi@FreeBSD.org; Tue, 12 Oct 2021 04:52:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 255362] ACPI errors Date: Tue, 12 Oct 2021 04:52:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255362 sid@bsdmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |Works As Intended --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Oct 21 17:43:18 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 46D5817F4B31 for ; Thu, 21 Oct 2021 17:43:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HZvw61T9bz3KqT for ; Thu, 21 Oct 2021 17:43:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 12D2B1F899 for ; Thu, 21 Oct 2021 17:43:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19LHhIRI031378 for ; Thu, 21 Oct 2021 17:43:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19LHhIn4031377 for acpi@FreeBSD.org; Thu, 21 Oct 2021 17:43:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 255194] acpi_ibm on Thinkpad T495: driver bug: Unable to set Date: Thu, 21 Oct 2021 17:43:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ali.abdallah@suse.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255194 Ali Abdallah changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ali.abdallah@suse.com --- Comment #1 from Ali Abdallah --- I have the same Thinkpad mode, acpi_ibm inserts fine for me. For what concerns the following acpi_ec0 no hardware response errors, you c= an enable burst mode to get rid of the problem (debug.acpi.ec.burst=3D1) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Nov 14 01:24:30 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3CAF9184DBA2 for ; Sun, 14 Nov 2021 01:24:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HsF3f12r0z4SWs for ; Sun, 14 Nov 2021 01:24:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 04C411DB94 for ; Sun, 14 Nov 2021 01:24:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1AE1OTO7083336 for ; Sun, 14 Nov 2021 01:24:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AE1OT08083335 for acpi@FreeBSD.org; Sun, 14 Nov 2021 01:24:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: maintainer-feedback requested: [Bug 259825] acpi: Toshiba Satelite L505D-LS501 fails to install: firmware error (ACPI) Could not resolve symbol [\_GPE._L07.RS*F] AE_NOT_FOUND Date: Sun, 14 Nov 2021 01:24:30 +0000 X-Bugzilla-Type: request X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable13? mfc-stable12? Message-ID: In-Reply-To: References: X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N Kubilay Kocak has asked freebsd-acpi (Nobody) for maintainer-feedback: Bug 259825: acpi: Toshiba Satelite L505D-LS501 fails to install: firmware e= rror (ACPI) Could not resolve symbol [\_GPE._L07.RS*F] AE_NOT_FOUND https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259825 --- Comment #1 from Kubilay Kocak --- Thank you for the report Thomas.=20 Are you able to test installing 13-STABLE and 14.0-CURRENT snapshot images from: https://download.freebsd.org/ftp/snapshots/amd64/ From nobody Sun Nov 14 01:24:30 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6D5AC184DB13 for ; Sun, 14 Nov 2021 01:24:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HsF3f2V4Yz4SDP for ; Sun, 14 Nov 2021 01:24:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3569C1DCF5 for ; Sun, 14 Nov 2021 01:24:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1AE1OUaI083345 for ; Sun, 14 Nov 2021 01:24:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AE1OUt4083344 for acpi@FreeBSD.org; Sun, 14 Nov 2021 01:24:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 259825] acpi: Toshiba Satelite L505D-LS501 fails to install: firmware error (ACPI) Could not resolve symbol [\_GPE._L07.RS*F] AE_NOT_FOUND Date: Sun, 14 Nov 2021 01:24:30 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable13? mfc-stable12? X-Bugzilla-Changed-Fields: short_desc assigned_to bug_status flagtypes.name keywords cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259825 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|ACPI |acpi: Toshiba Satelite | |L505D-LS501 fails to | |install: firmware error | |(ACPI) Could not resolve | |symbol [\_GPE._L07.RS*F] | |AE_NOT_FOUND Assignee|bugs@FreeBSD.org |acpi@FreeBSD.org Status|New |Open Flags| |maintainer-feedback?(acpi@F | |reeBSD.org), mfc-stable13?, | |mfc-stable12? Keywords| |needs-qa CC| |acpi@FreeBSD.org --- Comment #1 from Kubilay Kocak --- Thank you for the report Thomas.=20 Are you able to test installing 13-STABLE and 14.0-CURRENT snapshot images from: https://download.freebsd.org/ftp/snapshots/amd64/ --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From nobody Sun Nov 14 01:25:25 2021 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A6208184E13D for ; Sun, 14 Nov 2021 01:25:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HsF4j47dKz4Sx9 for ; Sun, 14 Nov 2021 01:25:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6DF161DD8B for ; Sun, 14 Nov 2021 01:25:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1AE1PP7T083524 for ; Sun, 14 Nov 2021 01:25:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AE1PP1V083523 for acpi@FreeBSD.org; Sun, 14 Nov 2021 01:25:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 259825] acpi: Toshiba Satelite L505D-LS501 fails to install: firmware error (ACPI) Could not resolve symbol [\_GPE._L07.RS*F] AE_NOT_FOUND Date: Sun, 14 Nov 2021 01:25:25 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable13? mfc-stable12? X-Bugzilla-Changed-Fields: component Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259825 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Component|misc |kern --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=