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

> 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" <(email address - cut out)am> wrote in message
> news:(email address - cut out)...
>> 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.
>>
>>
>>
>

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

> This post is related to the one on 5 Jun 2008, but I think I asked the
> question in that one!
>
> The operating system is Windows Server 2008 RTM with the RTM version of
> Hyper-V role installed (Windows6.0-KB950050-x64.msu).
>
> The computer is a custom built with an ASUS P5N-D motherboard, which has
> 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"
> "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".

>
> "Bruce Sanderson" <(email address - cut out)am> wrote in message
> news:(email address - cut out)...
>> 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
>
>

> 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>
>
> </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]" <(email address - cut out)> wrote in
> message news:(email address - cut out)...
> >
> > "Bruce Sanderson" <(email address - cut out)am> wrote in message
> > news:(email address - cut out)...
> >> 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
> > 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
> > 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
> >
> >
>

> 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" <(email address - cut out)am> wrote in message
> news:(email address - cut out)...
>> 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]" <(email address - cut out)> wrote in
>> message news:(email address - cut out)...
>> >
>> > "Bruce Sanderson" <(email address - cut out)am> wrote in message
>> > news:(email address - cut out)...
>> >> 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
>> >
>> >
>>
>
>

> in line
>
> "Bruce Sanderson" <(email address - cut out)am> wrote in message
> news:(email address - cut out)...
>> 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
>
>
>
>

> 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
> that might be interested in pursuing it.
>
> This computer is in a very small, test/experimental environment, so there
> 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
> by Connection View
> a. PCI bus
> i. NVIDIA nForce Serial ATA Controller: Properties, Location: PCI
> 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
> 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
> 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
> the ST3500320AS drive (2.a.i.b)1)). Enabling command queueing on the
> 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
> different chipset (680i). The remedy there is to update the firmware on
> 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
> SD15 to AD14) and essentially ruined the drive. So, this does not appear
> be a solution to this particular problem
>
> 5. Charlie points out that any performance improvement from command
> is likely to be marginal, so I'm willing to live with command queuing
> disabled.