Problem with Hyper-V, NCQ SATA drives; Event ID 129 from nvstor64 saying "Reset to device, \Device\R

[Bruce Sanderson]

This post is related to the one on 5 Jun 2008, but I think I asked the wrong
question in that one!

The operating system is Windows Server 2008 RTM with the RTM version of the
Hyper-V role installed (Windows6.0-KB950050-x64.msu).

The computer is a custom built with an ASUS P5N-D motherboard, which has the
NVIDIA nForce 750i SLI chipset.

This computer has three SATA drives - two ST3320620AS and one ST3500320AS.
The ST3500320AS has two partitions, one of which is the Windows "System" and
"Boot" partition (hosts the operating system).

If command queuing is enabled on the ST3500320AS, I get frequent System
Event Log entries with Event ID 129 from nvstor64 saying "Reset to device,
\Device\RaidPort0, was issued".

When these Event Log entries are recorded, the system temporarily freezes -
no response to mouse or keyboard, no video updates - everything stops for a
few seconds then carries on as if nothing happened.

Enabling command queuing on either or both of the ST3320620AS drives does
NOT cause this problem.

The ASUS web site says that problems with NCQ has been reported with the
NVIDIA nForce 750i SLI chipset and the solution is to update the firmware in
the drive.

Does anyone know where can I get updated firmware for the ST3500320AS or
have any other clue to resolving this problem?

I've disabled commmand queuing on the ST3500320AS, the system works and I
don't get the Event log entries (Event ID 129 from nvsotr64) or system
freezes, but I suspect this is resulting in degraded disk (and thus system)
performance.

--
Bruce Sanderson
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.

 

[Meinolf Weber]

Hello Bruce,

Well, this question better post better to seagate. If you know it's a firmware
problem, that's there task not MS.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

> This post is related to the one on 5 Jun 2008, but I think I asked the
> wrong question in that one!
>
> The operating system is Windows Server 2008 RTM with the RTM version
> of the Hyper-V role installed (Windows6.0-KB950050-x64.msu).
>
> The computer is a custom built with an ASUS P5N-D motherboard, which
> has the NVIDIA nForce 750i SLI chipset.
>
> This computer has three SATA drives - two ST3320620AS and one
> ST3500320AS. The ST3500320AS has two partitions, one of which is the
> Windows "System" and "Boot" partition (hosts the operating system).
>
> If command queuing is enabled on the ST3500320AS, I get frequent
> System Event Log entries with Event ID 129 from nvstor64 saying "Reset
> to device, \Device\RaidPort0, was issued".
>
> When these Event Log entries are recorded, the system temporarily
> freezes - no response to mouse or keyboard, no video updates -
> everything stops for a few seconds then carries on as if nothing
> happened.
>
> Enabling command queuing on either or both of the ST3320620AS drives
> does NOT cause this problem.
>
> The ASUS web site says that problems with NCQ has been reported with
> the NVIDIA nForce 750i SLI chipset and the solution is to update the
> firmware in the drive.
>
> Does anyone know where can I get updated firmware for the ST3500320AS
> or have any other clue to resolving this problem?
>
> I've disabled commmand queuing on the ST3500320AS, the system works
> and I don't get the Event log entries (Event ID 129 from nvsotr64) or
> system freezes, but I suspect this is resulting in degraded disk (and
> thus system) performance.
>
> It is perfectly useless to know the right answer to the wrong
> question.
>

 

[Charlie Russel - MVP]

GIYF.

http://www.seagate.com/www/en-us/support/downloads/other_downloads/cuda-fw

First hit on: ST3320320AS firmware site:seagate.com

In general, firmware updates are only available directly from the OEM
involved. So, for the Seagate drives, you go to the Seagate site.

As for actual performance of the drive with and without NCQ - most of the
reviews I've seen so far haven't shown a significant benefit to NCQ
enablement in benchmark tests. Real world, of course, is not a benchmark, so
YMMV.

--
Charlie.

"Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
news:OQ6IjCe6IHA.2336@TK2MSFTNGP03.phx.gbl...
> This post is related to the one on 5 Jun 2008, but I think I asked the
> wrong question in that one!
>
> The operating system is Windows Server 2008 RTM with the RTM version of
> the Hyper-V role installed (Windows6.0-KB950050-x64.msu).
>
> The computer is a custom built with an ASUS P5N-D motherboard, which has
> the NVIDIA nForce 750i SLI chipset.
>
> This computer has three SATA drives - two ST3320620AS and one ST3500320AS.
> The ST3500320AS has two partitions, one of which is the Windows "System"
> and "Boot" partition (hosts the operating system).
>
> If command queuing is enabled on the ST3500320AS, I get frequent System
> Event Log entries with Event ID 129 from nvstor64 saying "Reset to device,
> \Device\RaidPort0, was issued".
>
> When these Event Log entries are recorded, the system temporarily
> freezes - no response to mouse or keyboard, no video updates - everything
> stops for a few seconds then carries on as if nothing happened.
>
> Enabling command queuing on either or both of the ST3320620AS drives does
> NOT cause this problem.
>
> The ASUS web site says that problems with NCQ has been reported with the
> NVIDIA nForce 750i SLI chipset and the solution is to update the firmware
> in the drive.
>
> Does anyone know where can I get updated firmware for the ST3500320AS or
> have any other clue to resolving this problem?
>
> I've disabled commmand queuing on the ST3500320AS, the system works and I
> don't get the Event log entries (Event ID 129 from nvsotr64) or system
> freezes, but I suspect this is resulting in degraded disk (and thus
> system) performance.
>
> --
> Bruce Sanderson
> http://members.shaw.ca/bsanders
>
> It is perfectly useless to know the right answer to the wrong question.
>
>
>

 

[Bruce Sanderson]

Hello Charlie - good to hear from you! Thanks for your post.

I have reported the problem to Seagate - no reply yet.

Thanks for the hyperlink. Your searching skills must be far superior to
mine becuase my searching on the Seagate site did not find it!

The page you reference specifically says that for the model ST3500320AS,
which is triggering my problem, "no action is required".

I did find several posts on the Seagate site from people that had "updated"
the firware from SD15 to AD14 and now the drive doesn't work. I pulled my
drive and found that it does indeed have firmware version SD15, so I don't
think I'll be updating the firmware!

The ST3320620AS drives that do NOT cause the problem are Barracuda 7200.10

The ST3500320AS that DOES cause the problem is Barracuda 7200.11.

As to whether and how much performance degredation turning off command
queuing introduces I really don't know. I do notice that Resource Monitor
tells me the drive is "100%" busy when the Virtual Machines are busy
sometimes, but what difference the command queuing would make is hard to
say.

I also found a thread on the Seagate "message board" that someone is having
what appears to be a related problem with Vista 64 bit and a Seagate 7200.11
drive
(http://forums.seagate.com/stx/board/message?board.id=ata_drives&message.id=1916&jump=true#M1916).
I suggested they try disabling command queuing.

--
Bruce Sanderson
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.



"Charlie Russel - MVP" <charlie@mvKILLALLSPAMMERSps.org> wrote in message
news:%23yk7%23Pe6IHA.3684@TK2MSFTNGP05.phx.gbl...
> GIYF.
>
> http://www.seagate.com/www/en-us/support/downloads/other_downloads/cuda-fw
>
> First hit on: ST3320320AS firmware site:seagate.com
>
> In general, firmware updates are only available directly from the OEM
> involved. So, for the Seagate drives, you go to the Seagate site.
>
> As for actual performance of the drive with and without NCQ - most of the
> reviews I've seen so far haven't shown a significant benefit to NCQ
> enablement in benchmark tests. Real world, of course, is not a benchmark,
> so YMMV.
>
> --
> Charlie.
>
> "Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
> news:OQ6IjCe6IHA.2336@TK2MSFTNGP03.phx.gbl...
>> This post is related to the one on 5 Jun 2008, but I think I asked the
>> wrong question in that one!
>>
>> The operating system is Windows Server 2008 RTM with the RTM version of
>> the Hyper-V role installed (Windows6.0-KB950050-x64.msu).
>>
>> The computer is a custom built with an ASUS P5N-D motherboard, which has
>> the NVIDIA nForce 750i SLI chipset.
>>
>> This computer has three SATA drives - two ST3320620AS and one
>> ST3500320AS. The ST3500320AS has two partitions, one of which is the
>> Windows "System" and "Boot" partition (hosts the operating system).
>>
>> If command queuing is enabled on the ST3500320AS, I get frequent System
>> Event Log entries with Event ID 129 from nvstor64 saying "Reset to
>> device, \Device\RaidPort0, was issued".
>>
>> When these Event Log entries are recorded, the system temporarily
>> freezes - no response to mouse or keyboard, no video updates - everything
>> stops for a few seconds then carries on as if nothing happened.
>>
>> Enabling command queuing on either or both of the ST3320620AS drives does
>> NOT cause this problem.
>>
>> The ASUS web site says that problems with NCQ has been reported with the
>> NVIDIA nForce 750i SLI chipset and the solution is to update the firmware
>> in the drive.
>>
>> Does anyone know where can I get updated firmware for the ST3500320AS or
>> have any other clue to resolving this problem?
>>
>> I've disabled commmand queuing on the ST3500320AS, the system works and I
>> don't get the Event log entries (Event ID 129 from nvsotr64) or system
>> freezes, but I suspect this is resulting in degraded disk (and thus
>> system) performance.
>>
>> --
>> Bruce Sanderson
>> http://members.shaw.ca/bsanders
>>
>> It is perfectly useless to know the right answer to the wrong question.
>>
>>
>>
>

 

[Edwin vMierlo [MVP]]

"Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
news:OQ6IjCe6IHA.2336@TK2MSFTNGP03.phx.gbl...
> This post is related to the one on 5 Jun 2008, but I think I asked the
wrong
> question in that one!
>
> The operating system is Windows Server 2008 RTM with the RTM version of
the
> Hyper-V role installed (Windows6.0-KB950050-x64.msu).
>
> The computer is a custom built with an ASUS P5N-D motherboard, which has
the
> NVIDIA nForce 750i SLI chipset.
>
> This computer has three SATA drives - two ST3320620AS and one ST3500320AS.
> The ST3500320AS has two partitions, one of which is the Windows "System"
and
> "Boot" partition (hosts the operating system).
>
> If command queuing is enabled on the ST3500320AS, I get frequent System
> Event Log entries with Event ID 129 from nvstor64 saying "Reset to device,
> \Device\RaidPort0, was issued".

Can you post the full 129 event ?
(use copy symbol, including the Hex data at the end)

Thanks,
Edwin

 

[Bruce Sanderson]

Event Log entry as requested

Log Name: System
Source: nvstor64
Date: 19-Jul-2008 10:40:35 AM
Event ID: 129
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: disc2008HV.Discovery.sanderson
Description:
Reset to device, \Device\RaidPort0, was issued.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="nvstor64" />
<EventID Qualifiers="32772">129</EventID>
<Level>3</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2008-07-19T17:40:35.935Z" />
<EventRecordID>47825</EventRecordID>
<Channel>System</Channel>
<Computer>disc2008HV.Discovery.sanderson</Computer>
<Security />
</System>
<EventData>
<Data>\Device\RaidPort0</Data>
<Binary>0F001800010000000000000081000480040000000000000000000000000000000000000000000000000000000000000000000000810004800000000000000000</Binary>
</EventData>
</Event>

--
Bruce Sanderson
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.



"Edwin vMierlo [MVP]" <EdwinvMierlo@discussions.microsoft.com> wrote in
message news:uVYrnKk6IHA.3480@TK2MSFTNGP03.phx.gbl...
>
> "Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
> news:OQ6IjCe6IHA.2336@TK2MSFTNGP03.phx.gbl...
>> This post is related to the one on 5 Jun 2008, but I think I asked the
> wrong
>> question in that one!
>>
>> The operating system is Windows Server 2008 RTM with the RTM version of
> the
>> Hyper-V role installed (Windows6.0-KB950050-x64.msu).
>>
>> The computer is a custom built with an ASUS P5N-D motherboard, which has
> the
>> NVIDIA nForce 750i SLI chipset.
>>
>> This computer has three SATA drives - two ST3320620AS and one
>> ST3500320AS.
>> The ST3500320AS has two partitions, one of which is the Windows "System"
> and
>> "Boot" partition (hosts the operating system).
>>
>> If command queuing is enabled on the ST3500320AS, I get frequent System
>> Event Log entries with Event ID 129 from nvstor64 saying "Reset to
>> device,
>> \Device\RaidPort0, was issued".
>
> Can you post the full 129 event ?
> (use copy symbol, including the Hex data at the end)
>
> Thanks,
> Edwin
>
>

 

[Edwin vMierlo [MVP]]

In the "Binary" which is in really a string of hex (thanks Microsoft ! great
naming !)
you can see the error code

# for hex 0x80040081 / decimal -2147221375
IO_WARNING_RESET
# as an HRESULT: Severity: FAILURE (1), FACILITY_ITF (0x4), Code 0x81

further more the Bus Target Lun is all set to 00 00 00.

So, do you have a device on bus=0 target=0 lun=0 ?
If so, that is the device which had a timeout, contact your storage/HBA
vendor to continue investigations

an event 129 is generated by storport.sys (Microsoft driver) which has a
timeout on the lower level HBA driver, but reported in event log as from the
HBA driver. In this case the storport.sys had a timeout, and issues a reset.



"Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
news:uvbc7Ks6IHA.2220@TK2MSFTNGP06.phx.gbl...
> Event Log entry as requested
>
> Log Name: System
> Source: nvstor64
> Date: 19-Jul-2008 10:40:35 AM
> Event ID: 129
> Task Category: None
> Level: Warning
> Keywords: Classic
> User: N/A
> Computer: disc2008HV.Discovery.sanderson
> Description:
> Reset to device, \Device\RaidPort0, was issued.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="nvstor64" />
> <EventID Qualifiers="32772">129</EventID>
> <Level>3</Level>
> <Task>0</Task>
> <Keywords>0x80000000000000</Keywords>
> <TimeCreated SystemTime="2008-07-19T17:40:35.935Z" />
> <EventRecordID>47825</EventRecordID>
> <Channel>System</Channel>
> <Computer>disc2008HV.Discovery.sanderson</Computer>
> <Security />
> </System>
> <EventData>
> <Data>\Device\RaidPort0</Data>
>
<Binary>0F001800010000000000000081000480040000000000000000000000000000000000
000000000000000000000000000000000000810004800000000000000000</Binary>
> </EventData>
> </Event>
>
> --
> Bruce Sanderson
> http://members.shaw.ca/bsanders
>
> It is perfectly useless to know the right answer to the wrong question.
>
>
>
> "Edwin vMierlo [MVP]" <EdwinvMierlo@discussions.microsoft.com> wrote in
> message news:uVYrnKk6IHA.3480@TK2MSFTNGP03.phx.gbl...
> >
> > "Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
> > news:OQ6IjCe6IHA.2336@TK2MSFTNGP03.phx.gbl...
> >> This post is related to the one on 5 Jun 2008, but I think I asked the
> > wrong
> >> question in that one!
> >>
> >> The operating system is Windows Server 2008 RTM with the RTM version of
> > the
> >> Hyper-V role installed (Windows6.0-KB950050-x64.msu).
> >>
> >> The computer is a custom built with an ASUS P5N-D motherboard, which
has
> > the
> >> NVIDIA nForce 750i SLI chipset.
> >>
> >> This computer has three SATA drives - two ST3320620AS and one
> >> ST3500320AS.
> >> The ST3500320AS has two partitions, one of which is the Windows
"System"
> > and
> >> "Boot" partition (hosts the operating system).
> >>
> >> If command queuing is enabled on the ST3500320AS, I get frequent System
> >> Event Log entries with Event ID 129 from nvstor64 saying "Reset to
> >> device,
> >> \Device\RaidPort0, was issued".
> >
> > Can you post the full 129 event ?
> > (use copy symbol, including the Hex data at the end)
> >
> > Thanks,
> > Edwin
> >
> >
>

 

[Bruce Sanderson]

Edwin - thank you for your interest and response.

I'm aware that not every problem has a solution, problems have to be
prioritized and maybe this one is pretty low on the list, but perhaps
someone reading this newsgroup knows someone in Microsoft, NVIDIA or Seagate
that might be interested in pursuing it.

This computer is in a very small, test/experimental environment, so there is
definitly nothing "mission critical" here, but I'm always interested in
learnig about how things work investigating problems is often quite
enlightning, particularly in these newsgroups! The computer has an Intel
Quad core Q6600 and 8 GB RAM, so it runs Windows Server 2008 with Hyper-V
quite well.

I've reported the problem to ASUS, NVIDIA and Seagate. ASUS say the don't
support Windows Server on this motherboard (P5N-D). No response from
Seagate or NVIDIA yet.

Here's some additional information/clarification.

1. there are no SCSI or Fibre Channel devices in this system. All of the
drives are directly connected to the NVIDIA SATA controller on the
motherboard. So, there are no "HBA"s as understand the term.

2. Here's the configuration as reported by Device Manager using the Devices
by Connection View
a. PCI bus
i. NVIDIA nForce Serial ATA Controller: Properties, Location: PCI Bus
0, device 14, function 0
a) Port 0 ST3320620AS
1) [ST332062 0AS SCSI Disk Drive - Properties - Location: Bus
Number 1, Target Id 1, LUN 0]
b) Port 1 ST3500320AS
1) [ST350032 0AS SCSI Disk Drive - Properties - Location: Bus
Number 0, Target Id 0, LUN 0]

ii. NVIDIA nForce Serial ATA Controller: Properties, Location: PCI Bus
0, device 15, function 0
a) Port 0 HL-DT-ST DVDRAM GH20NS10
1) [HL-DT-ST DVDRAM GH20NS10 SCSI CdRom Device - Properties -
Location: Bus Number 0, Target Id 0, LUN 0]
b) Port 1 ST3500320AS
1) [ST350032 0AS SCSI Disk Drive Properties - Location: Bus
Number 1, Target Id 1, LUN 0]

3. I don't know why Windows Server 2008 Device Manager reports these devices
as "SCSI" instead of "SATA". I have exactly the same motherboard (ASUS
P5N-D) in another computer that is running Vista 64 bit SP1 and Device
Manager on that system also reports the SATA drives as "SCSI".

3. I've determined by experiment that the only device which causes the 129
Event Log entries when it's "Port" (2.a.i.b) has command queueing enabled is
the ST3500320AS drive (2.a.i.b)1)). Enabling command queueing on the other
two disk drives DOES NOT cauase the 129 Event entries.

4. The NVIDIA site has a KB artice
(http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_alp.php
article # 768) that indicates some problems with NCQ with SATA drives with a
different chipset (680i). The remedy there is to update the firmware on the
drive. Charlie pointed me to page on the Seagate site about firmware
updates, but that page specifically says that the updated do not apply to
this particular drive (ST3500320AS). There are posts on the Seagate site
where some people have non-the-less attempted to "update" the firmware (from
SD15 to AD14) and essentially ruined the drive. So, this does not appear to
be a solution to this particular problem.

5. Charlie points out that any performance improvement from command queueing
is likely to be marginal, so I'm willing to live with command queuing
disabled.

Thoughts anyone?

--
Bruce Sanderson
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.



"Edwin vMierlo [MVP]" <EdwinvMierlo@discussions.microsoft.com> wrote in
message news:uXqwJmw6IHA.4988@TK2MSFTNGP04.phx.gbl...
> In the "Binary" which is in really a string of hex (thanks Microsoft !
> great
> naming !)
> you can see the error code
>
> # for hex 0x80040081 / decimal -2147221375
> IO_WARNING_RESET
> # as an HRESULT: Severity: FAILURE (1), FACILITY_ITF (0x4), Code 0x81
>
> further more the Bus Target Lun is all set to 00 00 00.
>
> So, do you have a device on bus=0 target=0 lun=0 ?
> If so, that is the device which had a timeout, contact your storage/HBA
> vendor to continue investigations
>
> an event 129 is generated by storport.sys (Microsoft driver) which has a
> timeout on the lower level HBA driver, but reported in event log as from
> the
> HBA driver. In this case the storport.sys had a timeout, and issues a
> reset.
>
>
>
> "Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
> news:uvbc7Ks6IHA.2220@TK2MSFTNGP06.phx.gbl...
>> Event Log entry as requested
>>
>> Log Name: System
>> Source: nvstor64
>> Date: 19-Jul-2008 10:40:35 AM
>> Event ID: 129
>> Task Category: None
>> Level: Warning
>> Keywords: Classic
>> User: N/A
>> Computer: disc2008HV.Discovery.sanderson
>> Description:
>> Reset to device, \Device\RaidPort0, was issued.
>> Event Xml:
>> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
>> <System>
>> <Provider Name="nvstor64" />
>> <EventID Qualifiers="32772">129</EventID>
>> <Level>3</Level>
>> <Task>0</Task>
>> <Keywords>0x80000000000000</Keywords>
>> <TimeCreated SystemTime="2008-07-19T17:40:35.935Z" />
>> <EventRecordID>47825</EventRecordID>
>> <Channel>System</Channel>
>> <Computer>disc2008HV.Discovery.sanderson</Computer>
>> <Security />
>> </System>
>> <EventData>
>> <Data>\Device\RaidPort0</Data>
>>
> <Binary>0F001800010000000000000081000480040000000000000000000000000000000000
> 000000000000000000000000000000000000810004800000000000000000</Binary>
>> </EventData>
>> </Event>
>>
>> --
>> Bruce Sanderson
>> http://members.shaw.ca/bsanders
>>
>> It is perfectly useless to know the right answer to the wrong question.
>>
>>
>>
>> "Edwin vMierlo [MVP]" <EdwinvMierlo@discussions.microsoft.com> wrote in
>> message news:uVYrnKk6IHA.3480@TK2MSFTNGP03.phx.gbl...
>> >
>> > "Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
>> > news:OQ6IjCe6IHA.2336@TK2MSFTNGP03.phx.gbl...
>> >> This post is related to the one on 5 Jun 2008, but I think I asked the
>> > wrong
>> >> question in that one!
>> >>
>> >> The operating system is Windows Server 2008 RTM with the RTM version
>> >> of
>> > the
>> >> Hyper-V role installed (Windows6.0-KB950050-x64.msu).
>> >>
>> >> The computer is a custom built with an ASUS P5N-D motherboard, which
> has
>> > the
>> >> NVIDIA nForce 750i SLI chipset.
>> >>
>> >> This computer has three SATA drives - two ST3320620AS and one
>> >> ST3500320AS.
>> >> The ST3500320AS has two partitions, one of which is the Windows
> "System"
>> > and
>> >> "Boot" partition (hosts the operating system).
>> >>
>> >> If command queuing is enabled on the ST3500320AS, I get frequent
>> >> System
>> >> Event Log entries with Event ID 129 from nvstor64 saying "Reset to
>> >> device,
>> >> \Device\RaidPort0, was issued".
>> >
>> > Can you post the full 129 event ?
>> > (use copy symbol, including the Hex data at the end)
>> >
>> > Thanks,
>> > Edwin
>> >
>> >
>>
>
>

 

[Edwin vMierlo [MVP]]

in line

"Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
news:el7fj8G7IHA.4192@TK2MSFTNGP06.phx.gbl...
> Edwin - thank you for your interest and response.
>
> I'm aware that not every problem has a solution, problems have to be
> prioritized and maybe this one is pretty low on the list, but perhaps
> someone reading this newsgroup knows someone in Microsoft, NVIDIA or
Seagate
> that might be interested in pursuing it.
>
> This computer is in a very small, test/experimental environment, so there
is
> definitly nothing "mission critical" here, but I'm always interested in
> learnig about how things work investigating problems is often quite
> enlightning, particularly in these newsgroups! The computer has an Intel
> Quad core Q6600 and 8 GB RAM, so it runs Windows Server 2008 with Hyper-V
> quite well.
>
> I've reported the problem to ASUS, NVIDIA and Seagate. ASUS say the don't
> support Windows Server on this motherboard (P5N-D). No response from
> Seagate or NVIDIA yet.
>
> Here's some additional information/clarification.
>
> 1. there are no SCSI or Fibre Channel devices in this system. All of the
> drives are directly connected to the NVIDIA SATA controller on the
> motherboard. So, there are no "HBA"s as understand the term.
>
> 2. Here's the configuration as reported by Device Manager using the
Devices
> by Connection View
> a. PCI bus
> i. NVIDIA nForce Serial ATA Controller: Properties, Location: PCI
Bus
> 0, device 14, function 0
> a) Port 0 ST3320620AS
> 1) [ST332062 0AS SCSI Disk Drive - Properties - Location: Bus
> Number 1, Target Id 1, LUN 0]
> b) Port 1 ST3500320AS
> 1) [ST350032 0AS SCSI Disk Drive - Properties - Location: Bus
> Number 0, Target Id 0, LUN 0]

This is the one with B,T,L=0,0,0 -- this would be my suspect based on the
binary data of the event (see my previous post).

>
> ii. NVIDIA nForce Serial ATA Controller: Properties, Location: PCI
Bus
> 0, device 15, function 0
> a) Port 0 HL-DT-ST DVDRAM GH20NS10
> 1) [HL-DT-ST DVDRAM GH20NS10 SCSI CdRom Device - Properties -
> Location: Bus Number 0, Target Id 0, LUN 0]

This one has also a B,T,L=0,0,0 -- because this is a CDrom device, this
would not be my suspect

> b) Port 1 ST3500320AS
> 1) [ST350032 0AS SCSI Disk Drive Properties - Location: Bus
> Number 1, Target Id 1, LUN 0]
>
> 3. I don't know why Windows Server 2008 Device Manager reports these
devices
> as "SCSI" instead of "SATA". I have exactly the same motherboard (ASUS
> P5N-D) in another computer that is running Vista 64 bit SP1 and Device
> Manager on that system also reports the SATA drives as "SCSI".

Interesting, did not notice this until now, must keep an eye out

>
> 3. I've determined by experiment that the only device which causes the 129
> Event Log entries when it's "Port" (2.a.i.b) has command queueing enabled
is
> the ST3500320AS drive (2.a.i.b)1)). Enabling command queueing on the
other
> two disk drives DOES NOT cauase the 129 Event entries.

ah ! good info, definitely worth while relaying to HD support (seagate)
Although on the website it details that this drive supports NCQ.


>
> 4. The NVIDIA site has a KB artice
> (http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_alp.php
> article # 768) that indicates some problems with NCQ with SATA drives with
a
> different chipset (680i). The remedy there is to update the firmware on
the
> drive. Charlie pointed me to page on the Seagate site about firmware
> updates, but that page specifically says that the updated do not apply to
> this particular drive (ST3500320AS). There are posts on the Seagate site
> where some people have non-the-less attempted to "update" the firmware
(from
> SD15 to AD14) and essentially ruined the drive. So, this does not appear
to
> be a solution to this particular problem
>
> 5. Charlie points out that any performance improvement from command
queueing
> is likely to be marginal, so I'm willing to live with command queuing
> disabled.

Back to your original remark "This computer is in a very small,
test/experimental environment" you need to ask yourself the question if it
is worthwhile pursuing

 

[Bruce Sanderson]

Thanks for the info, Edwin. NVIDIA says talk to ASUS ASUS says "2008 not supported" no response
from Seagate yet.

I don't think I will do any more on this, just live with it!

--
Bruce Sanderson
http://members.shaw.ca/bsanders/
It's perfectly useless to know the right answer to the wrong question.


"Edwin vMierlo [MVP]" <EdwinvMierlo@discussions.microsoft.com> wrote in message
news:%233MvS3l7IHA.3652@TK2MSFTNGP04.phx.gbl...
> in line
>
> "Bruce Sanderson" <bsanders@newsgroups.nospam> wrote in message
> news:el7fj8G7IHA.4192@TK2MSFTNGP06.phx.gbl...
>> Edwin - thank you for your interest and response.
>>
>> I'm aware that not every problem has a solution, problems have to be
>> prioritized and maybe this one is pretty low on the list, but perhaps
>> someone reading this newsgroup knows someone in Microsoft, NVIDIA or
> Seagate
>> that might be interested in pursuing it.
>>
>> This computer is in a very small, test/experimental environment, so there
> is
>> definitly nothing "mission critical" here, but I'm always interested in
>> learnig about how things work investigating problems is often quite
>> enlightning, particularly in these newsgroups! The computer has an Intel
>> Quad core Q6600 and 8 GB RAM, so it runs Windows Server 2008 with Hyper-V
>> quite well.
>>
>> I've reported the problem to ASUS, NVIDIA and Seagate. ASUS say the don't
>> support Windows Server on this motherboard (P5N-D). No response from
>> Seagate or NVIDIA yet.
>>
>> Here's some additional information/clarification.
>>
>> 1. there are no SCSI or Fibre Channel devices in this system. All of the
>> drives are directly connected to the NVIDIA SATA controller on the
>> motherboard. So, there are no "HBA"s as understand the term.
>>
>> 2. Here's the configuration as reported by Device Manager using the
> Devices
>> by Connection View
>> a. PCI bus
>> i. NVIDIA nForce Serial ATA Controller: Properties, Location: PCI
> Bus
>> 0, device 14, function 0
>> a) Port 0 ST3320620AS
>> 1) [ST332062 0AS SCSI Disk Drive - Properties - Location: Bus
>> Number 1, Target Id 1, LUN 0]
>> b) Port 1 ST3500320AS
>> 1) [ST350032 0AS SCSI Disk Drive - Properties - Location: Bus
>> Number 0, Target Id 0, LUN 0]
>
> This is the one with B,T,L=0,0,0 -- this would be my suspect based on the
> binary data of the event (see my previous post).
>
>>
>> ii. NVIDIA nForce Serial ATA Controller: Properties, Location: PCI
> Bus
>> 0, device 15, function 0
>> a) Port 0 HL-DT-ST DVDRAM GH20NS10
>> 1) [HL-DT-ST DVDRAM GH20NS10 SCSI CdRom Device - Properties -
>> Location: Bus Number 0, Target Id 0, LUN 0]
>
> This one has also a B,T,L=0,0,0 -- because this is a CDrom device, this
> would not be my suspect
>
>> b) Port 1 ST3500320AS
>> 1) [ST350032 0AS SCSI Disk Drive Properties - Location: Bus
>> Number 1, Target Id 1, LUN 0]
>>
>> 3. I don't know why Windows Server 2008 Device Manager reports these
> devices
>> as "SCSI" instead of "SATA". I have exactly the same motherboard (ASUS
>> P5N-D) in another computer that is running Vista 64 bit SP1 and Device
>> Manager on that system also reports the SATA drives as "SCSI".
>
> Interesting, did not notice this until now, must keep an eye out
>
>>
>> 3. I've determined by experiment that the only device which causes the 129
>> Event Log entries when it's "Port" (2.a.i.b) has command queueing enabled
> is
>> the ST3500320AS drive (2.a.i.b)1)). Enabling command queueing on the
> other
>> two disk drives DOES NOT cauase the 129 Event entries.
>
> ah ! good info, definitely worth while relaying to HD support (seagate)
> Although on the website it details that this drive supports NCQ.
>
>
>>
>> 4. The NVIDIA site has a KB artice
>> (http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_alp.php
>> article # 768) that indicates some problems with NCQ with SATA drives with
> a
>> different chipset (680i). The remedy there is to update the firmware on
> the
>> drive. Charlie pointed me to page on the Seagate site about firmware
>> updates, but that page specifically says that the updated do not apply to
>> this particular drive (ST3500320AS). There are posts on the Seagate site
>> where some people have non-the-less attempted to "update" the firmware
> (from
>> SD15 to AD14) and essentially ruined the drive. So, this does not appear
> to
>> be a solution to this particular problem
>>
>> 5. Charlie points out that any performance improvement from command
> queueing
>> is likely to be marginal, so I'm willing to live with command queuing
>> disabled.
>
> Back to your original remark "This computer is in a very small,
> test/experimental environment" you need to ask yourself the question if it
> is worthwhile pursuing
>
>
>
>