Re: Data corruption when transfering across network?



On Sun, 21 Aug 2005 21:22:53 -0400, ByTor <ByTor@xxxxxxxxxxx> wrote:
>cquirkenews@xxxxxxxxxxxxxxx, cquirke (MVP Windows shell/user) says...
>> On Sat, 20 Aug 2005 17:20:08 -0400, ByTor <ByTor@xxxxxxxxxxx> wrote:
>> >In article <gn4fg1lftiejfh7l965ndvdfiosjfdhdvg@xxxxxxx>,

>> Ah, I missed that - you say it's always the same PC that receives data
>> that is corrupted? That suggests something on that PC... the data may
>> have been OK as it entered the LAN card, but longer be OK by the time
>> it hits the disk surface.

>Yes, same PC, same Win2K install..............I've actually tried
>writing it to a different HD on the machine... 1 HD is connected to the
>MB IDE channel (OS drive only) and 2 HD's connected to a controller card
>(promise UltraTX2) thinking maybe corrupted PT or something but same
>thing happened in all instances.....Each PT on the drives connected to
>the controller are split in 3 PT's each for different data storage.

Sounds like a nice VIA-provoking stack of PCI bus masters there ;-)

The known issue I refer to should predate KM400A, but then again it
may be the southbridge (the "pants") rather than the northbridge (the
"shirt") that makes the KM400A a KM400A.

It was noted that when the following conditions were met...
- multiple IDE bus masters
- typically a Creative Live sound card
....the last few bytes of transfers would get "eaten". The bug was due
to VIA failing to conform to safe PCI timings, and the "fix" was a
BIOS kludge to change the timings to slower ones that thier lame
chipset would support. The Creative Live sound card's notorious for
hogging the PCI and thus brings the problem to light, but the
underlying flaw is within VIA's hardware.

Try testing with the Promise "disabled in this profile' with no HDs on
it, just for laughs, unless that will upset the OSs.

>> >As far as this particular Win2K install, yes, it is definately driven
>> >harder than the remaining 3 OS's........More installs, etc.

>> I was thinking at a lower level i.e. wires, volts and microseconds.
>> Digital systems are made of analog parts, and at the analog level, all
>> it takes is the front edge of a square wave signal transition to take
>> slightly too long, and you have a bit error right there.

>Very interesting points you are making here, I will check settings I'm
>sure all modes are the same.....good point though, I did at one time
>check PIO modes on my CDROMS as burning sucks

XP's smart enough to detect excessive errors in UDMA mode, and fall
back to PIO if so. Win2000 is more likely to carry on bearing its
head against the wall until the neck snaps and the head falls off.

>my burners on this machine are connected to a Siig card
>and work astronomically when burning, wouldn't know I was
>burning....Wish I had another one.

Tell me more about that "Siig card"? Is this a 3rd IDE-oid
controller, allong with native VIA + Promise RAID? How are those
motherboard caps doing, sounds like they will be working hard, and
Win2000 puts it into that age bracket?

http://cquirke.mvps.org/badcaps.htm refers

>> >I have 4 OS's on one drive......Win2K-WinXP-WinXP-Win2K....All in that
>> >order on all hidden primary partitions using a boot manager.....The
>> >first Win2K is the problematic one.

>> The first and last Win2000; are they precisely the same version, with
>> same drivers?

>Yes..........

OK (crosses out a whole bunch of pipelined Q's)

>> Can each installation see the others' HDs? Were any installations "cloned"
>> from another, so that non-unique SIDs might be a problem?

>Yes all drives & partitions are seen perfectly....

Not so good. NT (XP) has been dumb enough to get caught fiddling in
the wrong partition's registry; Alex Nichol was up to speed with that,
but he's no longer with us and is sorely missed.

>all to C's, no clones.....I use BootMagic for booting & hiding
>each OS from each other.

Ah, that's good - and what I meant when I asked; you are appropriately
hiding them from each other. That removes the risk I referto above.

>....Each OS is on a primary partition with a "C" drive letter.

....and never "sees" the others.

>> Are you on the Internet while all this is going on?

>Yes..............High speed cable.

OK, try offing that for starters. Fight one battle at a time - it's
far easier to tshoot one PC than the entire Internet. Sun may rejoice
in "the network is the computer", but I don't want to have to manage
an alien million-node network every time I do anything "local".

>> Does the afflicted Win2000 have different av? Are there any
>> ambiguities between how other systesm see these installations, i.e.
>> where a remote PC may think it's dealing with installation 4 when it's
>> really dealing with installation 1?

>As mentioned above, each OS is independently isolated, shares are not
>confused.......

Actually, this bit CAN apply. We're now looking at the way other PCs
see this one via the LAN - let's say OS A shares C:\Blob\Blah as
"BLOOP" and OS B shares C:\Bugaboo as "BLOOP" but read-only. All the
other PC sees is "BLOOP", and any session-to-session changes may
ambush its assumptions. It shouldn't be a factor, but it may be,
given that data corruption shouldn't be a factor either, and yet is.

>> Has the HD ever had any bad clusters, in any installation? Does the
>> AutoChk / ChkDsk history show any code files that were "fixed"? Did
>> the av ever have to "clean" any code files?

>No bad clusters...........

Cool. I'd use HD-Tune to check SMART detail and surface, even though
it's unlikely given the swap-test you did (using a different physical
HD), as the meat is smelly (er... stakes are high) <kicks babelfish>

>> >All drivers are the same in the case of the 2K's.........The XP's were a
>> >little stupid with a few but not a major issue.

>> Uhh... cummer gain?

>I allowed XP's native driver for my controller card once and the 3rd
>partition on a particular drive did not appear in "My Computer"...

Aha... cue "lurking villian music" da da-da daaa...

In Win9x, one worked around PnP masking (that PnP would not display
any "inappropriate" drivers in Device Manager if the corresponding
hware wasn't detected) by working from Safe Mode, where PnP filtering
is disabled. This is when you see things like 5 sets of "COM1", etc.
and can clean them up.

The equivalent in XP, and presumably Win2000, may be different - I
think there's a registry setting that reveals "everything". PnP's
better these days, so I haven't had to go that deep in XP, and I
pretty much slept through the Win2000 era as my clients were Win9x.

>I used the management section it reported it as "free space?" Could not
>access the data.........I forced the Manufacturer's original drivers and
>the partition magically appeared with all data accessible....Very wierd
>thing, but only real issue I had with XP...

But this is a Win2000 installation that's giving trouble, isn't it?

There's one other system-level point of contention with PnP OSs, and
that is the BIOS PnP NVRAM that they all share. My practice has been
to set PnP OS = No in CMOS, so that the PnP BIOS does the driving; the
PnP OSs are then supposed to shaddup and eat whatever the good BIOS
provides, without pooing in NVRAM (ESCD) space.

>> >This particular board is a ASUS A7V8X-LA with VIA KM400A Chipset....

>> Bingo! Well, Google(KM499A corruption) seems to think so...

>Very, very interesting reading......Especially the AGP portitons, WOW, I
>actually was having an issue with setting the AGP speed on this machine
>to 4X after installing an "All In Wonder 2006" AGP card...

I got the cold grizzlies when I saw those incessent "New VIA 4-in-1
Beta Drivers Now Available!" posts.

My HD's life blood flows through those drivers, and you want I should
trust beta code there? You ship a chipset welded into thousands of
motherboards, and you still haven't debugged the critical driver code?
Bye VIA, thanks for playing, don't let the door hit your ass as you go

>> OK, pointing away from cables then. A thought: Do all these have the
>> LAN card in the same PCI socket? Same IRQ sharing on all systems and
>> all OSs? Could be a tie-breaker there.

>Interesting point at the end here.....Will look.

PCI IRQ sharing is a mature technology, but even so, you don't want
your biggest hitters sharing the same IRQ. The PCI slot closest to
the AGP is most likely to share an IRQ with it, so I avoid that one;
the lowest one is more likely to share with USB.

This is a less-obvious reason why I prefer to avoid Micro-ATX; I may
have "enough" PCI slots, but not be able to avoid such placements.

>> If I had to go AMD, I'd want AMD or nForce chipset. Trouble is, most
>> recent "AMD" chipsets have AMD shirt, VIA pants.

>Yes, why they lost the 761 chipset is beyond me....I believe the
>A7M266-D was the last of its kind

This is IMO what hurts AMD. I loved AMD's 286-20, 386DX-40, 386SX-40,
486DX-40, 486DX2-66, 486DX4-100 and especially "586"DX4-133, and
hardly did any Intel at all in those days. But they got off to a
wobbly start with the K5, which truly sucked; I respected the K6
series, but didn't use them. The K6 was engineered by the NexGen
team, whom AMD acquired; the K5 was "in-house" before this.

When Intel kicked them out of The Garden in the Sloth One era, they
were ironically forced to do what killed NexGen; start up a
socket-incompatible platform to stay in the race with Intel. In the
K6 era, they pushed Socket 7 as far as it could go, and then succeeded
in surviving in the wilderness with Slot/Socket A, etc.

Intel started thier own motherboard chipset business in the Pentium
era, out of frustration with incompitent 3rd-party chipsets that
continually under-utilised processor capabilities etc. Alas, AMD
didn't, leaving this to VIA, ALi and SiS. And that's why I don't do
AMD; if I did, I'd want AMD on nForce as my mobo's speedbumps.

>> >I've tackled much heavier issues and can't figure this one...

>> When that happens, it's uaually because the fault is at an abstraction
>> layer or few lower than the one your logic is walking around on.

>> This smells like a 1-in-a-billion bit-flip flakiness to me :-(

>Yes, agreed I will keep you posted.....This is getting more interesting
>by the minute............... ;0)

It's one of my fave threads right now, too! But then it's always more
fun this side of the small screen, heh heh.



>---------- ----- ---- --- -- - - - -
Proverbs Unscrolled #37
"Build it and they will come and break it"
>---------- ----- ---- --- -- - - - -
.



Relevant Pages

  • Thinkpad 760ED PnP issues.
    ... I've already mucked about with the BIOS IRQ configurations - IRQ 9 for ... The Ali USB 2.0/1.1 controller is on the card I have installed - but my ... No PCI interrupt routing table was found. ... PnPBIOS: Scanning system for PnP BIOS support... ...
    (Linux-Kernel)
  • Re: vmap allocation failed with 2 graphics cards and kernel 2.6.28
    ... 00000000-0009f7ff: System RAM ... 000cb400-000cbfff: pnp 00:0c ... 00200000-005bd7e5: Kernel code ... e0000000-e0ffffff: PCI Bus 0000:02 ...
    (Linux-Kernel)
  • problem: SATA performance drop down
    ... ACPI: Local APIC address 0xfee00000 ... Allocating PCI resources starting at dc000000 ... pnp: PnP ACPI init ... PCI: Setting latency timer of device 0000:00:06.0 to 64 ...
    (Debian-User)
  • fritz card unter etch schon installiert ?
    ... ACPI: Local APIC address 0xfee00000 ... Allocating PCI resources starting at c0000000 ... pnp: PnP ACPI init ... Using ACPI for IRQ routing ...
    (de.comp.os.unix.linux.misc)
  • pci-resume patch from 2.6.7-rc2 breakes S3 resume on some machines
    ... ACPI: IRQ9 SCI: Edge set to Level Trigger. ... PCI: PCI BIOS revision 2.10 entry at 0xfd9d3, ... PnPBIOS: Scanning system for PnP BIOS support... ... 20 nodes reported by PnP BIOS; 20 recorded by driver ...
    (Linux-Kernel)