[9fans] the mysterious bios change

[9fans] the mysterious bios change

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

i had a small panic on Friday, when a venti+fossil fs (a supermicro
5015A-EHF-D525 box) had an unexplained reboot followed by what appeared to
be a disk problem. on inspection -- by IL booting it from an un-retired
kenfs -- i noticed that the sd controller position had changed from sdE0 to
sdC0.

suspecting the bios setup, i checked the sata settings in bios, and the
first controller was set to ata rather than ahci.

although i'm happy it wasn't a bad disk, it bugs me that i don't know how
the bios could have changed by itself. has anyone seen this before?

-Skip

[-- Attachment #2: Type: text/html, Size: 775 bytes --]

Re: [9fans] the mysterious bios change

[erik quanstrom]

On Sun Aug 18 12:42:54 EDT 2013, skip.tavakkolian@gmail.com wrote:

> i had a small panic on Friday, when a venti+fossil fs (a supermicro
> 5015A-EHF-D525 box) had an unexplained reboot followed by what appeared to
> be a disk problem. on inspection -- by IL booting it from an un-retired
> kenfs -- i noticed that the sd controller position had changed from sdE0 to
> sdC0.
>
> suspecting the bios setup, i checked the sata settings in bios, and the
> first controller was set to ata rather than ahci.

i suspect that this is caused not by a bios change, but by some subtile confusion.

there are two different ways a drive can show up as sdE0.  first, as an ide driver
that is showing up in pci space, and not the blindly-probed ide addresses and
second as an ahci device.  the hardware supports both modes, so with the right
combination of bios settings and drivers, the same hardware could be used as
either ahci or ide without fiddling bios.  this may have to do with which vids and
dids are in your version of the ahci driver.

we have about 10 of these machines running around running standard 9atom nix
kernels with bios selected to be compatable/ahci.  once booted, the configuration
looks like the following:

consoled; aux/dmi -t 1
1: type sysinfo 1 len 27 handle 1
	mfg         	Supermicro
	product     	X7SPA-HF
	version     	1234567890
	serial      	1234567890
	uuid        	534D434900026490250064902500D660
	waketype    	powersw (0x6)
	sku         	To Be Filled By O.E.M.
	family      	<nil>
consoled; pci|grep disk
0.31.2:	disk 01.06.01 8086/2922  14 0:0000b481 16 1:0000c001 16 2:0000bc01 16 3:0000b881 16 4:0000b801 32 5:febfb000 2048
consoled; cat /dev/sdctl
sdE ahci ahci port 0xfffffe00febfb000: 64a ncq ntf ss alp led clo pmb slum pslum coal ems xs alhd xonly smb elmt iss 2 ncs 31 np 6 ghc 80000002 isr 0 pi 3f 0-5 ver 10200

i hope that helps.  it may be just a matter of commenting out a few lines in the
ide driver, though one could likely solve the issue with a bios change as well.

- erik

Re: [9fans] the mysterious bios change

[Anthony Sorace]

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.
Anthony

Re: [9fans] the mysterious bios change

[erik quanstrom]

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

Re: [9fans] the mysterious bios change

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

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 <quanstro@labs.coraid.com>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
>
>

[-- Attachment #2: Type: text/html, Size: 1696 bytes --]