Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mark Kane]

Mark Kane wrote:
I'm glad that it looks like running it at 100 will solve this. Thanks 
for the replies. I was probably going to go through all the hassle of 
getting an Asus board to replace this because I was almost certain it 
was hardware, but I don't think it's worth it as long as this works :)


I guess I spoke too soon. I was running things in 100 mode all day while 
doing some things to get it ready for my use. I copied 31GB of data from 
one drive (ad10) to another (ad9) with no WRITE errors from what I can 
see. Then I went to use cksfv to check the data against the source. This 
is what I get:


ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=157308607
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=157308607
ad9: FAILURE - READ_DMA status=51 
error=84 LBA=157308607

ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=157308639
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=157308639
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=195346815
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=195714111
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=196459199
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=197213503
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=110345151
ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=110345151
ad9: FAILURE - READ_DMA status=51 
error=84 LBA=110345151

ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=110345183

Here are the current drives in the system:

ad0: 194481MB  [395136/16/63] at ata0-master 
UDMA133
ad8: 156334MB  [317632/16/63] at ata4-master 
UDMA133

ad9: 194481MB  [395136/16/63] at ata4-slave UDMA133
ad10: 58643MB  [119147/16/63] at ata5-master 
UDMA133


(They say 133 in the dmesg but atacontrol says 100 for all of them)

Now Is this the problem that was described earlier on in the thread, or 
is this crappy controllers on the motherboard and I really do need to 
try to go through the hassle of exchanging it for that Asus board?


-Mark
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mark Kane]

Mark Kirkwood wrote:

Mark Kane wrote:

I do have a tall Antec case, and have both 200's and the 160 in 5 1/4 
inch trays so the cables for those are long (36 inches IIRC).



Hmm - 36 inch cable, makes me wonder if that is what is causing the 
problem in UDMA133 mode. IIRC the ATA spec says 18 inches, but most 
cables seem to be ok at 24 inches. 36 inches may just be tipping things 
over the edge...


Oh sorry I should have mentioned that my testing was done with standard 
length cables and there was still all the problems. I just got the 36 
inch for the final placement of the drives, and there seems to be no 
change when I switch the cables.


I'm glad that it looks like running it at 100 will solve this. Thanks 
for the replies. I was probably going to go through all the hassle of 
getting an Asus board to replace this because I was almost certain it 
was hardware, but I don't think it's worth it as long as this works :)


-Mark

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Pertti Kosunen]

Mark Kane wrote:

I do have a tall Antec case, and have both 200's and the 160 in 5 1/4 
inch trays so the cables for those are long (36 inches IIRC). Would it 
be OK to have that setup, or would it be better to isolate them all on 
their own cables/channels and get a Promise card or something for the 
other two? I'm not going to be doing huge file copying a whole lot, 
but I'd like the most performance I can get with no errors. 



You should not see any performance difference between 133 and 100.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mark Kirkwood]

Mark Kane wrote:

I do have a tall Antec case, and have both 200's and the 160 in 5 1/4 
inch trays so the cables for those are long (36 inches IIRC).


Hmm - 36 inch cable, makes me wonder if that is what is causing the 
problem in UDMA133 mode. IIRC the ATA spec says 18 inches, but most 
cables seem to be ok at 24 inches. 36 inches may just be tipping things 
over the edge...


Cheers

Mark

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mark Kane]

Mike Tancsa wrote:
Yes, I have had Maxtor drives in the past where they would not work 
properly at certain bus speeds-- even back in the RELENG_4 days.  Also, 
doesnt UDMA133 assume no slave ?


I would just run them at 100.  I dont think you would see much of a 
difference anyways.  Perhaps Soeren could comment ?


OK well I just tried adding some atacontrol commands to /etc/rc.local to 
force them all to 100 and it appeared to execute them upon boot. In 
various tests this evening I was getting errors even when trying to 
mount a drive while another one was on the same channel. However the 
atacontrol to rc.local seemed to do the trick for now, and I hope it 
continues to workunless there is a better way to do that for all my 
drives upon boot.


I'm not too worried about any 133 performance increase at this point. I 
just want the stuff to work.


Here is how I had planned my configuration to be:

Primary IDE Master - Maxtor 200GB (FreeBSD)
Secondary IDE Master - TDK VeloCD Burner
Secondary IDE Slave - Sony DRU500A
RAID 0 Master - Maxtor 200GB (Storage)
RAID 0 Slave - Maxtor 160GB (Storage)
RAID 1 Master - Maxtor 80GB (Storage)
RAID 1 Slave - Maxtor 80GB (Storage)

I do have a tall Antec case, and have both 200's and the 160 in 5 1/4 
inch trays so the cables for those are long (36 inches IIRC). Would it 
be OK to have that setup, or would it be better to isolate them all on 
their own cables/channels and get a Promise card or something for the 
other two? I'm not going to be doing huge file copying a whole lot, but 
I'd like the most performance I can get with no errors.


Thanks for the replies.

-Mark
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mark Kirkwood]

Mark Kane wrote:


However, note that if I turn the drives speed down to UDMA100, the 
errors seem to go away. Has anyone else tried this for their problems?




I currently do this, not due to problems, but to improve the write 
performance:


4xMaxtor 6E040L0  RAID0

UDMA133 -> 40M/s
UDMA100 -> 120M/s

(seem to find read performance is *slightly* slower for UDMA100, but not 
enough to make it worth worrying about).


However this may just be a quirk specific to my system (Tyan S2510 + 
PCD20271).


Cheers

Mark
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mike Tancsa]

At 12:10 PM 16/08/2005, Mark Kane wrote:
However, note that if I turn the drives speed down to UDMA100, the 
errors seem to go away. Has anyone else tried this for their problems?


Yes, I have had Maxtor drives in the past where they would not work 
properly at certain bus speeds-- even back in the RELENG_4 
days.  Also, doesnt UDMA133 assume no slave ?


I would just run them at 100.  I dont think you would see much of a 
difference anyways.  Perhaps Soeren could comment ?


---Mike 


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mark Kane]

I've been having similar problems on 5.4-RELEASE. I have a brand new 
board back from the factory (a RMA) and had a thread going on 
freebsd-questions about this.


I currently have six Maxtor 7200RPM ATA133 hard drives that I've been 
trying on and off and with various configurations in my 5.4-RELEASE 
amd64 machine. The only thing I have done thus far to reproduce the READ 
and WRITE errors (there have been more WRITE than READ) is copy data 
between the drives. All the drives check out just fine through PowerMax 
(Maxtor's utility), and work in other FreeBSD 4.x machines in the same 
placement that causes errors on my 5.4 box. The cables are also brand new.


However, note that if I turn the drives speed down to UDMA100, the 
errors seem to go away. Has anyone else tried this for their problems?


I've read the entire thread and so far there has been no mention of any 
nForce chipsets doing this, but I've got a Giga-Byte K8NS Pro 
motherboard with a nForce3 chipset.


I've been troubleshooting this for almost two weeks now on my end, and 
up until last night I didn't see any "FAILURE" messages. They were all 
just WARNINGS. I've only seen the FAILURE on one of the six hard drives, 
and that was last night when I was trying to fdisk it. Right when I hit 
"w" to write the fdisk information my screen flooded with WARNINGS and 
FAILURES, so indeed that particular drive might be going. This problem 
did not happen with any of the other drives.


My whole reason for bringing back this thread is to see if my problems 
could be a result of the problem discussed here, and in fact is really 
not my hardware. As I said, the board is brand new, the cables are brand 
new, and two of the hard drives are even brand new. I've been pulling my 
hair out trying to narrow this problem down, and as of yesterday I was 
just going to run all my drives in UDMA100 mode to save me the hassle 
(since they seem to run fine in 100). Then, I found this thread and 
thought I'd ask if anyone here might think anything other than hardware 
problems.


Granted, I'm not using FreeBSD 5-STABLE, but I could certainly give it a 
shot if you guys think it would help anything. I just chose RELEASE 
hoping for the least problems.


My dmesg is below. Note that I only have three of the drives in there 
currently.


Thanks

-Mark

---
DMESG:

FreeBSD 5.4-RELEASE #0: Sun May  8 07:00:26 UTC 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
ACPI APIC Table: 
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 Processor 3000+ (2009.79-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0xfc0  Stepping = 0

Features=0x78bfbff
  AMD Features=0xe0500800
real memory  = 1610547200 (1535 MB)
avail memory = 1543139328 (1471 MB)
ioapic0  irqs 0-23 on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
cpu0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf0-0xcf3,0xcf8-0xcff on acpi0
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
pci0:  at device 1.1 (no driver attached)
ohci0:  mem 0xfc002000-0xfc002fff irq 22 
at device 2.0 on pci0

usb0: OHCI version 1.0, legacy support
usb0:  on ohci0
usb0: USB revision 1.0
uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
ohci1:  mem 0xfc003000-0xfc003fff irq 21 
at device 2.1 on pci0

usb1: OHCI version 1.0, legacy support
usb1:  on ohci1
usb1: USB revision 1.0
uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 4 ports with 4 removable, self powered
pci0:  at device 2.2 (no driver attached)
atapci0:  port 
0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0

ata0: channel #0 on atapci0
ata1: channel #1 on atapci0
atapci1:  port 
0xe400-0xe40f,0xb70-0xb73,0x970-0x977,0xbf0-0xbf3,0x9f0-0x9f7 irq 22 at 
device 10.0 on pci0

ata2: channel #0 on atapci1
ata3: channel #1 on atapci1
pcib1:  at device 11.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
pcib2:  at device 14.0 on pci0
pci2:  on pcib2
pci2:  at device 9.0 (no driver attached)
pci2:  at device 9.1 (no driver attached)
fwohci0: <1394 Open Host Controller Interface> mem 
0xfb004000-0xfb007fff,0xfb00d000-0xfb00d7ff irq 18 at device 9.2 on pci2

fwohci0: OHCI version 1.10 (ROM=0)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:02:3c:00:91:01:6c:20
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0:  on fwohci0
fwe0:  on firewire0
if_fwe0: Fake Ethernet address: 02:02:3c:01:6c:20
fwe0: Ethernet address: 02:02:3c:01:6c:20
fwe0: if_start running deferred for Giant
sbp0:  on firewire0
fwohci0: Initiate bus reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
skc0:  port 0xa800-0xa8ff mem 
0xfb00-0xfb003fff irq

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request)LBA=11441599

[Karl Denninger]

On Thu, Aug 11, 2005 at 03:44:52PM -0700, Vinod Kashyap wrote:
> > I have two controllers here that are from different 
> > manufacturers and both exhibit the same problem.  The SAME 
> > disks (two different manufacturers - hitachi and maxtor) on a 
> > motherboard ICH5 adapter work perfectly, smartmontools says 
> > all 4 (I have two examples of each) are healthy, and both 
> > ALSO work perfectly on and are declared healthy by a 3ware 
> > 8502's internal diags and operating kernel (smartmontools 
> > won't talk to them on the 8502.)
> > 
> 
> smartmontools should support 3ware 7xxx & 8xxx controllers, although
> not 9xxx controllers.  See the answer to the question 'Can I monitor
> ATA disks behind SCSI RAID controllers?' at
> http://smartmontools.sourceforge.net/#FAQ.  Although the answer is
> for Linux, it applies to FreeBSD as well.  You have to use '-d 3ware,N'
> with every command, where N is the unit #.
> Ex: smartctl -H -A -d 3ware,1 /dev/twed


Fs:/disk/karl> smartctl -d 3ware,1 /dev/twed0
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Smartctl open device: /dev/twed0 failed: Inappropriate ioctl for device

Nope...apparently not supported on FreeBSD.

--
-- 
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org   Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.comMusings Of A Sentient Mind


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request)LBA=11441599

[Vinod Kashyap]

> I have two controllers here that are from different 
> manufacturers and both exhibit the same problem.  The SAME 
> disks (two different manufacturers - hitachi and maxtor) on a 
> motherboard ICH5 adapter work perfectly, smartmontools says 
> all 4 (I have two examples of each) are healthy, and both 
> ALSO work perfectly on and are declared healthy by a 3ware 
> 8502's internal diags and operating kernel (smartmontools 
> won't talk to them on the 8502.)
> 

smartmontools should support 3ware 7xxx & 8xxx controllers, although
not 9xxx controllers.  See the answer to the question 'Can I monitor
ATA disks behind SCSI RAID controllers?' at
http://smartmontools.sourceforge.net/#FAQ.  Although the answer is
for Linux, it applies to FreeBSD as well.  You have to use '-d 3ware,N'
with every command, where N is the unit #.
Ex: smartctl -H -A -d 3ware,1 /dev/twed


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Applied Micro Circuits Corporation or its 
subsidiaries. It is to be used solely for the purpose of furthering the 
parties' business relationship. All unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Igor Robul]

Maxim M. Kazachek wrote:

SoftModems works (well, almost) perfectly under Windows. Some of these 
works under Linux. SoftModems is the best, because they are cheap and 
works under Windows. The FreeBSD is puny OS just because they lack 
support of Software modem.
The thing is as worth as much you paid for it. If Silicon Image made 
BUGGY hardware, we should do just two things:
1. (the way we walked) Mark it as BROKEN. Perhaps we should document 
it, BUT... If things don't work, READ the manual, at last...
2. (the way linux walked) Try to make some QUIRKS to avoid problems 
for performance. The QUIRKS count will grow and some time later the 
NORMAL controller become QUIRK.


Even if we choose second way, there will be a lot of rocks at Soren's 
side, that "Goddamn, I've purchased SiI3112 card, WD Raptor, why the 
my config DAMN slow comparing with, say, config with ICH... DAMN, fix 
this IMMEDIATELY".


Completely agree! Also, SII3112 does NOT work with Windows WELL. You 
just cant "make -j4 buildworld" on Windows  to have EASY way to put 
reasonable load on controller. But I have seen reports from Windows 
users about brokeness of some integrated (and not integrated) SATA 
controllers.


Most of FreeBSD users just ASSUME that hardware works with Windows, 
because they (users of FreeBSD) dont
read forums of Windows users. Just try "SII3112 Windows trouble", also 
pay attention, that most Windows users just dont know which SATA 
controller is embeded to their motherboard.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[Fwd: Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599]

[Igor Robul]

--- Begin Message ---

Joel Rees wrote:

I have two which reliably fail if you put TWO disks on them in a  
gmirror

config within minutes of starting a "make buildworld".



Pardon the interruption, but is this two drives on one channel?


Two drives can not be on one channel on SATA controller.
Also try "Sii3112 Windows trouble" on any search site  and you'll find 
many links to problem reports.
SII3112 IS NOT Server (even small-server) chipset. It does not work well 
with semi-heavy load.
Of course, you can install and use FreeBSD, Linux, Windows on it, just 
dont put load on it with 2 disks.


--- End Message ---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Maxim M. Kazachek]

SoftModems works (well, almost) perfectly under Windows. Some of these 
works under Linux. SoftModems is the best, because they are cheap and 
works under Windows. The FreeBSD is puny OS just because they lack support 
of Software modem.
The thing is as worth as much you paid for it. If Silicon Image made BUGGY 
hardware, we should do just two things:
1. (the way we walked) Mark it as BROKEN. Perhaps we should document it, 
BUT... If things don't work, READ the manual, at last...
2. (the way linux walked) Try to make some QUIRKS to avoid problems for 
performance. The QUIRKS count will grow and some time later the NORMAL 
controller become QUIRK.


Even if we choose second way, there will be a lot of rocks at Soren's 
side, that "Goddamn, I've purchased SiI3112 card, WD Raptor, why the my 
config DAMN slow comparing with, say, config with ICH... DAMN, fix 
this IMMEDIATELY".



   Sincerely, Maxim M. Kazachek
   mailto:[EMAIL PROTECTED]


On Wed, 10 Aug 2005, J. T. Farmer wrote:


Mike Tancsa wrote:


At 09:31 AM 10/08/2005, Karl Denninger wrote:

Also, I've yet to see a developer commit on the list that they WILL fix it 
if
such a controller board is forthcoming (and will return the board when 
they're
done) - I've got two of these cards here (choose between Adaptec and 
Bustek)
and would be happy to UPS one to someone IF I had a firm commitment that 
6.x

would NOT go out without this being addressed and that the board would be
returned to me when work was complete.



You demand to see support for this chipset fixed, yet, you cant pony up a 
measly hundred bucks to donate the card to the developer who is not being 
paid to develop anything.


Why?  It was claimed that the code was developed to support this chipset.
Was that done in the dark, without hardware?  And why must it be a
hardware donation?  Karl has offered access to the hardware.  Asking to
get it back afterwards is a reasonable thing.  If the developer wants to
keep the card as part of a verification hardware suite, then they should
open their mouth and say so.  I suspect that Karl, and many other people,
would be more forthcoming with such donations if 1.) They were asked
in a reasonable manner, 2.) The hardware in question have not already
been listed as working under 5.x, and 3.) They had some assurance that
the problem would be fixed.

And finally, the problem has been reported in 5.4 and apparently in
6.0-Beta _not _only_ for the SII chipset & SATA, but also for some
of the Intel ICH chipsets.  And others, such as myself, are seeing the
same problem with plain PATA drives and controllers that are listed
as being supported by the ata driver.

In my case, a vanilla, OLD but working Via KT266A/8235 chipset MB
_will_not_boot an install kernel unless booted in safe mode.  I don't have
the resources to just give away hardware or buy replacements, just to
run FreeBSD as my desktop/development machine.  It runs WinXP and
Linux just fine.  However I _want_ to run FreeBSD.  Part of the that
machine's rational is so that I can contribute in my areas of interest
(sound & video editing/production tools, documentation).  I chose to
install 5.4, the PRODUCTION version, because I did not want any
surprises, did not want to be hacking a basic system functions.

At what point do I give up and just reformat the FreeBSD partition
and either release it to use with WinXP or install Linux?  Now mind
you, I've used FreeBSD, as a production platform, since 2.0.X.  I've
survived a fair number of "bumps."   But I'm at the point that I really
want the things that are claimed to work to just work.  I continue  to
run my servers under 4.X because or all the upheaval in 5.0/5.1/etc.
But 5.4 was supposed to have those teething problems behind it.
And the so far the only answer I get is try the ATA MkIII patches for
a partial fix, move to 6.0 for a real solution. 
So when will 6.X really be Stable?  Yes, I understand that the RE is

working on getting 6.0 out the door.  But what users are trying to tell
you is that we need an answer for these problems.  If the production
release is broken for certain hardware, say so.  If FreeBSD developers
would rather work on big hairy server oriented problems, then say so.
If we have to run beta code to get old hardware to work, then say so.
Then we can make a choice as to what we run or try to use.  If
no one is interested in making FreeBSD work on the vanilla hardware
that is out there, then say so.  If FreeBSD is only going to run on
expensive hand picked hardware (the Sun approach) then say so.
Those of us who want to switch desktops and light duty servers
to FreeBSD will give up and move to Linux.  OR back to WinXP.

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
  Consulting, Design, & Development of Networks & Software

__

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Joel Rees]

I have two which reliably fail if you put TWO disks on them in a  
gmirror

config within minutes of starting a "make buildworld".


Pardon the interruption, but is this two drives on one channel?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[J. T. Farmer]

Karl Denninger wrote:


From the online man page for ata.4, which is EXPLICITLY referenced as THE

authoritative list of which disk controllers it supports:


The currently supported ATA/SATA controller chips are:

Acard:   ATP850P, ATP860A, ATP860R, ATP865A, ATP865R
ALI: Aladdin (ALi5229) compatible chips.
AMD: AMD756, AMD766, AMD768, AMD8111.
CMD: CMD646, CMD648, CMD649.
Cypress: Cypress 82C693.
Cyrix:   Cyrix 5530.
HighPoint:  HPT302, HPT366, HPT366, HPT368, HPT370, HPT371, HPT372,
 HPT374.
Intel:   PIIX, PIIX3, PIIX4, ICH, ICH0, ICH2, ICH3, ICH4, ICH5.
ITE: IT8212F.
National:SC1100.
nVidia:  nForce, nForce2, nForce3.
Promise: PDC20246, PDC20262, PDC20263, PDC20265, PDC20267,
 PDC20268, PDC20269, PDC20270, PDC20271, PDC20275,
 PDC20276, PDC20277, PDC20318, PDC20319, PDC20371,
 PDC20375, PDC20376, PDC20377, PDC20378, PDC20379,
 PDC20617, PDC20618, PDC20619, PDC20620.
 



Karl, Thanks for listing this.  I overlooked that my older Promise 20265 
on this other

box is "supposedly" supported.  Now I wonder what will happen when I try it.

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
   Consulting, Design, & Development of Networks & Software

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[J. T. Farmer]

Chuck Swiger wrote:


Karl Denninger wrote:


On Thu, Aug 11, 2005 at 12:46:04AM +0200, S?ren Schmidt wrote:


[ ... ]

I've already gone WAY out of my way to try to support the sii3112,  
and I'm not inclined to waste more of my precious spare time on it.  
However, if it really is that important to enough people to try to  
workaround the silicon bugs (which very likely isn't possible), get  
together and get me failing HW on my desk and time to work on it.


Ok, then do the RIGHT THING and document that the SiI chips are declared
BROKEN by FreeBSD and likely to cause people trouble - including 
irrevocable data corruption.


This would have saved me COUNTLESS hours when I first ran into this 
issue.  Indeed, it was not until someone else started posting 
excerpts from commit logs (months after I filed the PR originally!) 
that I was aware FreeBSD developers considered these chipsets 
"damaged goods".


Look, Karl, we're all as sorry as we can be that you've spent lots of 
time on this issue and/or you've had data get corrupted.  You should 
not rely on that sympathy to be endless.


FreeBSD attempts to document that it works with common hardware which 
follows industry standards and is not otherwise broken.  The 
information available to me suggests the SiI 3112 is broken.  It has 
multiple hardware defects involving ATA request-size handling (SIIBUG 
in ata_sii_allocate() in dev/ata/ata-chipset.c around line ~2300, or 
what the Linux guys call SIL_QUIRK_MOD15WRITE), and with LBA48 if used 
with various Seagate drives.



Does it work with Linux?  Does it work with any of the *BSD? Does it work
with Windows XP?  So what answer do we give when discussions about OS
selection is done?  "Well, FreeBSD is really a rock solid OS, if you 
cherry pick

prime hardware, and can configure it"  And they answer, XP installs and
runs.  Linux installs and runs.  So as I said in a previous note,  is 
FreeBSD
going down the Sun Microsystems path?  "We work really, really well, but 
only on

prime server grade hardware"

Is the Via 8235 controller for PATA broken?  It and it's brothers are on
9 gazillion Athlon mainboards.  That's what I get the DMA_READ and
DMA_WRITE errors on. 

I've got an older Soyo MB that I had intended to use as household 
fileserver. 
It has a  Via 8233 for PATA and a promise 20265 raid controller.  How 
likely
are these to work?  The 8233 is listed as supported by the ata driver, 
but so

was the 8237 that's in my desktop machine. Is support going to be spotty
for that older chipset?  The Promise 20265 is supported by 4.11, but does
not appear to be in 5.4 or 6.0.  Yeah this is older hardware, but it's not
that old.


[ ...some 200 (!) lines of ranting at poor Soren deleted :-)... ]

I haven't seen a diatribe like this one since those green JPCON 
capacitors which leaked and fried motherboards everywhere, or maybe 
even since those old KT266 motherboards, which were supposed to do 4x 
AGP but would lock up hard when some slavering gamer tried to make his 
$500 new 4x AGP card go.



You get diatribes when you ignore problems users are having.  The
fact that you have broken the Principle of Least Surprise makes
it worse.  The fact that you appear to not care, that the only
answers are "we decided that it's broken, so we aren't going do
anything with it..." or "Well try using Current."  Damn it, once
upon a time Stable was stable, and and you used Current at your
own risk.  Now we are being told that what we thought was
stable isn't working and we must use cutting edge software to
try to get a stable system. 

Finally you get diatribes when users are trying to get your attention. 
I could have installed Fedora on my desktop several months ago.

I would have freed up a bunch of time.  My wife wouldn't have to
listen to gripe and curse as I searched mailing list archives and web
sites trying to find an answer.  The WinXP machine on desk would
have been sent on it's way and a Unix box would be there.


Anyway, yeah, you got it: some SII chipsets don't work right.

FreeBSD tries to compensate; for some people it works OK for what they 
are doing, and for others it doesn't.  Blow $25 and get a cheap 4-port 
SATA-150 RAID card using something other than a SiI 3112.  Blow $50 
and you can even get one from a vendor like Promise or Highpoint 
that's at least somewhat reputable, and/or provides open source 
drivers and FreeBSD support for their products.


So I should support a pr to change the docs for the Via chipsets for
PATA drives.  "Warning!  Used to work, may or may not work with
current Stable systems."

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
   Consulting, Design, & Development of Networks & Software

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

On Wed, Aug 10, 2005 at 09:47:38PM -0400, Chuck Swiger wrote:
> Karl Denninger wrote:
> >On Thu, Aug 11, 2005 at 12:46:04AM +0200, S?ren Schmidt wrote:
> [ ... ]
> >>I've already gone WAY out of my way to try to support the sii3112,  
> >>and I'm not inclined to waste more of my precious spare time on it.  
> >>However, if it really is that important to enough people to try to  
> >>workaround the silicon bugs (which very likely isn't possible), get  
> >>together and get me failing HW on my desk and time to work on it.
> >
> >Ok, then do the RIGHT THING and document that the SiI chips are declared
> >BROKEN by FreeBSD and likely to cause people trouble - including 
> >irrevocable data corruption.
> >
> >This would have saved me COUNTLESS hours when I first ran into this 
> >issue.  Indeed, it was not until someone else started posting excerpts 
> >from commit logs (months after I filed the PR originally!) that I was 
> >aware FreeBSD developers considered these chipsets "damaged goods".
> 
> Look, Karl, we're all as sorry as we can be that you've spent lots of time 
> on this issue and/or you've had data get corrupted.  You should not rely on 
> that sympathy to be endless.

I'm not asking for ANY sympathy.

I'm asking for the documentation to properly reflect KNOWN problems with
a given chipset or device, rather than burying them.

> FreeBSD attempts to document that it works with common hardware which 
> follows industry standards and is not otherwise broken.  

Good, as far as it goes.

> The information 
> available to me suggests the SiI 3112 is broken.  It has multiple hardware 
> defects involving ATA request-size handling (SIIBUG in ata_sii_allocate() 
> in dev/ata/ata-chipset.c around line ~2300, or what the Linux guys call 
> SIL_QUIRK_MOD15WRITE), and with LBA48 if used with various Seagate drives.

That's all "quirk" stuff - that is, it will work, but perhaps not return the
best performance.

> I've also gotten the impression that the chipset is prone to locking up the 
> entire system under high load, especially under RAID-1 mirroring or other 
> parallel access cases, because it mishandles interrupts or some such.

Now that's an entirely different matter, .

This is particularly true when the "workarounds" were just fine for 4.x, but
suddenly blow chunks under 5.4 and later due to arthitectural changes made
in that driver.

> Given that this is the case, I would be looking to get my money back or a 
> replacement from the vendor who sold me this crappy hardware, far more than 
> I would be looking towards implementing software workarounds which cripple 
> the performance of the system in order to safely work around the hardware 
> errata.

Not the point here.

I agree the hardware is crappy, if the reported issues are correct.

> >Where is fair warning in the hardware compatability guide?
> 
> http://www.freebsd.org/platforms/amd64/motherboards.html ...?

Note the "SiI UNTESTED" lines in that list?

Its not untested.  Its known to be broken!  Again, WHERE IS THE WARNING?

Second, I don't have an AMD system - I have a HT P4.

>From the online man page for ata.4, which is EXPLICITLY referenced as THE
authoritative list of which disk controllers it supports:


The currently supported ATA/SATA controller chips are:

 Acard:  ATP850P, ATP860A, ATP860R, ATP865A, ATP865R
 ALI:Aladdin (ALi5229) compatible chips.
 AMD:AMD756, AMD766, AMD768, AMD8111.
 CMD:CMD646, CMD648, CMD649.
 Cypress:Cypress 82C693.
 Cyrix:  Cyrix 5530.
 HighPoint:  HPT302, HPT366, HPT366, HPT368, HPT370, HPT371, HPT372,
 HPT374.
 Intel:  PIIX, PIIX3, PIIX4, ICH, ICH0, ICH2, ICH3, ICH4, ICH5.
 ITE:IT8212F.
 National:   SC1100.
 nVidia: nForce, nForce2, nForce3.
 Promise:PDC20246, PDC20262, PDC20263, PDC20265, PDC20267,
 PDC20268, PDC20269, PDC20270, PDC20271, PDC20275,
 PDC20276, PDC20277, PDC20318, PDC20319, PDC20371,
 PDC20375, PDC20376, PDC20377, PDC20378, PDC20379,
 PDC20617, PDC20618, PDC20619, PDC20620.
 ServerWorks:ROSB4, CSB5, CSB6.
 Silicon Image:  SiI0680, SiI3112, SiI3114, SiI3512.

Note that last line (I omitted the rest)

Note CLEARLY the absence of any warning that these chipsets are BROKEN, 
either here or anywhere else in that document page.

SUPPORTED means 

If you're going to withdraw support, as Soren is apparently doing, then 
by God, WITHDRAW IT!  Get that line out of there and remove the sense data
from the module or make it conditional on a specific option in the kernel.

> >Is it thus necessary for us "mere users" to consider this an issue that 
> >will simply not be addressed?  If so, then just say so up front  >DOCUMENT THAT THE SII CHIPSETS DON'T WORK RIGHT.>
> [ ...some 200 (!) lines of ranting at poor Soren deleted :-)... ]

I'm ranting beca

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Chuck Swiger]

Karl Denninger wrote:

On Thu, Aug 11, 2005 at 12:46:04AM +0200, S?ren Schmidt wrote:

[ ... ]
I've already gone WAY out of my way to try to support the sii3112,  
and I'm not inclined to waste more of my precious spare time on it.  
However, if it really is that important to enough people to try to  
workaround the silicon bugs (which very likely isn't possible), get  
together and get me failing HW on my desk and time to work on it.


Ok, then do the RIGHT THING and document that the SiI chips are declared
BROKEN by FreeBSD and likely to cause people trouble - including irrevocable 
data corruption.


This would have saved me COUNTLESS hours when I first ran into this 
issue.  Indeed, it was not until someone else started posting excerpts 
from commit logs (months after I filed the PR originally!) that I was 
aware FreeBSD developers considered these chipsets "damaged goods".


Look, Karl, we're all as sorry as we can be that you've spent lots of time on 
this issue and/or you've had data get corrupted.  You should not rely on that 
sympathy to be endless.


FreeBSD attempts to document that it works with common hardware which follows 
industry standards and is not otherwise broken.  The information available to 
me suggests the SiI 3112 is broken.  It has multiple hardware defects involving 
ATA request-size handling (SIIBUG in ata_sii_allocate() in 
dev/ata/ata-chipset.c around line ~2300, or what the Linux guys call 
SIL_QUIRK_MOD15WRITE), and with LBA48 if used with various Seagate drives.


I've also gotten the impression that the chipset is prone to locking up the 
entire system under high load, especially under RAID-1 mirroring or other 
parallel access cases, because it mishandles interrupts or some such.


Given that this is the case, I would be looking to get my money back or a 
replacement from the vendor who sold me this crappy hardware, far more than I 
would be looking towards implementing software workarounds which cripple the 
performance of the system in order to safely work around the hardware errata.



Where is fair warning in the hardware compatability guide?


http://www.freebsd.org/platforms/amd64/motherboards.html ...?

Second, your requirement for  hardware  simply can't be 
met.  It is not possible for anyone to manufacture or deliver time.  


"Donne-moi, monsieur, tout mais les temps...?"  :-)

Is it thus necessary for us "mere users" to consider this an issue that 
will simply not be addressed?  If so, then just say so up front DOCUMENT THAT THE SII CHIPSETS DON'T WORK RIGHT.>

[ ...some 200 (!) lines of ranting at poor Soren deleted :-)... ]

I haven't seen a diatribe like this one since those green JPCON capacitors 
which leaked and fried motherboards everywhere, or maybe even since those old 
KT266 motherboards, which were supposed to do 4x AGP but would lock up hard 
when some slavering gamer tried to make his $500 new 4x AGP card go.


Anyway, yeah, you got it: some SII chipsets don't work right.

FreeBSD tries to compensate; for some people it works OK for what they are 
doing, and for others it doesn't.  Blow $25 and get a cheap 4-port SATA-150 
RAID card using something other than a SiI 3112.  Blow $50 and you can even get 
one from a vendor like Promise or Highpoint that's at least somewhat reputable, 
and/or provides open source drivers and FreeBSD support for their products.


If it makes you feel better, submit this as a PR against the docs category:

--- ata.4~  Tue Apr  5 14:28:00 2005
+++ ata.4   Wed Aug 10 21:43:05 2005
@@ -129,7 +129,7 @@
 .It ServerWorks:
 ROSB4, CSB5, CSB6.
 .It Silicon Image:
-SiI0680, SiI3112, SiI3114, SiI3512.
+SiI0680, SiI3114, SiI3512.  SiI3112 has hardware errata and may not work.
 .It SiS:

--
-Chuck

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

On Thu, Aug 11, 2005 at 12:46:04AM +0200, S?ren Schmidt wrote:
> 
> On 10/08/2005, at 22:51, Karl Denninger wrote:
> >
> >This is the subject of the PR I filed back in February.
> >
> >Again, if you want either a controller shipped to you OR access to a
> >development machine (e.g. ssh in and play) which has the suspect
> >configuration on it, the latter of which is probably the best  
> >option (since
> >making it fail is simple) I'm willing to provide either - my only  
> >caveat is
> >that if I send hardware I want it back when you're done, and I  
> >believe its
> >reasonable to expect that 6.0 will get HELD in its release cycle  
> >until this
> >is resolved.
> 
> I have plenty of the sii3112's around, so thats not needed, however  
> I've not managed to get ahold of a machine in which it fails reliably  
> with ATA as is in 6.0.

I have two which reliably fail if you put TWO disks on them in a gmirror
config within minutes of starting a "make buildworld".  With one disk
it takes a bit longer and more effort, but can still be forced to fail.

It appears to require a mix of read and write operations and a fairly heavy
- but not horiffically so - I/O load to make it blow up.

All reads or all writes do NOT fail.  For example, you can do a gmirror
rebuild and it will succeed.  That's all writes (to the new disks) until
complete.  Seconds to minutes after the rebuilds complete if the system 
is under heavy random I/O load it will fail.

>From this and other tests I've concluded that a MIX of read and write
operations are required, and the total load must be substantial.  Either
reads alone or writes alone do not appear to provoke it, even with 100% 
disk utilization.

> >The latter offer (ssh access) has been on the table for several  
> >months.  The
> >former I just put on the table as I threw up my hands and bought a  
> >3ware
> >card - which means I now have TWO of the suspect cards and need  
> >only one
> >for my own testing (in the sandbox)
> >
> >I'm willing to go WELL out of my way to make it possible for this  
> >to get
> >fixed, since there appears to be an issue with access to hardware that
> >breaks reliably.  However, I, and others, would like to know that  
> >we're
> >going to see the problem get resolved.
> 
> I've already gone WAY out of my way to try to support the sii3112,  
> and I'm not inclined to waste more of my precious spare time on it.  
> However, if it really is that important to enough people to try to  
> workaround the silicon bugs (which very likely isn't possible), get  
> together and get me failing HW on my desk and time to work on it.

Ok, then do the RIGHT THING and document that the SiI chips are declared
BROKEN by FreeBSD and likely to cause people trouble - including irrevocable 
data corruption.

This would have saved me COUNTLESS hours when I first ran into this 
issue.  Indeed, it was not until someone else started posting excerpts 
from commit logs (months after I filed the PR originally!) that I was 
aware FreeBSD developers considered these chipsets "damaged goods".

Where is fair warning in the hardware compatability guide?

Second, your requirement for  hardware  simply can't be 
met.  It is not possible for anyone to manufacture or deliver time.  

Is it thus necessary for us "mere users" to consider this an issue that 
will simply not be addressed?  If so, then just say so up front 

> >Again - this is hardware that is STABLE and works under 4.x - in  
> >the case of
> >my specific configuration I ran under 4.x for over a year without a  
> >single
> >incident.  With 5.4 and 6.0-BETA I can kill it inside of 2 minutes  
> >with
> >nothing more complicated than a "make -j4 buildworld".
> 
> First. you cannot by any degree of the word call the sii3112 for  
> STABLE hardware, its broken beyond repair or workarounds,  and even  
> the supplier acknowledges that fact.

Well then how about if FreeBSD officially DECLARES this hardware to be
broken beyond repair and workaround, and simply says "if this doesn't work
for you, don't bitch or complain, because we have nothing further we can 
do about it"?

That is acceptable, although I bet it costs 'ya a fair number of users,
particularly in the small server and workstation markets.  Of course since
its not "money lost", that may be perfectly OK to the FreeBSD team. 

It definitely will change MY focus as a developer of software often run on 
small office and home network machines though.  It HAS TO Soren.  

This isn't a matter of me not wanting to be a FreeBSD evangelist - but
if I try to tell people that half of the machines out there that they might
run FreeBSD on are likely to fail, and if they do my only recommendation is
"sorry, I can't do anything about it other than sell you this hardware", the
obvious next reply is that they will want the software to be made available 
on an operating system that DOESN'T blow up like this.  Linux ends up being
something I have to support of necessity down that road.

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Søren Schmidt]

On 11/08/2005, at 0:28, Randy Bush wrote:


As I said I need reports on 6.0, the ATA driver as is in 5.4 is not
supported by me unless you use the ATA mkIII patches..



you know, we just upgraded a system from 4.11 to 7.0 and see problems.
we have been chasing cables, and never considered that we could blame
all our problems on you and demand service!  :-)



I'd rather put it like this: "you got what you payed for" ;)



ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729217
ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729217
ad2: FAILURE - WRITE_DMA status=51  
error=84 LBA=7

ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729222
ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729222
ad2: FAILURE - WRITE_DMA status=51  
error=84 LBA=2


atapci0:  port  
0x5020-0x5027,0x5014-0x50175

ata2:  on atapci0
ata3:  on atapci0
pci4:  at device 30.0 (no  
driver attache)

pcib6:  at device 31.0 on pci4
pci6:  on pcib6
atapci1:  port  
0x6020-0x6027,0x6014-0x60176

ata4:  on atapci1
ata5:  on atapci1
pci0:  at device 29.0 (no driver attached)
pci0:  at device 29.1 (no driver attached)
pci0:  at device 29.2 (no driver attached)
pcib7:  at device 30.0 on pci0
pci7:  on pcib7
pci7:  at device 1.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci2:  port  
0x1f0-0x1f7,0x3f6,0x170-0x177,0x30

ata0:  on atapci2
ata1:  on atapci2


Could I have the *complete* dmesg please ?


h

i demand a full refund


granted! just get it from where you bought it :)

- Søren



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Søren Schmidt]

On 10/08/2005, at 22:51, Karl Denninger wrote:


Since I came in late in this, I need to know what kind of controller
we are talking about, and if the problem is still present in 6.0.
I plan to backport ATA from 6.0 to 5-stable when it has settled, so
6.0 is the one and only (pre)release to test with and get back to me
with the result.

- S?ren



6.0 BETA1 AND 5.4 BOTH fail with the SiI 3112 chipsets.  Reliably.


I have two controllers here that are from different manufacturers  
and both
exhibit the same problem.  The SAME disks (two different  
manufacturers -

hitachi and maxtor) on a motherboard ICH5 adapter work perfectly,
smartmontools says all 4 (I have two examples of each) are healthy,  
and

both ALSO work perfectly on and are declared healthy by a 3ware 8502's
internal diags and operating kernel (smartmontools won't talk to  
them on

the 8502.)

This is the subject of the PR I filed back in February.

Again, if you want either a controller shipped to you OR access to a
development machine (e.g. ssh in and play) which has the suspect
configuration on it, the latter of which is probably the best  
option (since
making it fail is simple) I'm willing to provide either - my only  
caveat is
that if I send hardware I want it back when you're done, and I  
believe its
reasonable to expect that 6.0 will get HELD in its release cycle  
until this

is resolved.


I have plenty of the sii3112's around, so thats not needed, however  
I've not managed to get ahold of a machine in which it fails reliably  
with ATA as is in 6.0.


The latter offer (ssh access) has been on the table for several  
months.  The
former I just put on the table as I threw up my hands and bought a  
3ware
card - which means I now have TWO of the suspect cards and need  
only one

for my own testing (in the sandbox)

I'm willing to go WELL out of my way to make it possible for this  
to get

fixed, since there appears to be an issue with access to hardware that
breaks reliably.  However, I, and others, would like to know that  
we're

going to see the problem get resolved.


I've already gone WAY out of my way to try to support the sii3112,  
and I'm not inclined to waste more of my precious spare time on it.  
However, if it really is that important to enough people to try to  
workaround the silicon bugs (which very likely isn't possible), get  
together and get me failing HW on my desk and time to work on it.


Again - this is hardware that is STABLE and works under 4.x - in  
the case of
my specific configuration I ran under 4.x for over a year without a  
single
incident.  With 5.4 and 6.0-BETA I can kill it inside of 2 minutes  
with

nothing more complicated than a "make -j4 buildworld".


First. you cannot by any degree of the word call the sii3112 for  
STABLE hardware, its broken beyond repair or workarounds,  and even  
the supplier acknowledges that fact.
Second, you cannot possibly have used gmirror (as in the PR) on 4.x  
so what was the config back then ?
Third, please get gmirror out of the loop (use atacontrol to create a  
mirror if need be) and let me know if that changes anything.
Forth, another thing to try is fumbling with BIOS settings, some  
setups has been reported to start working when PCI timings is changed  
YMMV..


- Søren



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Randy Bush]

> As I said I need reports on 6.0, the ATA driver as is in 5.4 is not  
> supported by me unless you use the ATA mkIII patches..

you know, we just upgraded a system from 4.11 to 7.0 and see problems.
we have been chasing cables, and never considered that we could blame
all our problems on you and demand service!  :-)

ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729217
ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729217
ad2: FAILURE - WRITE_DMA status=51 error=84 LBA=7
ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729222
ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729222
ad2: FAILURE - WRITE_DMA status=51 error=84 LBA=2

atapci0:  port 0x5020-0x5027,0x5014-0x50175
ata2:  on atapci0
ata3:  on atapci0
pci4:  at device 30.0 (no driver attache)
pcib6:  at device 31.0 on pci4
pci6:  on pcib6
atapci1:  port 0x6020-0x6027,0x6014-0x60176
ata4:  on atapci1
ata5:  on atapci1
pci0:  at device 29.0 (no driver attached)
pci0:  at device 29.1 (no driver attached)
pci0:  at device 29.2 (no driver attached)
pcib7:  at device 30.0 on pci0
pci7:  on pcib7
pci7:  at device 1.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci2:  port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x30
ata0:  on atapci2
ata1:  on atapci2

h

i demand a full refund

randy, still chasing cables

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Emanuel Strobl]

Am Mittwoch, 10. August 2005 19:48 CEST schrieb Unix:
> O. Hartmann wrote:
> > Mike Jakubik wrote:
> >> On Wed, August 10, 2005 6:37 am, Dmitry Mityugov said:
> >>> There are Maxtor MaXLine II and III, and perhaps several other
> >>> models, that are supposed to work 24/7.
> >>
> >> Right, i have a dead 250GB Maxline Plus II drive on my desk, only
> >> after about 1.5 years. At least its still on warranty.
> >
> > On the other hand: In the department for physics of the athmosphere,
> > where I built six years ago a server for meteorological data, a RAID-5
> > with 4 older IBM U160 SCSI discs still works - 24/7. Never had a
> > problem!
>
> I still own old 1-2 GB old SCSI disks and these are still working, I
> also had an old 500mb SCSI disk that was in an old Mac that also worked
> but I trashed it since it was that old and no longer of use...

I have an old 700 MB WD IDE drive that still works fine and has about 6 
years 24/7 survived. And I also had a 2000$ 73G SCSI IBM drive that lasted 
for about 5 monthas and was that damadged that Convar sent it back without 
one byte recovered! And I don't want to remember the 80GB WD drive that 
lasted for 2 months..
Please, don't discuss about SCSI/ATA reliability, there are bad 
designed/produced drives and there are good ones. You can't tell before, 
only experience counts.
I can say only good things about Seagates Barracuda 7200.8 drives for 
example. Some dozends are running for two years without _any_ single drive 
failed. Also the Samsung (p)ATA drives are still running without any 
single failure. And WDs once were perfect drices, but they also produced 
crap. So you can't even be sure by vendor!

-Harry

P.S.: I'm planning to bring up a FreeBSD site which reflects hardware 
compatibility experiences as well as long term experiences. I'll be back 
if I have more...


pgpO99dRlvrUu.pgp
Description: PGP signature

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

On Wed, Aug 10, 2005 at 08:36:39PM +0200, S?ren Schmidt wrote:
> 
> On 10/08/2005, at 20:05, Scot Hetzel wrote:
> >>
> >>Since I came in late in this, I need to know what kind of controller
> >>we are talking about, and if the problem is still present in 6.0.
> >>I plan to backport ATA from 6.0 to 5-stable when it has settled, so
> >>6.0 is the one and only (pre)release to test with and get back to me
> >>with the result.
> >>
> >>
> >
> >They have been talking about SII and Intel ICH6 chips.  And a few have
> >stated that they are having problems with the 6.0-Beta releases with
> >these chips.
> 
> Well, both work wonderfully here YMMV of course..
> 
> No, seriously I need *much* more accurate info than that, I need the  
> dmesg from the failing system, and I need an exact description of the  
> problem, preferably with logs, dumbs etc etc.
> 
> - S?ren

http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/83974

Filed on July 24th.

Again, happy to give you SSH access to  if it will 
work towards getting this resolved.

--
-- 
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org   Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.comMusings Of A Sentient Mind


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

On Wed, Aug 10, 2005 at 07:24:01PM +0200, S?ren Schmidt wrote:
> 
> On 10/08/2005, at 17:44, Scot Hetzel wrote:
> 
> >On 8/10/05, Karl Denninger <[EMAIL PROTECTED]> wrote:
> >
> >>On Wed, Aug 10, 2005 at 09:51:03AM -0400, Mike Tancsa wrote:
> >>
> >>>At 09:31 AM 10/08/2005, Karl Denninger wrote:
> >>>
> >>>
> Also, I've yet to see a developer commit on the list that they  
> WILL fix it
> if
> such a controller board is forthcoming (and will return the  
> board when
> they're
> done) - I've got two of these cards here (choose between Adaptec  
> and
> Bustek)
> and would be happy to UPS one to someone IF I had a firm  
> commitment that
> 6.x
> would NOT go out without this being addressed and that the board  
> would be
> returned to me when work was complete.
> 
> >>>
> >>>You demand to see support for this chipset fixed, yet, you cant  
> >>>pony up a
> >>>measly hundred bucks to donate the card to the developer who is  
> >>>not being
> >>>paid to develop anything.
> >>>
> >>>---Mike
> >>>
> >>
> >>I have "demanded" nothing Mike.
> >>
> >>
> >I agree Mike's wording was a little strong, but we have seen you
> >request strongly that some one fix this problem.
> >
> >Have you contacted S?ren, to see if he has the troublesome hardware?
> >
> >Also contact S?ren directly with your offer to supply a troublesome
> >board, and/or access to a system that displays the problem.  More than
> >likely he would agree to return the board once he has a proper fix for
> >the problem.
> 
> Since I came in late in this, I need to know what kind of controller  
> we are talking about, and if the problem is still present in 6.0.
> I plan to backport ATA from 6.0 to 5-stable when it has settled, so  
> 6.0 is the one and only (pre)release to test with and get back to me  
> with the result.
> 
> - S?ren

6.0 BETA1 AND 5.4 BOTH fail with the SiI 3112 chipsets.  Reliably.

I have two controllers here that are from different manufacturers and both
exhibit the same problem.  The SAME disks (two different manufacturers -
hitachi and maxtor) on a motherboard ICH5 adapter work perfectly, 
smartmontools says all 4 (I have two examples of each) are healthy, and 
both ALSO work perfectly on and are declared healthy by a 3ware 8502's
internal diags and operating kernel (smartmontools won't talk to them on 
the 8502.)

This is the subject of the PR I filed back in February.

Again, if you want either a controller shipped to you OR access to a
development machine (e.g. ssh in and play) which has the suspect
configuration on it, the latter of which is probably the best option (since 
making it fail is simple) I'm willing to provide either - my only caveat is 
that if I send hardware I want it back when you're done, and I believe its 
reasonable to expect that 6.0 will get HELD in its release cycle until this 
is resolved.

The latter offer (ssh access) has been on the table for several months.  The
former I just put on the table as I threw up my hands and bought a 3ware
card - which means I now have TWO of the suspect cards and need only one 
for my own testing (in the sandbox)

I'm willing to go WELL out of my way to make it possible for this to get
fixed, since there appears to be an issue with access to hardware that
breaks reliably.  However, I, and others, would like to know that we're
going to see the problem get resolved.

Again - this is hardware that is STABLE and works under 4.x - in the case of
my specific configuration I ran under 4.x for over a year without a single
incident.  With 5.4 and 6.0-BETA I can kill it inside of 2 minutes with 
nothing more complicated than a "make -j4 buildworld".

Let me know if you'd like to take me up on either of my offers.  Note that
with 6.0-BETA (what's currently on the sandbox machine) when it blows up it
does so in such a way that a reboot FAILS (it hangs during the shutdown
sequence!) so you need to hit the red button to get a clean restart (and
wait for the FSCK)

I have a PATA drive in the sandbox machine on the motherboard adapter that
is part of a mirror with the "bad" controller, so there is no risk of data
corruption - when it fails the "bad" disk disconnects from the array but
the boot drive remains "safe".

--
-- 
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org   Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.comMusings Of A Sentient Mind


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Søren Schmidt]

On 10/08/2005, at 20:29, J. T. Farmer wrote:


Scot Hetzel wrote:



On 8/10/05, Søren Schmidt <[EMAIL PROTECTED]> wrote:



Since I came in late in this, I need to know what kind of controller

we are talking about, and if the problem is still present in 6.0.
I plan to backport ATA from 6.0 to 5-stable when it has settled, so
6.0 is the one and only (pre)release to test with and get back to me
with the result.


They have been talking about SII and Intel ICH6 chips.  And a few  
have

stated that they are having problems with the 6.0-Beta releases with
these chips.




What, I'm chopped liver? :^>  I'm getting these errors with a  
standard, _very_
not "state of the art", Via KT266A/8235 chipset.  PATA WDC 800  
drive. All very standard stuff for a desktop.  Was running WinXP  
without a
problem for quite some time.  Generic kernel.  In fact when I tried  
to install 5.4
(and 5.4-SNAP from 5 July & 9 July), it errored out as soon as the  
install kernel
tried to write to the disk.  FS's do not work when you can't  write  
the superblocks

out...  Oh yeah, writing the disklabel also generated the same error.

So it's not just the SATA raid type chipsets.  It's plain vanilla ATA
controllers, also.


As I said I need reports on 6.0, the ATA driver as is in 5.4 is not  
supported by me unless you use the ATA mkIII patches..


- Søren



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Søren Schmidt]

On 10/08/2005, at 20:05, Scot Hetzel wrote:


Since I came in late in this, I need to know what kind of controller
we are talking about, and if the problem is still present in 6.0.
I plan to backport ATA from 6.0 to 5-stable when it has settled, so
6.0 is the one and only (pre)release to test with and get back to me
with the result.




They have been talking about SII and Intel ICH6 chips.  And a few have
stated that they are having problems with the 6.0-Beta releases with
these chips.


Well, both work wonderfully here YMMV of course..

No, seriously I need *much* more accurate info than that, I need the  
dmesg from the failing system, and I need an exact description of the  
problem, preferably with logs, dumbs etc etc.


- Søren



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[J. T. Farmer]

Scot Hetzel wrote:


On 8/10/05, Søren Schmidt <[EMAIL PROTECTED]> wrote:
 


Since I came in late in this, I need to know what kind of controller

we are talking about, and if the problem is still present in 6.0.
I plan to backport ATA from 6.0 to 5-stable when it has settled, so
6.0 is the one and only (pre)release to test with and get back to me
with the result.


They have been talking about SII and Intel ICH6 chips.  And a few have
stated that they are having problems with the 6.0-Beta releases with
these chips.



What, I'm chopped liver? :^>  I'm getting these errors with a standard, 
_very_
not "state of the art", Via KT266A/8235 chipset.  PATA WDC 800 drive. 
All very standard stuff for a desktop.  Was running WinXP without a
problem for quite some time.  Generic kernel.  In fact when I tried to 
install 5.4
(and 5.4-SNAP from 5 July & 9 July), it errored out as soon as the 
install kernel
tried to write to the disk.  FS's do not work when you can't  write the 
superblocks

out...  Oh yeah, writing the disklabel also generated the same error.

So it's not just the SATA raid type chipsets.  It's plain vanilla ATA
controllers, also.

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
   Consulting, Design, & Development of Networks & Software

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Scot Hetzel]

On 8/10/05, Søren Schmidt <[EMAIL PROTECTED]> wrote:
> 
> On 10/08/2005, at 17:44, Scot Hetzel wrote:
> 
> > On 8/10/05, Karl Denninger <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, Aug 10, 2005 at 09:51:03AM -0400, Mike Tancsa wrote:
> >>
> >>> At 09:31 AM 10/08/2005, Karl Denninger wrote:
> >>>
> >>>
>  Also, I've yet to see a developer commit on the list that they
>  WILL fix it
>  if
>  such a controller board is forthcoming (and will return the
>  board when
>  they're
>  done) - I've got two of these cards here (choose between Adaptec
>  and
>  Bustek)
>  and would be happy to UPS one to someone IF I had a firm
>  commitment that
>  6.x
>  would NOT go out without this being addressed and that the board
>  would be
>  returned to me when work was complete.
> 
> >>>
> >>> You demand to see support for this chipset fixed, yet, you cant
> >>> pony up a
> >>> measly hundred bucks to donate the card to the developer who is
> >>> not being
> >>> paid to develop anything.
> >>>
> >>> ---Mike
> >>>
> >>
> >> I have "demanded" nothing Mike.
> >>
> >>
> > I agree Mike's wording was a little strong, but we have seen you
> > request strongly that some one fix this problem.
> >
> > Have you contacted Søren, to see if he has the troublesome hardware?
> >
> > Also contact Søren directly with your offer to supply a troublesome
> > board, and/or access to a system that displays the problem.  More than
> > likely he would agree to return the board once he has a proper fix for
> > the problem.
> 
> Since I came in late in this, I need to know what kind of controller
> we are talking about, and if the problem is still present in 6.0.
> I plan to backport ATA from 6.0 to 5-stable when it has settled, so
> 6.0 is the one and only (pre)release to test with and get back to me
> with the result.
> 

They have been talking about SII and Intel ICH6 chips.  And a few have
stated that they are having problems with the 6.0-Beta releases with
these chips.

-- 
DISCLAIMER:
No electrons were mamed while sending this message. Only slightly bruised.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

O. Hartmann wrote:


Mike Jakubik wrote:


On Wed, August 10, 2005 6:37 am, Dmitry Mityugov said:



There are Maxtor MaXLine II and III, and perhaps several other models,
that are supposed to work 24/7.




Right, i have a dead 250GB Maxline Plus II drive on my desk, only after
about 1.5 years. At least its still on warranty.



On the other hand: In the department for physics of the athmosphere, 
where I built six years ago a server for meteorological data, a RAID-5 
with 4 older IBM U160 SCSI discs still works - 24/7. Never had a problem!


I still own old 1-2 GB old SCSI disks and these are still working, I 
also had an old 500mb SCSI disk that was in an old Mac that also worked 
but I trashed it since it was that old and no longer of use...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[O. Hartmann]

Mike Jakubik wrote:

On Wed, August 10, 2005 6:37 am, Dmitry Mityugov said:



There are Maxtor MaXLine II and III, and perhaps several other models,
that are supposed to work 24/7.



Right, i have a dead 250GB Maxline Plus II drive on my desk, only after
about 1.5 years. At least its still on warranty.


On the other hand: In the department for physics of the athmosphere, 
where I built six years ago a server for meteorological data, a RAID-5 
with 4 older IBM U160 SCSI discs still works - 24/7. Never had a problem!

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

It's sad isn't it, Mike..I don't know what the hd manufacturers are 
doing to the HD drives..ok, the systems get faster, there's usually bad 
cooling unless you build your own system...but even if you get enough 
cooling that won't change a thing some hds are prone to die an early 
death such as the Maxtors..I used to love Maxtor and hated Seagate now 
it's the other way around but my #1 HD still is Western Digital...I have 
an old Maxtor drive here 6 gb that's still running perfectly, just like 
3 40gb Seagate Barracuda and Western Digital Caviar...I had a 120gb 
Hitachi that died after 1 yr of use...



Mike Jakubik wrote:


On Wed, August 10, 2005 6:37 am, Dmitry Mityugov said:

 


There are Maxtor MaXLine II and III, and perhaps several other models,
that are supposed to work 24/7.
   



Right, i have a dead 250GB Maxline Plus II drive on my desk, only after
about 1.5 years. At least its still on warranty.



 



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mike Jakubik]

On Wed, August 10, 2005 6:37 am, Dmitry Mityugov said:

> There are Maxtor MaXLine II and III, and perhaps several other models,
> that are supposed to work 24/7.

Right, i have a dead 250GB Maxline Plus II drive on my desk, only after
about 1.5 years. At least its still on warranty.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Søren Schmidt]

On 10/08/2005, at 17:44, Scot Hetzel wrote:


On 8/10/05, Karl Denninger <[EMAIL PROTECTED]> wrote:


On Wed, Aug 10, 2005 at 09:51:03AM -0400, Mike Tancsa wrote:


At 09:31 AM 10/08/2005, Karl Denninger wrote:


Also, I've yet to see a developer commit on the list that they  
WILL fix it

if
such a controller board is forthcoming (and will return the  
board when

they're
done) - I've got two of these cards here (choose between Adaptec  
and

Bustek)
and would be happy to UPS one to someone IF I had a firm  
commitment that

6.x
would NOT go out without this being addressed and that the board  
would be

returned to me when work was complete.



You demand to see support for this chipset fixed, yet, you cant  
pony up a
measly hundred bucks to donate the card to the developer who is  
not being

paid to develop anything.

---Mike



I have "demanded" nothing Mike.



I agree Mike's wording was a little strong, but we have seen you
request strongly that some one fix this problem.

Have you contacted Søren, to see if he has the troublesome hardware?

Also contact Søren directly with your offer to supply a troublesome
board, and/or access to a system that displays the problem.  More than
likely he would agree to return the board once he has a proper fix for
the problem.


Since I came in late in this, I need to know what kind of controller  
we are talking about, and if the problem is still present in 6.0.
I plan to backport ATA from 6.0 to 5-stable when it has settled, so  
6.0 is the one and only (pre)release to test with and get back to me  
with the result.


- Søren



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

Matthias Buelow wrote:


J. T. Farmer wrote:

 


Those of us who want to switch desktops and light duty servers
to FreeBSD will give up and move to Linux.  OR back to WinXP.
   



I myself am just waiting for NetBSD 3.0, which will hopefully support
the ICH6 SATA stuff I have here (2.0.2 doesn't support it) and then
I'll move some machines to it. I don't want to start a flamewar but
they seem to have a somewhat higher quality output as of lately..
that is, when they advertise something as "working", one can be pretty
confident that it actually does work.

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

 

NetBSD 3.0 is also supposed to work somewhat with the Intel HD Audio 
controller..at least it gets detected...I'm in the same boat..I love 
FreeBSD and I'd prefer to keep it, I want to buy a Fujitsu MO Drive and 
I heard it only works in FreeBSD..but if I can't get good audio support 
in the near future and a stable S/ATA controller I'll consider switching...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Matthias Buelow]

J. T. Farmer wrote:

>Those of us who want to switch desktops and light duty servers
>to FreeBSD will give up and move to Linux.  OR back to WinXP.

I myself am just waiting for NetBSD 3.0, which will hopefully support
the ICH6 SATA stuff I have here (2.0.2 doesn't support it) and then
I'll move some machines to it. I don't want to start a flamewar but
they seem to have a somewhat higher quality output as of lately..
that is, when they advertise something as "working", one can be pretty
confident that it actually does work.

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

Yes, I agree. I don't think anyone wants to blame the entire FreeBSD 
community for not being up to date on everything but if it is a known 
problem we should know. I know that the developers work for free and I, 
for one, appreciate all the work they've done. I know I would help if I 
could..but my programming knowledges are too poor..if there is a problem 
though, like the one with the SII and ICH chipsets maybe a FreeBSD 
developer should send an email asking for our help and I bet there would 
be plenty of people to test and script and like...


J. T. Farmer wrote:


Mike Tancsa wrote:


At 09:31 AM 10/08/2005, Karl Denninger wrote:

Also, I've yet to see a developer commit on the list that they WILL 
fix it if
such a controller board is forthcoming (and will return the board 
when they're
done) - I've got two of these cards here (choose between Adaptec and 
Bustek)
and would be happy to UPS one to someone IF I had a firm commitment 
that 6.x
would NOT go out without this being addressed and that the board 
would be

returned to me when work was complete.




You demand to see support for this chipset fixed, yet, you cant pony 
up a measly hundred bucks to donate the card to the developer who is 
not being paid to develop anything.



Why?  It was claimed that the code was developed to support this chipset.
Was that done in the dark, without hardware?  And why must it be a
hardware donation?  Karl has offered access to the hardware.  Asking to
get it back afterwards is a reasonable thing.  If the developer wants to
keep the card as part of a verification hardware suite, then they should
open their mouth and say so.  I suspect that Karl, and many other people,
would be more forthcoming with such donations if 1.) They were asked
in a reasonable manner, 2.) The hardware in question have not already
been listed as working under 5.x, and 3.) They had some assurance that
the problem would be fixed.

And finally, the problem has been reported in 5.4 and apparently in
6.0-Beta _not _only_ for the SII chipset & SATA, but also for some
of the Intel ICH chipsets.  And others, such as myself, are seeing the
same problem with plain PATA drives and controllers that are listed
as being supported by the ata driver.

In my case, a vanilla, OLD but working Via KT266A/8235 chipset MB
_will_not_boot an install kernel unless booted in safe mode.  I don't 
have

the resources to just give away hardware or buy replacements, just to
run FreeBSD as my desktop/development machine.  It runs WinXP and
Linux just fine.  However I _want_ to run FreeBSD.  Part of the that
machine's rational is so that I can contribute in my areas of interest
(sound & video editing/production tools, documentation).  I chose to
install 5.4, the PRODUCTION version, because I did not want any
surprises, did not want to be hacking a basic system functions.

At what point do I give up and just reformat the FreeBSD partition
and either release it to use with WinXP or install Linux?  Now mind
you, I've used FreeBSD, as a production platform, since 2.0.X.  I've
survived a fair number of "bumps."   But I'm at the point that I really
want the things that are claimed to work to just work.  I continue  to
run my servers under 4.X because or all the upheaval in 5.0/5.1/etc.
But 5.4 was supposed to have those teething problems behind it.
And the so far the only answer I get is try the ATA MkIII patches for
a partial fix, move to 6.0 for a real solution.
So when will 6.X really be Stable?  Yes, I understand that the RE is
working on getting 6.0 out the door.  But what users are trying to tell
you is that we need an answer for these problems.  If the production
release is broken for certain hardware, say so.  If FreeBSD developers
would rather work on big hairy server oriented problems, then say so.
If we have to run beta code to get old hardware to work, then say so.
Then we can make a choice as to what we run or try to use.  If
no one is interested in making FreeBSD work on the vanilla hardware
that is out there, then say so.  If FreeBSD is only going to run on
expensive hand picked hardware (the Sun approach) then say so.
Those of us who want to switch desktops and light duty servers
to FreeBSD will give up and move to Linux.  OR back to WinXP.

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
   Consulting, Design, & Development of Networks & Software

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Scot Hetzel]

On 8/10/05, Karl Denninger <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005 at 09:51:03AM -0400, Mike Tancsa wrote:
> > At 09:31 AM 10/08/2005, Karl Denninger wrote:
> >
> > >Also, I've yet to see a developer commit on the list that they WILL fix it
> > >if
> > >such a controller board is forthcoming (and will return the board when
> > >they're
> > >done) - I've got two of these cards here (choose between Adaptec and
> > >Bustek)
> > >and would be happy to UPS one to someone IF I had a firm commitment that
> > >6.x
> > >would NOT go out without this being addressed and that the board would be
> > >returned to me when work was complete.
> >
> > You demand to see support for this chipset fixed, yet, you cant pony up a
> > measly hundred bucks to donate the card to the developer who is not being
> > paid to develop anything.
> >
> > ---Mike
> 
> I have "demanded" nothing Mike.
> 
I agree Mike's wording was a little strong, but we have seen you
request strongly that some one fix this problem.

Have you contacted Søren, to see if he has the troublesome hardware?

Also contact Søren directly with your offer to supply a troublesome
board, and/or access to a system that displays the problem.  More than
likely he would agree to return the board once he has a proper fix for
the problem.

Currently, he is the only one I am aware of who is actively working on
the ATA code (ata-ng, ata-mkIII).

Scot
-- 
DISCLAIMER:
No electrons were mamed while sending this message. Only slightly bruised.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[J. T. Farmer]

Mike Tancsa wrote:


At 09:31 AM 10/08/2005, Karl Denninger wrote:

Also, I've yet to see a developer commit on the list that they WILL 
fix it if
such a controller board is forthcoming (and will return the board 
when they're
done) - I've got two of these cards here (choose between Adaptec and 
Bustek)
and would be happy to UPS one to someone IF I had a firm commitment 
that 6.x
would NOT go out without this being addressed and that the board 
would be

returned to me when work was complete.



You demand to see support for this chipset fixed, yet, you cant pony 
up a measly hundred bucks to donate the card to the developer who is 
not being paid to develop anything.


Why?  It was claimed that the code was developed to support this chipset.
Was that done in the dark, without hardware?  And why must it be a
hardware donation?  Karl has offered access to the hardware.  Asking to
get it back afterwards is a reasonable thing.  If the developer wants to
keep the card as part of a verification hardware suite, then they should
open their mouth and say so.  I suspect that Karl, and many other people,
would be more forthcoming with such donations if 1.) They were asked
in a reasonable manner, 2.) The hardware in question have not already
been listed as working under 5.x, and 3.) They had some assurance that
the problem would be fixed.

And finally, the problem has been reported in 5.4 and apparently in
6.0-Beta _not _only_ for the SII chipset & SATA, but also for some
of the Intel ICH chipsets.  And others, such as myself, are seeing the
same problem with plain PATA drives and controllers that are listed
as being supported by the ata driver.

In my case, a vanilla, OLD but working Via KT266A/8235 chipset MB
_will_not_boot an install kernel unless booted in safe mode.  I don't have
the resources to just give away hardware or buy replacements, just to
run FreeBSD as my desktop/development machine.  It runs WinXP and
Linux just fine.  However I _want_ to run FreeBSD.  Part of the that
machine's rational is so that I can contribute in my areas of interest
(sound & video editing/production tools, documentation).  I chose to
install 5.4, the PRODUCTION version, because I did not want any
surprises, did not want to be hacking a basic system functions.

At what point do I give up and just reformat the FreeBSD partition
and either release it to use with WinXP or install Linux?  Now mind
you, I've used FreeBSD, as a production platform, since 2.0.X.  I've
survived a fair number of "bumps."   But I'm at the point that I really
want the things that are claimed to work to just work.  I continue  to
run my servers under 4.X because or all the upheaval in 5.0/5.1/etc.
But 5.4 was supposed to have those teething problems behind it.
And the so far the only answer I get is try the ATA MkIII patches for
a partial fix, move to 6.0 for a real solution. 


So when will 6.X really be Stable?  Yes, I understand that the RE is
working on getting 6.0 out the door.  But what users are trying to tell
you is that we need an answer for these problems.  If the production
release is broken for certain hardware, say so.  If FreeBSD developers
would rather work on big hairy server oriented problems, then say so.
If we have to run beta code to get old hardware to work, then say so.
Then we can make a choice as to what we run or try to use.  If
no one is interested in making FreeBSD work on the vanilla hardware
that is out there, then say so.  If FreeBSD is only going to run on
expensive hand picked hardware (the Sun approach) then say so.
Those of us who want to switch desktops and light duty servers
to FreeBSD will give up and move to Linux.  OR back to WinXP.

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
   Consulting, Design, & Development of Networks & Software

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

On Wed, Aug 10, 2005 at 09:51:03AM -0400, Mike Tancsa wrote:
> At 09:31 AM 10/08/2005, Karl Denninger wrote:
> 
> >Also, I've yet to see a developer commit on the list that they WILL fix it 
> >if
> >such a controller board is forthcoming (and will return the board when 
> >they're
> >done) - I've got two of these cards here (choose between Adaptec and 
> >Bustek)
> >and would be happy to UPS one to someone IF I had a firm commitment that 
> >6.x
> >would NOT go out without this being addressed and that the board would be
> >returned to me when work was complete.
> 
> You demand to see support for this chipset fixed, yet, you cant pony up a 
> measly hundred bucks to donate the card to the developer who is not being 
> paid to develop anything.
> 
> ---Mike 

I have "demanded" nothing Mike.

I have stated VERY clearly, however, that I've been one of FreeBSD's loudest
evangelists, to the point that I won't support the code I both give away and
sell on ANYTHING OTHER THAN FreeBSD - at least so far.

That evangalism dates back to the mid 90s when I ran my own ISP, and refused
multiple "requests" (sweetened with various offers) to run my back office on
all sorts of things. One of those "requests" came from Microsoft (to run on 
NT, specifcally for our back office functions.)  I assure you that their 
offer, made in confidence in my conference room, was quite "sweet" - and 
was flatly turned down.

I do not believe that it is unreasonable in any way, shape or form to expect
that hardware that is in mass circulation (that is, NOT deprecated stuff
that nobody sells or makes anymore) will NOT be broken from one release to
the next when it was working just fine previously.

I  expect FreeBSD to magically support every piece of crap that
comes down the pipe, and am well-aware that there's a lot of that sort of
thing out there.

But this isn't the case in this instance.  This is hardware that worked 
perfectly well on 4.x (and in fact still does) but broke immediately and 
severely with the newer ATA code.  The FreeBSD team KNOWS THIS, in that I 
filed a PR on it in February, yet there is nothing in the Errata or hardware 
notes (as of AUGUST!) warning people that they risk severe data corruption 
if they attempt to use these controllers on releases 5.4 and beyond.

In addition, the "fix" propounded upon for this problem (buy a 3ware card),
which I finally did after watching my PR sit unattended for six months,
led to a SECOND surprise - that the much-touted reason for the ATA-ng code
in the first place, that is, a more rich feature environment (specifically 
hot plug support) IS NOT IN THE FIX PROPOUNDED UPON!

That is, I get to go BACK to the 4.x feature set in pursuit of the fix!

Nonetheless I'm willing to SEND A BOARD to the developer IF I get in
return a commitment (in public, right here) from the development/release 
teams that 6.x WILL NOT GO OUT THE DOOR UNTIL THIS PROBLEM IS ADDRESSED.

I am requesting the board back after the fix is purportedly in the source
tree , and drop the warnings from my product
documentation.  UPSing the board back to me (or sending it first class US
mail) will cost all of a couple of bucks.

What I get in return for this offer (I own the board, I will pay the UPS 
charge anywhere in the US to send it out) is a personal attack that I'm
too "miserly" to not pony up MONEY - when I've already offered to send what 
the money would BUY.

Is it REALLY true that the developers DO NOT HAVE a card that has this
problem?  

If so I have TWO which exhibit the problem (pick your brand, Adaptec or
Bustek) and have offered to send ONE of the two to a developer.

So why do they want MONEY, when I have and am offering better - a KNOWN 
TROUBLESOME BOARD?  What is the money going to BUY Mike?  A board - or 
beer?  If a board, I have one.  If beer, be honest enough to say so.

I ALSO (about two weeks ago) offered to give any developer who wanted to
work on this a login on my Sandbox machine, configured with the bad controller
and a disk exhibiting the problem in it, plus a boot disk on a "SAFE"
controller in the same box.  Gmirror appears to insure (from my testing)
that if/when the disk disconnects and blows chunks that operating system
integrity is not compromised.

Therefore, said developer(s) could work SAFELY on this problem (without risk
to their development machines - it'd be at MY risk to MY environment) until 
they are satisfied that its fixed.  At that point I will once again run my 
validation tests on the box and see if it remains stable, as a further 
verification that it truly is fixed.  If it passes THAT test, then of 
course the final verification would come from the community at large.

That machine has 6.0-BETA on it and they are free to have at it at will 
via SSH.  It also has a full CVS set on it so the FULL development
environment is available to whoever wishes to work on it and other than
sharing a network connection with production machines is entirely isolated -
so t

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mike Tancsa]

At 09:31 AM 10/08/2005, Karl Denninger wrote:


Also, I've yet to see a developer commit on the list that they WILL fix it if
such a controller board is forthcoming (and will return the board when 
they're

done) - I've got two of these cards here (choose between Adaptec and Bustek)
and would be happy to UPS one to someone IF I had a firm commitment that 6.x
would NOT go out without this being addressed and that the board would be
returned to me when work was complete.


You demand to see support for this chipset fixed, yet, you cant pony up a 
measly hundred bucks to donate the card to the developer who is not being 
paid to develop anything.


---Mike 


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

On Wed, Aug 10, 2005 at 08:15:50AM -0400, Mike Tancsa wrote:
> At 10:46 PM 09/08/2005, Matthias Buelow wrote:
> >Karl Denninger wrote:
> >
> >>SII chipsets were ok in 4.x, but the newer ATA code broke badly with them.
> >>I've had a PR open on this since February, and many others have reported
> >>similar issues.  The problems still exist in the 6.x-BETA releases I've
> >>checked out, and are in some cases MORE severe (for me anyway) than they 
> >are
> >>in 5.4.
> >
> >Well, it doesn't affect just the SII chips.. I see the same on an
> >Intel ICH6 chipset but never after the kernel has mounted the root
> >fs. Sometimes it takes several attempts until it manages to do so,
> >though. The machine works w/o any such problems on other OSes. I've
> 
> I have ICH6 boxes and they run just fine without issue.  Have you checked 
> to see if it actually has bad sectors or is a problem with your tray (if 
> you use one)
> 
> [verify1]% dmesg | grep -i ich
> uhci0:  port 
> 0xe000-0xe01f at device 29.0 on pci0
> usb0:  on uhci0
> uhci1:  port 
> 0xe100-0xe11f at device 29.1 on pci0
> usb1:  on uhci1
> uhci2:  port 
> 0xe200-0xe21f at device 29.2 on pci0
> usb2:  on uhci2
> uhci3:  port 
> 0xe300-0xe31f at device 29.3 on pci0
> usb3:  on uhci3
> fxp0:  port 0xd000-0xd03f mem 0xd000-0xdfff 
> irq 10 at device 8.0 on pci1
> atapci0:  port 
> 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.2 on pci0
> [verify1]%

I have an ICH5 on my motherboard and it works fine - it is under heavy use
and has had no trouble.

atapci1:  port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20
-0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 irq 18 at device 31.2 on pci0

There's two potential issues here - if it is failing during the boot process
that's a completely different set of code - and thus potential problem -
than failing while running.

I've not had booting problems with the ICH5, and no failures while running.

On the other hand the SII chipset boards I have (two of them) can be
RELIABLY forced to fail within minutes.  If there are no drives in the
mirror set on something else, the data on the disk(s) is toast - if so 
they detach and the non-SII-attached disks end up carrying the data.

This is across two different manufacturers of drives (Hitachi and Maxtor)
and FOUR separate disks, all four of which smartmontools bless as operating
properly and all of which ran just fine under 4.x.

Oh, and all of which work just fine on a 3ware 8502 card.

I've read the reports that basically boil down to "the SII chipset sucks,
don't use it" BUT (1) it works under 4.x, (2) it works under other operating
systems and (3) the FreeBSD folks who are saying it doesn't work don't have 
the courage of their statements to make them in the official release 
documents (e.g. the release notes, hardware compatability guide or erratta.)
So while the chipset may or may not be "less desireable", what is clear is 
that the problems with it are not insurmountable - they've just not been 
taken care of in the newer ATA code.

Arguments that this is about resources (e.g. the developers don't have a
card and need anything from a board to a complete system to have any chance 
of fixing it) ring pretty hollow to me.  This is an EXTREMELY popular chipset,
is on both the Adaptec and Bustek cards commonly sold with machines and at
retail, and cards with that chipset can be had for as little as $30 (and up,
of course.)  In addition I've yet to find a SATA drive that WON'T fail with 
this board - or a motherboard that is stable with it on FreeBSD 5.4 or 6.x - 
it is definitely NOT linked to the drive and I have no confidence its linked 
to the motherboard chipset in any way. Further, smartmontools says the disks 
that do fail aren't defective, and it worked just fine under 4.x.  

Also, I've yet to see a developer commit on the list that they WILL fix it if 
such a controller board is forthcoming (and will return the board when they're 
done) - I've got two of these cards here (choose between Adaptec and Bustek) 
and would be happy to UPS one to someone IF I had a firm commitment that 6.x 
would NOT go out without this being addressed and that the board would be 
returned to me when work was complete.

Finally, while the 3ware card works fine, it doesn't support hot plug.  The 
SII chipset claims to, and so does the ATA code, but the 3ware card runs on 
a different driver - which doesn't (either claim to or actually accomplish 
it.)

So while using a 3ware card solves the "blows chunks and dies" problem, you
are back to the lack of functionality that was present in 4.x - no hot drive
swap support.  (This is mitigated somewhat by the 3ware management tools,
which do allow reconnection and work - but its a manual operation.)  This
entirely voids the argument for ATAng being a "step forward" - support of 
hot plug and other functionality improvements - in the first place, since
you can't actually USE that capability if you are forced to a 3ware board!

Again, I think the ATA-

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mike Tancsa]

At 10:46 PM 09/08/2005, Matthias Buelow wrote:

Karl Denninger wrote:

>SII chipsets were ok in 4.x, but the newer ATA code broke badly with them.
>I've had a PR open on this since February, and many others have reported
>similar issues.  The problems still exist in the 6.x-BETA releases I've
>checked out, and are in some cases MORE severe (for me anyway) than they are
>in 5.4.

Well, it doesn't affect just the SII chips.. I see the same on an
Intel ICH6 chipset but never after the kernel has mounted the root
fs. Sometimes it takes several attempts until it manages to do so,
though. The machine works w/o any such problems on other OSes. I've


I have ICH6 boxes and they run just fine without issue.  Have you checked 
to see if it actually has bad sectors or is a problem with your tray (if 
you use one)


[verify1]% dmesg | grep -i ich
uhci0:  port 
0xe000-0xe01f at device 29.0 on pci0

usb0:  on uhci0
uhci1:  port 
0xe100-0xe11f at device 29.1 on pci0

usb1:  on uhci1
uhci2:  port 
0xe200-0xe21f at device 29.2 on pci0

usb2:  on uhci2
uhci3:  port 
0xe300-0xe31f at device 29.3 on pci0

usb3:  on uhci3
fxp0:  port 0xd000-0xd03f mem 0xd000-0xdfff 
irq 10 at device 8.0 on pci1
atapci0:  port 
0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.2 on pci0

[verify1]%

Master:  ad0  Serial ATA v1.0

---Mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

On Wed, Aug 10, 2005 at 04:46:18AM +0200, Matthias Buelow wrote:
> Karl Denninger wrote:
> 
> >SII chipsets were ok in 4.x, but the newer ATA code broke badly with them.
> >I've had a PR open on this since February, and many others have reported
> >similar issues.  The problems still exist in the 6.x-BETA releases I've
> >checked out, and are in some cases MORE severe (for me anyway) than they are
> >in 5.4.
> 
> Well, it doesn't affect just the SII chips.. I see the same on an
> Intel ICH6 chipset but never after the kernel has mounted the root
> fs. Sometimes it takes several attempts until it manages to do so,
> though. The machine works w/o any such problems on other OSes. I've
> deferred update of another machine (which is a hosted box and cannot
> afford random hangs at boot) because of general flakeyness of the
> ATA/SATA code in 5.4 (significantly worse than with 5.3, imho). If
> these issues don't go away completely soon (in 6.x) I'll have to
> look for some alternative system which doesn't make such a fuss
> with mainstream hardware.
> 
> mkb.

Yep.

4.x was perfectly stable on the hardware in question here.  

The "feature set" of the newer ATA code may be better, but the stability is
significantly worse.  IMHO "requiring" 3ware cards for drives to work right
is such a huge step backwards that for the lower-end server user, and
virtually all desktop users, it will basically kill FreeBSD off.

--
-- 
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org   Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.comMusings Of A Sentient Mind


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request)LBA=11441599

[Mathijs Brands]

On 8/10/05, Unix <[EMAIL PROTECTED]> wrote:

>I thought the WD Raptors were supposed to replace the SCSI for that
>purpose. I used to run one in a Powermac and performance wise it behaved
>very well, unfortunately I haven't had the chance to test the 30 or 70
>GB WD Raptor SATA in FreeBSD..S/ATA drives should never be used for 24/7
>or server use anyway
>
I have a FreeBSD 6.0-BETA2 machine that's using a WD Raptor 36 GB using
the on-board controller (VIA 8237) of the Asus A7V880 motherboard and it
works perfectly. The most taxing thing it runs is the occasional
buildworld or (re)build of KDE3 though...

Cheers,

Mathijs
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

Dmitry Mityugov wrote:


On 8/10/05, Unix <[EMAIL PROTECTED]> wrote:
 


Dmitry Mityugov wrote:

   


On 8/10/05, Unix <[EMAIL PROTECTED]> wrote:
...


 


I thought the WD Raptors were supposed to replace the SCSI for that
purpose. I used to run one in a Powermac and performance wise it behaved
very well, unfortunately I haven't had the chance to test the 30 or 70
GB WD Raptor SATA in FreeBSD..S/ATA drives should never be used for 24/7
or server use anyway


   


...

There are Maxtor MaXLine II and III, and perhaps several other models,
that are supposed to work 24/7.



 


Yes, but I don't like Maxtor drives, the ones I've used always failed
after a year or less than a year...
   



Western Digital produces similar drives as well - from
http://store.westerndigital.com/product.asp?sku=2700729: ..."24x7 100%
duty cycle–the highest available reliability rating on high capacity
drives"...

 


thanks, I need to get some new drives anyway...and WD was on my list...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Dmitry Mityugov]

On 8/10/05, Unix <[EMAIL PROTECTED]> wrote:
> Dmitry Mityugov wrote:
> 
> >On 8/10/05, Unix <[EMAIL PROTECTED]> wrote:
> >...
> >
> >
> >>I thought the WD Raptors were supposed to replace the SCSI for that
> >>purpose. I used to run one in a Powermac and performance wise it behaved
> >>very well, unfortunately I haven't had the chance to test the 30 or 70
> >>GB WD Raptor SATA in FreeBSD..S/ATA drives should never be used for 24/7
> >>or server use anyway
> >>
> >>
> >...
> >
> >There are Maxtor MaXLine II and III, and perhaps several other models,
> >that are supposed to work 24/7.
> >
> >
> >
> Yes, but I don't like Maxtor drives, the ones I've used always failed
> after a year or less than a year...

Western Digital produces similar drives as well - from
http://store.westerndigital.com/product.asp?sku=2700729: ..."24x7 100%
duty cycle–the highest available reliability rating on high capacity
drives"...

-- 
Dmitry Mityugov, St. Petersburg, Russia
I ignore all messages with confidentiality statements

"We live less by imagination than despite it" - Rockwell Kent, "N by E"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

Dmitry Mityugov wrote:


On 8/10/05, Unix <[EMAIL PROTECTED]> wrote:
...
 


I thought the WD Raptors were supposed to replace the SCSI for that
purpose. I used to run one in a Powermac and performance wise it behaved
very well, unfortunately I haven't had the chance to test the 30 or 70
GB WD Raptor SATA in FreeBSD..S/ATA drives should never be used for 24/7
or server use anyway
   


...

There are Maxtor MaXLine II and III, and perhaps several other models,
that are supposed to work 24/7.

 

Yes, but I don't like Maxtor drives, the ones I've used always failed 
after a year or less than a year...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Dmitry Mityugov]

On 8/10/05, Unix <[EMAIL PROTECTED]> wrote:
...
> I thought the WD Raptors were supposed to replace the SCSI for that
> purpose. I used to run one in a Powermac and performance wise it behaved
> very well, unfortunately I haven't had the chance to test the 30 or 70
> GB WD Raptor SATA in FreeBSD..S/ATA drives should never be used for 24/7
> or server use anyway
...

There are Maxtor MaXLine II and III, and perhaps several other models,
that are supposed to work 24/7.

-- 
Dmitry Mityugov, St. Petersburg, Russia
I ignore all messages with confidentiality statements

"We live less by imagination than despite it" - Rockwell Kent, "N by E"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Andrey V. Elsukov]

O. Hartmann wrote:

Sometimes I get this error:
ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
while the machine still keeps working.


Check your disks with MHDD (http://mhdd.com/).

--
WBR, Andrey V. Elsukov

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

Joel Rees wrote:



On 平成 17/08/10, at 7:36, O. Hartmann wrote:


[...] When is SCSI back for desktops?



I vote for that.

In my opinion, ATA is primarily for home media systems, if that.

Joel Rees   <[EMAIL PROTECTED]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
**  **




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

I thought the WD Raptors were supposed to replace the SCSI for that 
purpose. I used to run one in a Powermac and performance wise it behaved 
very well, unfortunately I haven't had the chance to test the 30 or 70 
GB WD Raptor SATA in FreeBSD..S/ATA drives should never be used for 24/7 
or server use anyway, they die after a while, in my case, two 80gb 
seagate drives after 1.5 yrs with proper cooling...thing is that SCSI 
drives are not affordable to the regular home server user...if they 
were, I bet more people would use them so that's why the current 
alternatives are ATA and SATA and SATA Raptors.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Unix]

Matthias Buelow wrote:


Karl Denninger wrote:

 


SII chipsets were ok in 4.x, but the newer ATA code broke badly with them.
I've had a PR open on this since February, and many others have reported
similar issues.  The problems still exist in the 6.x-BETA releases I've
checked out, and are in some cases MORE severe (for me anyway) than they are
in 5.4.
   



Well, it doesn't affect just the SII chips.. I see the same on an
Intel ICH6 chipset but never after the kernel has mounted the root
fs. Sometimes it takes several attempts until it manages to do so,
though. The machine works w/o any such problems on other OSes. I've
deferred update of another machine (which is a hosted box and cannot
afford random hangs at boot) because of general flakeyness of the
ATA/SATA code in 5.4 (significantly worse than with 5.3, imho). If
these issues don't go away completely soon (in 6.x) I'll have to
look for some alternative system which doesn't make such a fuss
with mainstream hardware.

mkb.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

 

i knew about the problems with the sii chipset, had no idea it was just 
as bad with the ich6 chipset, I  have a Seagate 160gb SATA drive on an 
Intel SATA controller so far no problems though in 5.4-stable, my system 
did not like 6 at all, 7 was fine again..

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Joel Rees]

On 平成 17/08/10, at 7:36, O. Hartmann wrote:


[...] When is SCSI back for desktops?


I vote for that.

In my opinion, ATA is primarily for home media systems, if that.

Joel Rees   <[EMAIL PROTECTED]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
**  **




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[O. Hartmann]

Chuck Swiger wrote:


O. Hartmann wrote:
[ ... ]

One of  my SATA disks, the SAMSUNG SP2004C seems to show errors 
during operation (and also showd under 5.4-RELEASE-p3).

Sometimes I get this error:
ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
while the machine still keeps working.
Other days the box crashes completely.

Is this a operating system bug or is this message an evidence of 
defective hardware?


You can also run a "dd if=/dev/ad10 of=/dev/null bs=8192" to do a full 
read test under FreeBSD, and see how many CRC errors show up.



I did so and I ran into a crash of the system ...

I changed the cabling, did it again and until now nothing happend ... 
hope it was only a cabling issue. The first time I use ATA/SATA and now 
these experiences ... When is SCSI back for desktops?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Matthias Buelow]

Karl Denninger wrote:

>SII chipsets were ok in 4.x, but the newer ATA code broke badly with them.
>I've had a PR open on this since February, and many others have reported
>similar issues.  The problems still exist in the 6.x-BETA releases I've
>checked out, and are in some cases MORE severe (for me anyway) than they are
>in 5.4.

Well, it doesn't affect just the SII chips.. I see the same on an
Intel ICH6 chipset but never after the kernel has mounted the root
fs. Sometimes it takes several attempts until it manages to do so,
though. The machine works w/o any such problems on other OSes. I've
deferred update of another machine (which is a hosted box and cannot
afford random hangs at boot) because of general flakeyness of the
ATA/SATA code in 5.4 (significantly worse than with 5.3, imho). If
these issues don't go away completely soon (in 6.x) I'll have to
look for some alternative system which doesn't make such a fuss
with mainstream hardware.

mkb.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Karl Denninger]

Post your "dmesg" output from boot.

If the SATA controller has a SII chipset, you're in trouble.

Get that board out of there - or if its on the motherboard, get something
else in there and use it instead.

SII chipsets were ok in 4.x, but the newer ATA code broke badly with them.
I've had a PR open on this since February, and many others have reported
similar issues.  The problems still exist in the 6.x-BETA releases I've
checked out, and are in some cases MORE severe (for me anyway) than they are
in 5.4.

You CAN AND WILL lose data if you're not careful.  

Be careful!

A BIG disappointment to me is that FreeBSD has not CONSPICUOUSLY stated in
the hardware notes for 5.4 (and beyond) that these controllers DO NOT work 
reliably with 5.x and later, or undertaken to do whatever is needed to 
make them work as they did in 4.x (I had no problems with the same 
hardware under the 4.x releases)  As these controllers are widely 
available and very inexpensive, not to mention showing up in all manner
of boards from various vendors (including Adaptec, Bustek and on some
motherboards!) this is quite a disappointment.

I finally gave up kvetching on the list and bought a 3ware 8502 card.  
Same disks, same system, same load, no problems.

Smartmontools declared all my disks as perfectly healthy in my case, and has
for several others as well

YMMV.

--
-- 
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org   Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.comMusings Of A Sentient Mind

On Tue, Aug 09, 2005 at 10:04:14PM -0400, J. T. Farmer wrote:
> Chuck Swiger wrote:
> 
> >O. Hartmann wrote:
> >[ ... ]
> >
> >>One of  my SATA disks, the SAMSUNG SP2004C seems to show errors 
> >>during operation (and also showd under 5.4-RELEASE-p3).
> >>Sometimes I get this error:
> >>ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
> >>while the machine still keeps working.
> >>Other days the box crashes completely.
> >>
> >>Is this a operating system bug or is this message an evidence of 
> >>defective hardware?
> >
> >Back up any data you care about now.  Use the smartmontools port or 
> >hunt down a utility from Samsung which'll do a surface test (read 
> >only, nondestructive).
> >
> >You can also run a "dd if=/dev/ad10 of=/dev/null bs=8192" to do a full 
> >read test under FreeBSD, and see how many CRC errors show up.
> 
> 
> Actually, I would go with the "it's an operating system error."  That's 
> exactly
> the same error quite a few people (myself included) have been reporting 
> under
> 5.4 and 5-STABLE.  In my case, I just installed the smartmontools port and
> it's reporting that my drive is behaving perfectly.
> 
> This is 6.0-Beta?  I have a couple spare drives here (destined to be part of
> a RAID array on another machine).  Perhaps after I get rid of some of the
> current RL overloads, I will try it on this machine.
> 
> John
> 
> --
> John T. FarmerOwner & CTOGoldSword Systems
> [EMAIL PROTECTED] 865-691-6498   Knoxville TN
>Consulting, Design, & Development of Networks & Software
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> 
> %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[J. T. Farmer]

Chuck Swiger wrote:


O. Hartmann wrote:
[ ... ]

One of  my SATA disks, the SAMSUNG SP2004C seems to show errors 
during operation (and also showd under 5.4-RELEASE-p3).

Sometimes I get this error:
ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
while the machine still keeps working.
Other days the box crashes completely.

Is this a operating system bug or is this message an evidence of 
defective hardware?


Back up any data you care about now.  Use the smartmontools port or 
hunt down a utility from Samsung which'll do a surface test (read 
only, nondestructive).


You can also run a "dd if=/dev/ad10 of=/dev/null bs=8192" to do a full 
read test under FreeBSD, and see how many CRC errors show up.



Actually, I would go with the "it's an operating system error."  That's 
exactly
the same error quite a few people (myself included) have been reporting 
under

5.4 and 5-STABLE.  In my case, I just installed the smartmontools port and
it's reporting that my drive is behaving perfectly.

This is 6.0-Beta?  I have a couple spare drives here (destined to be part of
a RAID array on another machine).  Perhaps after I get rid of some of the
current RL overloads, I will try it on this machine.

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
   Consulting, Design, & Development of Networks & Software

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Chuck Swiger]

O. Hartmann wrote:
[ ... ]
One of  my SATA disks, the SAMSUNG SP2004C seems to show errors during 
operation (and also showd under 5.4-RELEASE-p3).

Sometimes I get this error:
ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
while the machine still keeps working.
Other days the box crashes completely.

Is this a operating system bug or is this message an evidence of 
defective hardware?


Back up any data you care about now.  Use the smartmontools port or hunt down a 
utility from Samsung which'll do a surface test (read only, nondestructive).


You can also run a "dd if=/dev/ad10 of=/dev/null bs=8192" to do a full read 
test under FreeBSD, and see how many CRC errors show up.


--
-Chuck

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[O. Hartmann]

Mike Tancsa wrote:

At 08:25 PM 08/08/2005, O. Hartmann wrote:


Hello.

My box is a FreeBSD 6.0-BETA2 driven ASUS A8N-SLI Deluxe based AMD64 
boxed (see dmesg).
One of  my SATA disks, the SAMSUNG SP2004C seems to show errors during 
operation (and also showd under 5.4-RELEASE-p3).

Sometimes I get this error:
ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
while the machine still keeps working.
Other days the box crashes completely.

Is this a operating system bug or is this message an evidence of 
defective hardware?



You can probably confirm a hardware issue with the smartmon tools.  
(/usr/ports/sysutils/smartmontools).


It was quite handy the other day for us to narrow down a problem between 
a drive tray and the actual drive.  We started to see


Aug  3 02:02:49 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=391423
Aug  3 02:03:00 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=2304319
Aug  3 02:03:10 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=2312927
Aug  3 02:03:17 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=2308639
Aug  3 02:03:26 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=2309855
Aug  3 02:03:37 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=2348359
Aug  4 12:12:37 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=1528639
Aug  4 12:13:04 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 
retries left) LBA=1530031
Aug  4 12:13:04 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (1 
retry left) LBA=1528639

Aug  4 12:13:04 verify1 kernel: ad0: FAILURE - READ_DMA timed out
Aug  4 12:13:04 verify1 kernel: spec_getpages:(ad0s1a) I/O read failure: 
(error=5) bp 0xd630b4fc vp 0xc2640d68


Yet when we read the actual error info off the drive via smartctl -a 
ad0, it was clean.  So it pointed to the drive tray which we swapped and 
all was well.  In other situations however, the smart info will often 
tell you if the drive is starting to fail.  Its not 100% reliable, but 
since we started using it, it generally gave us some sort of heads up as 
to whether or not a drive is in trouble.



---Mike


Dear Mike.
Thanks a lot for this info.
I will use this tool and try to report what I found out.

I also use trays for my drives (like I did with SCSI and SCA2 on our 
servers at the lab). Maybe this could be an issue.


Oliver
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599

[Mike Tancsa]

At 08:25 PM 08/08/2005, O. Hartmann wrote:

Hello.

My box is a FreeBSD 6.0-BETA2 driven ASUS A8N-SLI Deluxe based AMD64 boxed 
(see dmesg).
One of  my SATA disks, the SAMSUNG SP2004C seems to show errors during 
operation (and also showd under 5.4-RELEASE-p3).

Sometimes I get this error:
ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
while the machine still keeps working.
Other days the box crashes completely.

Is this a operating system bug or is this message an evidence of defective 
hardware?


You can probably confirm a hardware issue with the smartmon 
tools.  (/usr/ports/sysutils/smartmontools).


It was quite handy the other day for us to narrow down a problem between a 
drive tray and the actual drive.  We started to see


Aug  3 02:02:49 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=391423
Aug  3 02:03:00 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=2304319
Aug  3 02:03:10 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=2312927
Aug  3 02:03:17 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=2308639
Aug  3 02:03:26 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=2309855
Aug  3 02:03:37 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=2348359
Aug  4 12:12:37 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=1528639
Aug  4 12:13:04 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries 
left) LBA=1530031
Aug  4 12:13:04 verify1 kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry 
left) LBA=1528639

Aug  4 12:13:04 verify1 kernel: ad0: FAILURE - READ_DMA timed out
Aug  4 12:13:04 verify1 kernel: spec_getpages:(ad0s1a) I/O read failure: 
(error=5) bp 0xd630b4fc vp 0xc2640d68


Yet when we read the actual error info off the drive via smartctl -a ad0, 
it was clean.  So it pointed to the drive tray which we swapped and all was 
well.  In other situations however, the smart info will often tell you if 
the drive is starting to fail.  Its not 100% reliable, but since we started 
using it, it generally gave us some sort of heads up as to whether or not a 
drive is in trouble.



---Mike 


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"