Re: firefox, Xorg and crash.
On 15 Aug, Yann Golanski wrote: Firefox keeps taking X11 and then the whole machine with it. It requires a hard reset as even pinging the machine does not work. Only Firefox seems to be doing this. Does anyone else have the same problem? Anyone knows how to solve/debug this? ; uname -a FreeBSD rubicon.york.ac.uk 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Aug 8 16:18:46 BST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 ; pkg_info | grep xorg xorg-6.8.2 X.Org distribution metaport ; pkg_info | grep firefox firefox-1.0.6_1,1 Web browser based on the browser portion of Mozilla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: firefox, Xorg and crash.
On 15 Aug, Yann Golanski wrote: Firefox keeps taking X11 and then the whole machine with it. It requires a hard reset as even pinging the machine does not work. Only Firefox seems to be doing this. Does anyone else have the same problem? Anyone knows how to solve/debug this? What X11 driver are you using? I am using the 'radeon' driver and had to set: Option NoAccel true in the Device section from my xorg.conf file. Just in case. Phil. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
pxeboot problems with BETA2
Hello, I just wanted to ask if somebody had success with providing pxe boot service under 6-BETA2. I have two clients, one NET4501 wich just reboots after fetching pxeldr via TFTP and a Laptop which just hangs when NFS-loading kernel. I'm about to investigate further, but maybe someone can confirm that in general PXE booting with BETA2 is working... Or not... Thanks, -Harry pgpQYJVX1MOKy.pgp Description: PGP signature
Re: 5.4-STABLE panic in propagate_priority() and a tentative patch
Garry Belka [EMAIL PROTECTED] writes: We saw several panics of the same kind on different systems running 5.4-STABLE. The panic was in propagate_priority() and was ultimately traced to vget() call in pfs_vncache_alloc(). vget() is called under global pfs mutex. When vget() sleeps, propagate_priority() in a different thread comes across a sleeping thread that owns a blocked mutex, and that causes a panic. Could you please file a PR about this issue, with the patch attached? (use 'send-pr -a /path/to/patch' to avoid clobbering whitespace) DES -- Dag-Erling Smørgrav - [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: Build failure in procfs module
On Tue, Aug 16, 2005 at 01:29:45AM +0400, Boris Samorodov wrote: On Thu, 11 Aug 2005 19:34:09 +0400 Yar Tikhiy wrote: On Thu, Aug 04, 2005 at 12:28:35PM +0400, Boris Samorodov wrote: On Mon, 18 Jul 2005 19:19:24 +0400 Yar Tikhiy wrote: On Thu, Jul 14, 2005 at 02:15:07PM +0400, Yar Tikhiy wrote: I ran into a problem that might be triggered by Peter's recent changes to procfs. Namely, the buildworld procedure would fail in the procfs module if MODULES_WITH_WORLD were set. I noticed it first in CURRENT and then tested it in a clean environment by building a freshly CVSup'd RELENG_6 on a freshly installed 5.4-RELEASE, with MODULES_WITH_WORLD set. I think it's a route of upgrading quite a few people will follow. Here's the diagnostics: [snip] The problem appears to have to do with Peter's changes to procfs: The procfs source files now include opt_compat.h, which is not available by default when building with MODULES_WITH_WORLD set. The attached patch seems to fix the problem in the conventional way. However, I'm unsure which COMPAT_* options are really needed to the procfs module. COMPAT_43 should be enough according to my quick examining /sys/fs/procfs. Was the case corrected in BETA2? A couple of days ago I upgraded from CURRENT (middle of June 2005) to BETA1. The problem existed but the patch helped. Alas, no one has displayed interest in fixing this bug since I left for vacation. I committed the fix to CURRENT today although I don't use procfs, which is a kind of a situation I hate. MFC to RELENG_6 is due in 3 days. Could you (or somebody else) MFC the patch to RELENG_6? RELENG_6 is frozen now, so I must receive RE's approval before merging my change to the branch. Discussion with re@ and some expert developers is under way. Applying for the approval has appeared the best way to draw attention to the issue :-) -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
badblocks
Hello, is therer any application similar to badblocks of linux on freebsd? How can I check and mark bad blocks of HD's ? thanks. Atenciosamente, __ Augusto Cesar Castoldi Analista de Sistemas www.dock.com.br Florianópolis - SC - Brasil E-mail: [EMAIL PROTECTED] Telefone: (48) 3035-2585 - Sistema Docktool 2005 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: badblocks
Augusto Cesar Castoldi wrote: is therer any application similar to badblocks of linux on freebsd? badsect(8) How can I check and mark bad blocks of HD's ? But normally modern drives do that by themselves (and transparently remap them). If the filesystem starts complaining about bad blocks (that is, hard read/write errors), that means the on-disk bad sector list is full and it's probably time to buy a new drive. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Xorg monopolizes CPU after switching away with KVM
Hi all- So I've just encountered a new issue ( for me ) with Xorg, and i'm having a heck of a time tracking down the source and/or the actual nature of the issue. When i switch to another computer using my KVM, Xorg immediately begins to monopolize the CPU, heading up to 95% utilization. When i switch back to my machine, my USB keyboard works, but by USB mouse is unfunctioning. I have to force quit Xorg and restart to restore peace to the land. Now, this didn't exist on 5.3. I'm running FreeBSD 5.4-STABLE, and xorg-6.8.2 and gnome2-2.10.1 from ports. I get no info in the logs either. I've searched the archives on this, but it's difficult to figure out exactly /what/ to search on to match this problem. No love on the xorg list either. Any thoughts are greatly appreciated. Regards, darren david ___ 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: badblocks
Matthias Buelow [EMAIL PROTECTED] wrote: Augusto Cesar Castoldi wrote: is therer any application similar to badblocks of linux on freebsd? badsect(8) How can I check and mark bad blocks of HD's ? But normally modern drives do that by themselves (and transparently remap them). If the filesystem starts complaining about bad blocks (that is, hard read/write errors), that means the on-disk bad sector list is full and it's probably time to buy a new drive. That's not completely true. The transparent remapping feature only works when sectors are being written to. When you read from a file and get a read error, nothing will be rewritten and you you keep getting the same error. To force the drive to remap the bad sectors, you have to write to them. If the bad sectors are inside a file, it might work to overwrite the file. Otherwise you have to extract the sector numbers from syslog and use dd(1) to overwrite them on the raw device, followed by fsck. Of course it is always a good idea to make a complete backup (if possible) before. If you have a good backup, you can also simply overwrite the whole disk with dd (and then use fdisk, disklabel, newfs as usual and restore from your backup). Note that remapping has to be enabled. For SCSI disks, the camcontrol(8) manpage contains an example for that. Also note that some drives don't remap bad sectors, no matter what you do. In any case: If the drive is used to store important or valuable data, then it should be replaced when read errors occur, no matter whether remapping the bad sectors works or not, because it is quite possible that further sectors will be damaged. Just my 2 Euro cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: badblocks
Hans Lambermont wrote: How can I check if my drives are configured to do this ? I remember on BSDi that you had to 'switch it on' as it was no default behaviour then. I don't know but on my ATA/SATA disks, smartctl displays a Reallocated_Sector_Ct, which I guess is the number of relocated sectors. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg monopolizes CPU after switching away with KVM
Darren David wrote: Hi all- So I've just encountered a new issue ( for me ) with Xorg, and i'm having a heck of a time tracking down the source and/or the actual nature of the issue. When i switch to another computer using my KVM, Xorg immediately begins to monopolize the CPU, heading up to 95% utilization. When i switch back to my machine, my USB keyboard works, but by USB mouse is unfunctioning. I have to force quit Xorg and restart to restore peace to the land. Now, this didn't exist on 5.3. I'm running FreeBSD 5.4-STABLE, and xorg-6.8.2 and gnome2-2.10.1 from ports. I get no info in the logs either. I've searched the archives on this, but it's difficult to figure out exactly /what/ to search on to match this problem. No love on the xorg list either. Any thoughts are greatly appreciated. Regards, darren david It sounds like the symptoms I had when I tried to run an nvidia card on my Tyan motherboard with the nvidia drivers. (And I waited for hours to see if it would stop.) I bet that it is something that the video card is doing, maybe it is trying probe your CRT to see what kind it is, or something like that. (This is all pure speculation on my part, so I don't know.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc-ng problem with [procname] (e.g. kernel threaded procs)
Hmh, no one interested in this issue? Or am i wrong with this issue?
You (Andy Hilker) wrote:
Hi,
i think I have found a problem with rc-ng scripts and procnames
including brackets (e.g. kernel threaded, like mysqld).
Brackets [] are ignored, process will not be found and is regarded
as not running. This breaks stop+status functions of rcng. The
following patch allows brackets in variable procname rc-ng scripts.
Maybe someone can review and fix this issue.
It was relevant for me when using [mysqld].
bye,
Andy
# $FreeBSD: src/etc/rc.subr,v 1.31.2.1 2005/01/17 11:51:00 keramida Exp $
--- rc.subr Thu Aug 11 15:18:52 2005
+++ /etc/rc.subrThu Aug 11 15:14:06 2005
@@ -267,7 +267,7 @@
_procnamebn=${_procname##*/}
_fp_args='_arg0 _argv'
_fp_match='case $_arg0 in
-
$_procname|$_procnamebn|${_procnamebn}:|(${_procnamebn}))'
+
$_procname|$_procnamebn|${_procnamebn}:|(${_procnamebn}))'
fi
_proccheck='
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pxeboot problems with BETA2
On Tue, Aug 16, 2005 at 02:05:08PM +0200, Emanuel Strobl wrote: Hello, I just wanted to ask if somebody had success with providing pxe boot service under 6-BETA2. I have two clients, one NET4501 wich just reboots after fetching pxeldr via TFTP and a Laptop which just hangs when NFS-loading kernel. I'm about to investigate further, but maybe someone can confirm that in general PXE booting with BETA2 is working... Or not... I'm PXE booting systems with RELENG_6 as of 7/27. I'll probably do an update some time this week. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpxiAs9U7feW.pgp Description: PGP signature
Re: Too short ethernet frame...
On Sat, Aug 13, 2005 at 02:01:26AM -0700, Iva Hesy wrote: Just now, I add date=2005.07.31.03.00.00 to my src cvsup sup-file and make kernel, too short ethernet frames are still sniffered. But when I add date=2005.07.22.03.00.00 to sup-file and cvsup and make kernel, the damn datagrams gone!!! Sounds like someone introduced a bug in the nic driver or the ethernet code, but I'm not seeing anything obvious between those dates. If you could narrow the date range further that would help. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpbSR9Wbg7WT.pgp Description: PGP signature
Soekris 1.28 pxeboot problem [Was: Re: pxeboot problems with BETA2]
Am Dienstag, 16. August 2005 19:52 CEST schrieb Brooks Davis: On Tue, Aug 16, 2005 at 02:05:08PM +0200, Emanuel Strobl wrote: Hello, I just wanted to ask if somebody had success with providing pxe boot service under 6-BETA2. I have two clients, one NET4501 wich just reboots after fetching pxeldr via TFTP and a Laptop which just hangs when NFS-loading kernel. I'm about to investigate further, but maybe someone can confirm that in general PXE booting with BETA2 is working... Or not... I'm PXE booting systems with RELENG_6 as of 7/27. I'll probably do an update some time this week. Thanks for the info, I found that the problem is my NET4501 (soekris). Unfortunately my Laptop also seems to have broken PXE code, I got another box booting fine. Any experiences with a net4501 and BIOS versions higher than 1.24? Like mentioned, the box gets DHCP info, loads pxeboot and after this message immediately reboots: CLIENT MAC ADDR: 00 00 24 C0 33 70 CLIENT IP: 172.21.1.248 MASK: 255.255.0.0 DHCP IP: 172.21.0.1 GATEWAY IP: 172.21.0.1 PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader Thanks a lot, -Harry pgp9JzPn9UqIm.pgp Description: PGP signature
problem with ide slots
Hi, I've downloaded the last weekend 5.4-RELEASE-i386-disc1.iso and 5.4-RELEASE-i386-disc2.iso. Several errors raise itself when the installer was running: ata0-master: Failure - ATA-IDENTIFY timed out ata0-master: Failure - ATA-IDENTIFY timed out ata0-master: Failure - ATA-IDENTIFY timed out atapi ... I don't remember the rest My hdd is a Segate ST340014A (40Gb barracuda7200.7) with two partitions where in the partition one I've WinXP and I would want to install freeBDS on the second partition but it's not able to find the hdd. My Motherboard is: http://www.biostar.com.tw/products/mainboard/board.php?name=U8668-D%20v7.x I think that the problems is in fBSD that it's not able to communicate itself with IDE slots. In this case what can I do? In the freebsd-questions@freebsd.org list they told me that I should write you, that maybe you can help me. I hope you can give me some suggestion Thank you ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Create 2.5TB file system on 5.4S?
David Magda wrote: There's the Bonnie and Bonnie++ file system testing programs. I believe one or both are in the Ports. Thanks. I'll take a look. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Create 2.5TB file system on 5.4S?
On Tue, 2005-08-16 at 16:21 -0700, Brandon Fosdick wrote: David Magda wrote: There's the Bonnie and Bonnie++ file system testing programs. I believe one or both are in the Ports. Thanks. I'll take a look. There's also raidtest in benchmarks/raidtest in the ports tree that can be used to generate synthetic I/O load and measure performance. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ 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 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]
