[9fans] the mysterious bios change

[Skip Tavakkolian]

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

[erik quanstrom]

Post by Skip Tavakkolian
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

[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

[erik quanstrom]

Post by 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.

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

[Skip Tavakkolian]

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.

Post by erik quanstrom

Post by 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.

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