From: Bruce Sanderson on
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(a)discussions.microsoft.com> wrote in
message news:uVYrnKk6IHA.3480(a)TK2MSFTNGP03.phx.gbl...
>
> "Bruce Sanderson" <bsanders(a)newsgroups.nospam> wrote in message
> news:OQ6IjCe6IHA.2336(a)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
>
>

From: Edwin vMierlo [MVP] on
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(a)newsgroups.nospam> wrote in message
news:uvbc7Ks6IHA.2220(a)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(a)discussions.microsoft.com> wrote in
> message news:uVYrnKk6IHA.3480(a)TK2MSFTNGP03.phx.gbl...
> >
> > "Bruce Sanderson" <bsanders(a)newsgroups.nospam> wrote in message
> > news:OQ6IjCe6IHA.2336(a)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
> >
> >
>


From: Bruce Sanderson on
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(a)discussions.microsoft.com> wrote in
message news:uXqwJmw6IHA.4988(a)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(a)newsgroups.nospam> wrote in message
> news:uvbc7Ks6IHA.2220(a)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(a)discussions.microsoft.com> wrote in
>> message news:uVYrnKk6IHA.3480(a)TK2MSFTNGP03.phx.gbl...
>> >
>> > "Bruce Sanderson" <bsanders(a)newsgroups.nospam> wrote in message
>> > news:OQ6IjCe6IHA.2336(a)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
>> >
>> >
>>
>
>

From: Edwin vMierlo [MVP] on
in line

"Bruce Sanderson" <bsanders(a)newsgroups.nospam> wrote in message
news:el7fj8G7IHA.4192(a)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




From: Bruce Sanderson on
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(a)discussions.microsoft.com> wrote in message
news:%233MvS3l7IHA.3652(a)TK2MSFTNGP04.phx.gbl...
> in line
>
> "Bruce Sanderson" <bsanders(a)newsgroups.nospam> wrote in message
> news:el7fj8G7IHA.4192(a)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
>
>
>
>