| Message ID | 1327962588-5230-1-git-send-email-agraf@suse.de |
|---|---|
| State | New |
| Headers | show |
Hi Alex, Am 30.01.2012 23:29, schrieb Alexander Graf: > When using Windows 8 with an AHCI disk drive, it issues a blue screen. > The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not > supported by our ATA implementation, but Windows expects it to be there. > > Since without security stuff implemented, the lock would be a nop anyway > and CFA_WEAR_LEVEL already is treated as a nop, let's just allow the cmd > for HD drives as well. That way Windows is happy. I tested this with Windows 2008 R2 and it does not resolve the blue screen I'm getting there during installation. Unfortunately it reboots so quickly that I cannot read what it says. Could you share how you debugged your Windows 8 issue? Andreas > > Signed-off-by: Alexander Graf <agraf@suse.de> > --- > hw/ide/core.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/ide/core.c b/hw/ide/core.c > index 56b219b..2c129f4 100644 > --- a/hw/ide/core.c > +++ b/hw/ide/core.c > @@ -969,7 +969,7 @@ static const uint8_t ide_cmd_table[0x100] = { > [WIN_IDENTIFY] = ALL_OK, > [WIN_SETFEATURES] = ALL_OK, > [IBM_SENSE_CONDITION] = CFA_OK, > - [CFA_WEAR_LEVEL] = CFA_OK, > + [CFA_WEAR_LEVEL] = HD_CFA_OK, > [WIN_READ_NATIVE_MAX] = ALL_OK, > }; >
On 07.02.2012, at 15:57, Andreas Färber wrote: > Hi Alex, > > Am 30.01.2012 23:29, schrieb Alexander Graf: >> When using Windows 8 with an AHCI disk drive, it issues a blue screen. >> The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not >> supported by our ATA implementation, but Windows expects it to be there. >> >> Since without security stuff implemented, the lock would be a nop anyway >> and CFA_WEAR_LEVEL already is treated as a nop, let's just allow the cmd >> for HD drives as well. That way Windows is happy. > > I tested this with Windows 2008 R2 and it does not resolve the blue > screen I'm getting there during installation. Unfortunately it reboots > so quickly that I cannot read what it says. Phew, that's probably yet another issue then. > Could you share how you debugged your Windows 8 issue? I enabled printf debugging in hw/ide/core.c and looked through the commands close to the blue screen :) Alex
Am 30.01.2012 23:29, schrieb Alexander Graf: > When using Windows 8 with an AHCI disk drive, it issues a blue screen. > The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not > supported by our ATA implementation, but Windows expects it to be there. Is there anything that makes Windows believe that we support it? The spec says bits in IDENTIFY word 82 and 128 must be set to indicate support for the security feature set, and we don't set those. Might be just a Windows bug, of course... > Since without security stuff implemented, the lock would be a nop anyway > and CFA_WEAR_LEVEL already is treated as a nop, let's just allow the cmd > for HD drives as well. That way Windows is happy. It sets the sector count register to 0, which isn't exactly nop. In any case, the code would at the very least need a comment that it's used for two separate commands, so that we still remember this when some time in the future someone writes a real implementation. Kevin
On 09.02.2012, at 15:28, Kevin Wolf wrote: > Am 30.01.2012 23:29, schrieb Alexander Graf: >> When using Windows 8 with an AHCI disk drive, it issues a blue screen. >> The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not >> supported by our ATA implementation, but Windows expects it to be there. > > Is there anything that makes Windows believe that we support it? The > spec says bits in IDENTIFY word 82 and 128 must be set to indicate > support for the security feature set, and we don't set those. > > Might be just a Windows bug, of course... IIUC it's mandatory in more recent ATA versions, so that's probably why it assumes it's there. > >> Since without security stuff implemented, the lock would be a nop anyway >> and CFA_WEAR_LEVEL already is treated as a nop, let's just allow the cmd >> for HD drives as well. That way Windows is happy. > > It sets the sector count register to 0, which isn't exactly nop. In any > case, the code would at the very least need a comment that it's used for > two separate commands, so that we still remember this when some time in > the future someone writes a real implementation. Hrm. Good point. Alex
Am 09.02.2012 15:49, schrieb Alexander Graf: > > On 09.02.2012, at 15:28, Kevin Wolf wrote: > >> Am 30.01.2012 23:29, schrieb Alexander Graf: >>> When using Windows 8 with an AHCI disk drive, it issues a blue screen. >>> The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not >>> supported by our ATA implementation, but Windows expects it to be there. >> >> Is there anything that makes Windows believe that we support it? The >> spec says bits in IDENTIFY word 82 and 128 must be set to indicate >> support for the security feature set, and we don't set those. >> >> Might be just a Windows bug, of course... > > IIUC it's mandatory in more recent ATA versions, so that's probably why it assumes it's there. ACS-2 says it's optional for both ATA and ATAPI devices. Kevin
On 09.02.2012, at 15:59, Kevin Wolf wrote: > Am 09.02.2012 15:49, schrieb Alexander Graf: >> >> On 09.02.2012, at 15:28, Kevin Wolf wrote: >> >>> Am 30.01.2012 23:29, schrieb Alexander Graf: >>>> When using Windows 8 with an AHCI disk drive, it issues a blue screen. >>>> The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not >>>> supported by our ATA implementation, but Windows expects it to be there. >>> >>> Is there anything that makes Windows believe that we support it? The >>> spec says bits in IDENTIFY word 82 and 128 must be set to indicate >>> support for the security feature set, and we don't set those. >>> >>> Might be just a Windows bug, of course... >> >> IIUC it's mandatory in more recent ATA versions, so that's probably why it assumes it's there. > > ACS-2 says it's optional for both ATA and ATAPI devices. Ah, right. I was looking at the "Historical Command Assignments" table and figured C means it's required, but that of course is wrong. Then I seriously have no idea why Windows is erroring out here. I mean, it does work just fine for IDE devices. And we don't tell the guest anything special for AHCI. Alex
On 09.02.2012, at 15:28, Kevin Wolf wrote: > Am 30.01.2012 23:29, schrieb Alexander Graf: >> When using Windows 8 with an AHCI disk drive, it issues a blue screen. >> The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not >> supported by our ATA implementation, but Windows expects it to be there. > > Is there anything that makes Windows believe that we support it? The > spec says bits in IDENTIFY word 82 and 128 must be set to indicate > support for the security feature set, and we don't set those. > > Might be just a Windows bug, of course... That's what I would assume, since it only occurs with AHCI, but not with the normal IDE driver. The bug still exists with the current customer preview though. > >> Since without security stuff implemented, the lock would be a nop anyway >> and CFA_WEAR_LEVEL already is treated as a nop, let's just allow the cmd >> for HD drives as well. That way Windows is happy. > > It sets the sector count register to 0, which isn't exactly nop. In any > case, the code would at the very least need a comment that it's used for > two separate commands, so that we still remember this when some time in > the future someone writes a real implementation. Alrighty, done :). Alex
diff --git a/hw/ide/core.c b/hw/ide/core.c index 56b219b..2c129f4 100644 --- a/hw/ide/core.c +++ b/hw/ide/core.c @@ -969,7 +969,7 @@ static const uint8_t ide_cmd_table[0x100] = { [WIN_IDENTIFY] = ALL_OK, [WIN_SETFEATURES] = ALL_OK, [IBM_SENSE_CONDITION] = CFA_OK, - [CFA_WEAR_LEVEL] = CFA_OK, + [CFA_WEAR_LEVEL] = HD_CFA_OK, [WIN_READ_NATIVE_MAX] = ALL_OK, };
When using Windows 8 with an AHCI disk drive, it issues a blue screen. The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not supported by our ATA implementation, but Windows expects it to be there. Since without security stuff implemented, the lock would be a nop anyway and CFA_WEAR_LEVEL already is treated as a nop, let's just allow the cmd for HD drives as well. That way Windows is happy. Signed-off-by: Alexander Graf <agraf@suse.de> --- hw/ide/core.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)