Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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 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
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=51READY,DSC,ERROR error=84ICRC,ABORTED 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=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=110345151 ad9: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=110345183 Here are the current drives in the system: ad0: 194481MB Maxtor 6B200R0/BAH41BM0 [395136/16/63] at ata0-master UDMA133 ad8: 156334MB Maxtor 6Y160P0/YAR41BW0 [317632/16/63] at ata4-master UDMA133 ad9: 194481MB Maxtor 6B200P0/BAH41BM0 [395136/16/63] at ata4-slave UDMA133 ad10: 58643MB Maxtor 6Y060L0/YAR41BW0 [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
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: Nvidia AWRDACPI 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=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow+,3DNow real memory = 1610547200 (1535 MB) avail memory = 1543139328 (1471 MB) ioapic0 Version 1.1 irqs 0-23 on motherboard acpi0: Nvidia AWRDACPI 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: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf0-0xcf3,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: serial bus, SMBus at device 1.1 (no driver attached) ohci0: OHCI (generic) USB controller mem 0xfc002000-0xfc002fff irq 22 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller 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: OHCI (generic) USB controller mem 0xfc003000-0xfc003fff irq 21 at device 2.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: OHCI (generic) USB controller 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: serial bus, USB at device 2.2 (no driver attached) atapci0: nVidia nForce3 Pro UDMA133 controller 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: GENERIC ATA controller 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: ACPI PCI-PCI bridge at device 11.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 14.0 on pci0 pci2: ACPI PCI bus on pcib2 pci2: multimedia, audio at device 9.0 (no driver attached) pci2: input device 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.
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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 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 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 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]
[Fwd: Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599]
---BeginMessage--- 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 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]
RE: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request)LBA=11441599
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
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
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
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 ** http://www.ddcom.co.jp ** ___ 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 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
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
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 ** http://www.ddcom.co.jp ** ___ 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
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
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
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
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
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
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
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: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xe000-0xe01f at device 29.0 on pci0 usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xe100-0xe11f at device 29.1 on pci0 usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0xe200-0xe21f at device 29.2 on pci0 usb2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0xe300-0xe31f at device 29.3 on pci0 usb3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 fxp0: Intel 82562EZ (ICH6) port 0xd000-0xd03f mem 0xd000-0xdfff irq 10 at device 8.0 on pci1 atapci0: Intel ICH6 SATA150 controller port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.2 on pci0 [verify1]% Master: ad0 ST3120026AS/3.18 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
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: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xe000-0xe01f at device 29.0 on pci0 usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xe100-0xe11f at device 29.1 on pci0 usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0xe200-0xe21f at device 29.2 on pci0 usb2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0xe300-0xe31f at device 29.3 on pci0 usb3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 fxp0: Intel 82562EZ (ICH6) port 0xd000-0xd03f mem 0xd000-0xdfff irq 10 at device 8.0 on pci1 atapci0: Intel ICH6 SATA150 controller 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: Intel ICH5 SATA150 controller 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
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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
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 DO NOT 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 SO I CAN VERIFY IT, 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 there is no risk
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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 THIS SPECIFIC MACHINE 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
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
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=51READY,DSC,ERROR error=84ICRC,ABORTED 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=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=2 atapci0: Promise PDC20269 UDMA133 controller port 0x5020-0x5027,0x5014-0x50175 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 pci4: base peripheral, interrupt controller at device 30.0 (no driver attache) pcib6: ACPI PCI-PCI bridge at device 31.0 on pci4 pci6: ACPI PCI bus on pcib6 atapci1: Promise PDC20269 UDMA133 controller port 0x6020-0x6027,0x6014-0x60176 ata4: ATA channel 0 on atapci1 ata5: ATA channel 1 on atapci1 pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci7: ACPI PCI bus on pcib7 pci7: display, VGA at device 1.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci2: Intel ICH3 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x30 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 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
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
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=51READY,DSC,ERROR error=84ICRC,ABORTED 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=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=2 atapci0: Promise PDC20269 UDMA133 controller port 0x5020-0x5027,0x5014-0x50175 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 pci4: base peripheral, interrupt controller at device 30.0 (no driver attache) pcib6: ACPI PCI-PCI bridge at device 31.0 on pci4 pci6: ACPI PCI bus on pcib6 atapci1: Promise PDC20269 UDMA133 controller port 0x6020-0x6027,0x6014-0x60176 ata4: ATA channel 0 on atapci1 ata5: ATA channel 1 on atapci1 pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci7: ACPI PCI bus on pcib7 pci7: display, VGA at device 1.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci2: Intel ICH3 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x30 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 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
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 BOTH hardware AND TIME 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 AND DOCUMENT THAT THE SII CHIPSETS DON'T WORK RIGHT. 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.. (a thing I've studiously avoided
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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 BOTH hardware AND TIME 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 AND 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
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, AND IT DESERVES MENTION IN THE RELEASE NOTES OR HARDWARE GUIDE. 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 SUPPORTED 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 AND DOCUMENT THAT THE SII CHIPSETS DON'T WORK RIGHT. [ ...some 200 (!) lines of ranting at poor Soren deleted :-)... ] I'm ranting
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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
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
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
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
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
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
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
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]
ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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? By the way, DMA support is enabled: hw.ata.ata_dma: 1 hw.ata.atapi_dma: 1 Thanks in advance,\ Oliver Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA2 #23: Sun Aug 7 23:32:03 UTC 2005 [EMAIL PROTECTED]:/usr/backup/obj/usr/src/sys/THOR Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3500+ (2211.34-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x10ff0 Stepping = 0 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe2500800SYSCALL,NX,MMX+,b25,LM,3DNow+,3DNow real memory = 2147418112 (2047 MB) avail memory = 2064375808 (1968 MB) ACPI APIC Table: Nvidia AWRDACPI ioapic0 Version 1.1 irqs 0-23 on motherboard netsmb_dev: loaded acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR pci_link0: ACPI PCI Link LNK1 irq 10 on acpi0 pci_link1: ACPI PCI Link LNK2 on acpi0 pci_link2: ACPI PCI Link LNK3 irq 5 on acpi0 pci_link3: ACPI PCI Link LNK4 on acpi0 pci_link4: ACPI PCI Link LNK5 on acpi0 pci_link5: ACPI PCI Link LUBA irq 5 on acpi0 pci_link6: ACPI PCI Link LUBB on acpi0 pci_link7: ACPI PCI Link LMAC irq 11 on acpi0 pci_link8: ACPI PCI Link LACI irq 3 on acpi0 pci_link9: ACPI PCI Link LMCI on acpi0 pci_link10: ACPI PCI Link LSMB irq 11 on acpi0 pci_link11: ACPI PCI Link LUB2 irq 3 on acpi0 pci_link12: ACPI PCI Link LIDE on acpi0 pci_link13: ACPI PCI Link LSID irq 11 on acpi0 pci_link14: ACPI PCI Link LFID irq 10 on acpi0 pci_link15: ACPI PCI Link LPCA on acpi0 pci_link16: ACPI PCI Link APC1 irq 0 on acpi0 pci_link17: ACPI PCI Link APC2 irq 0 on acpi0 pci_link18: ACPI PCI Link APC3 irq 0 on acpi0 pci_link19: ACPI PCI Link APC4 irq 0 on acpi0 pci_link20: ACPI PCI Link APC5 irq 16 on acpi0 pci_link21: ACPI PCI Link APCF irq 0 on acpi0 pci_link22: ACPI PCI Link APCG irq 0 on acpi0 pci_link23: ACPI PCI Link APCH irq 0 on acpi0 pci_link24: ACPI PCI Link APCJ irq 0 on acpi0 pci_link25: ACPI PCI Link APCK irq 0 on acpi0 pci_link26: ACPI PCI Link APCS irq 0 on acpi0 pci_link27: ACPI PCI Link APCL irq 0 on acpi0 pci_link28: ACPI PCI Link APCZ irq 0 on acpi0 pci_link29: ACPI PCI Link APSI irq 0 on acpi0 pci_link30: ACPI PCI Link APSJ irq 0 on acpi0 pci_link31: ACPI PCI Link APCP irq 0 on acpi0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci_link26: BIOS IRQ 11 for -2145766612.1.INTA is invalid pci_link21: BIOS IRQ 5 for -2145766612.2.INTA is invalid pci_link27: BIOS IRQ 3 for -2145766612.2.INTB is invalid pci_link23: BIOS IRQ 11 for -2145766612.10.INTA is invalid pci_link24: BIOS IRQ 3 for -2145766612.4.INTA is invalid pci_link29: BIOS IRQ 11 for -2145766612.7.INTA is invalid pci_link30: BIOS IRQ 10 for -2145766612.8.INTA is invalid pci0: ACPI PCI bus on pcib0 pci_link26: Unable to choose an IRQ pci_link21: Unable to choose an IRQ pci_link27: Unable to choose an IRQ pci_link24: Unable to choose an IRQ pci_link29: Unable to choose an IRQ pci_link30: Unable to choose an IRQ pci_link23: Unable to choose an IRQ pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 ichsmb0: SMBus controller port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c40-0x4c7f irq 20 at device 1.1 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 ohci0: OHCI (generic) USB controller mem 0xd8104000-0xd8104fff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfeb0-0xfeb000ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: EHCI (generic) USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
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]
