"Bruce Sanderson" <bsanders@xxxxxx> wrote in message
news:OQ6IjCe6IHA.2336@xxxxxx

> 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 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@xxxxxx> wrote in message
news:uvbc7Ks6IHA.2220@xxxxxx

> 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@xxxxxx> wrote in
> message news:uVYrnKk6IHA.3480@xxxxxx

> >
> > "Bruce Sanderson" <bsanders@xxxxxx> wrote in message
> > news:OQ6IjCe6IHA.2336@xxxxxx

> >> 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" <bsanders@xxxxxx> wrote in message
news:el7fj8G7IHA.4192@xxxxxx

> 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/n...er/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

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@xxxxxx> wrote in message
news:%233MvS3l7IHA.3652@xxxxxx

> in line
>
> "Bruce Sanderson" <bsanders@xxxxxx> wrote in message
> news:el7fj8G7IHA.4192@xxxxxx

>> 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/n...er/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
>
>
>
>