From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <558b5fd4f39a7820a67adedd78f94483@coraid.com> References: <53C11780-938A-4F11-B94A-032414483EA7@9srv.net> <558b5fd4f39a7820a67adedd78f94483@coraid.com> Date: Mon, 19 Aug 2013 11:17:01 -0700 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c309aa580bcf04e450f271 Subject: Re: [9fans] the mysterious bios change Topicbox-Message-UUID: 729b1452-ead8-11e9-9d60-3106f5b1d025 --001a11c309aa580bcf04e450f271 Content-Type: text/plain; charset=ISO-8859-1 it is possible that i could have built a new 9pccpuf after the initial boot of the fs and installed it in place but had never rebooted the machine with the new kernel; but (old age memory failings notwithstanding), i don't think i did that. FYI, i think i noticed that in ata compatibility mode vid/did is 8086/2920 and in ahci mode it shows 8086/2922. in the version of sources i have, sdata.c checks for the former and sdiahci.c checks for the latter. On Mon, Aug 19, 2013 at 9:53 AM, erik quanstrom wrote: > On Mon Aug 19 12:25:33 EDT 2013, a@9srv.net wrote: > > Erik's explanation certainly makes sense, but here's an > > alternative possibility. In the past, I've set up the bios on > > a system a certain way, then accidentally written to > > #r/nvram (which isn't really useful on a PC), and had the > > bios reset to factory defaults. Behavior of the bios after > > writing that file is bios-dependent, but it's easy to test. > > i happen to have that machine, and i have not seen that > behavior with any version of bios up to 1.2a. > > perhaps we haven't written to #r/nvram. > > - erik > > --001a11c309aa580bcf04e450f271 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
it is possible that i could have built a new 9pccpuf after= the initial boot of the fs and installed it in place but had never reboote= d the machine with the new kernel; but (old age memory failings notwithstan= ding), i don't think i did that.

FYI, i think i noticed that in ata compatibility mode vid/di= d is 8086/2920 and in ahci mode it shows 8086/2922. in the version of sourc= es i have, sdata.c checks for the former and sdiahci.c checks for the latte= r.


On Mon,= Aug 19, 2013 at 9:53 AM, erik quanstrom <quanstro@labs.coraid.com<= /a>> wrote:
On M= on Aug 19 12:25:33 EDT 2013, a@9srv.net w= rote:
> Erik's explanation certainly makes sense, but here's an
> alternative possibility. In the past, I've set up the bios on
> a system a certain way, then accidentally written to
> #r/nvram (which isn't really useful on a PC), and had the
> bios reset to factory defaults. Behavior of the bios after
> writing that file is bios-dependent, but it's easy to test.

i happen to have that machine, and i have not seen that
behavior with any version of bios up to 1.2a.

perhaps we haven't written to #r/nvram.

- erik


--001a11c309aa580bcf04e450f271--